VPN dans une session Bureau à distance

13

Je me connecte à un serveur de mon réseau local via Remote Desktop. Je dois ensuite établir une connexion VPN à Internet à partir de cette session Remote Desktop. Cependant, cela déconnecte immédiatement ma session de bureau à distance.

Que se passe-t-il ici et existe-t-il un moyen de résoudre ce problème?

Informations supplémentaires:

Ordinateur local # 1:

Initie la session RDP à # 2
Windows 7
10.1.1.140/24

Ordinateur local # 2:

Windows Vista
10.1.1.132/24
Initie la connexion VPN à l'IP publique
Le VPN est PPTP
Prêt à obtenir automatiquement IP et DNS
«Utiliser la passerelle par défaut sur le réseau distant» n'est pas sélectionné
'Activer LMHosts' est sélectionné
'Activer Netbios' sur TCP / IP est sélectionné
A la capacité d'être multi-hébergé (c.-à-d. A 2 nic)

Routeur ADSL public:

Serveur VPN
reçoit la connexion de # 2 via IP externe
Le réseau interne est 192.168.0.0/24

Je peux établir une connexion VPN à partir de mon PC sans aucun problème (pas de RDP impliqué).

Tom a suggéré d'utiliser deux cartes réseau dans un commentaire ci-dessous. J'ai deux cartes réseau dans la boîte (# 2 ci-dessus) mais je ne sais pas comment les configurer correctement, ni comment assigner le VPN pour les utiliser l'une par rapport à l'autre.

J'ai essayé de configurer la carte d'interface réseau supplémentaire pour qu'elle soit sur le même réseau privé (10.1.1.200/24), en démarrant le VPN et en essayant de RDP sur l'une des cartes réseau, 10.1.1.132 ou 10.1.1.200, mais je n'ai pas eu de chance. Existe-t-il un moyen de dire au VPN d'utiliser une carte réseau sur l'autre?

Comme demandé - voici mes tables de routage du PC # 2:

Avant que le VPN ne soit connecté:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.1.1.254       10.1.1.132     20
         10.1.1.0    255.255.255.0         On-link        10.1.1.132    276
       10.1.1.132  255.255.255.255         On-link        10.1.1.132    276
       10.1.1.255  255.255.255.255         On-link        10.1.1.132    276
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      169.254.0.0      255.255.0.0         On-link        10.1.1.132    296
  169.254.255.255  255.255.255.255         On-link        10.1.1.132    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link        10.1.1.132    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link        10.1.1.132    276
===========================================================================

et après la connexion du VPN:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.1.1.254       10.1.1.132     20
         10.1.1.0    255.255.255.0         On-link        10.1.1.132    276
       10.1.1.132  255.255.255.255         On-link        10.1.1.132    276
       10.1.1.255  255.255.255.255         On-link        10.1.1.132    276
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      169.254.0.0      255.255.0.0         On-link        10.1.1.132    296
  169.254.255.255  255.255.255.255         On-link        10.1.1.132    276
      192.168.0.0    255.255.255.0    192.168.0.254    192.168.0.234    267
    192.168.0.234  255.255.255.255         On-link     192.168.0.234    522
    remote-vpn-ip  255.255.255.255       10.1.1.254       10.1.1.132     21
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link        10.1.1.132    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link        10.1.1.132    276
  255.255.255.255  255.255.255.255         On-link     192.168.0.234    522
===========================================================================

J'ai même essayé de brancher la deuxième interface (10.1.1.232) et de jouer avec les routes par défaut:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.1.1.254       10.1.1.132     21
         10.1.1.0    255.255.255.0       10.1.1.254       10.1.1.232     11
       10.1.1.132  255.255.255.255         On-link        10.1.1.132    276
       10.1.1.232  255.255.255.255         On-link        10.1.1.232    266
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      169.254.0.0      255.255.0.0         On-link        10.1.1.132    296
  169.254.255.255  255.255.255.255         On-link        10.1.1.132    276
      192.168.0.0    255.255.255.0    192.168.0.254    192.168.0.235    267
    192.168.0.235  255.255.255.255         On-link     192.168.0.235    522
    remote-vpn-ip  255.255.255.255       10.1.1.254       10.1.1.132     21
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link        10.1.1.132    276
        224.0.0.0        240.0.0.0         On-link        10.1.1.232    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link        10.1.1.132    276
  255.255.255.255  255.255.255.255         On-link        10.1.1.232    266
  255.255.255.255  255.255.255.255         On-link     192.168.0.235    522

vpn remote-desktop

— Dan
source

Veuillez fournir plus d'informations sur votre configuration. En particulier, quelle technologie VPN (IPsec, VPN SSL, ...), quel client VPN et quel type de routage dans le LAN?

— sleske

Avez-vous la configuration vpn pour ne pas acheminer tout le trafic sur le vpn? si sa configuration est comme ça, il vous coupera.

— Sirex

J'ai ajouté plus d'informations. Aussi - j'ai essayé d'avoir "Utiliser la passerelle par défaut sur le réseau distant" sélectionné et non sélectionné. Pas de chance. Merci pour votre contribution jusqu'à présent.

— Dan

Tout le trafic provenant d'autres hôtes sur le réseau 10.1.1.0/24 est-il rejeté par le PC # 2 lorsque le VPN est actif? ICMP (Ping) etc.?

— Goyuix

Oui Goyuix - c'est exact. Les pings vers PC # 2 ne réussissent que lorsque le VPN est inactif.

— Dan

10

Ce qui se passe, c'est que vous coupez efficacement la route IP du serveur vers vous-même - d'où la perte de session RDP. Vous pouvez le corriger en configurant le VPN de manière à ce qu'il soit lié à une seconde interface (physique ou virtuelle) afin que le lien VPN et RDP puissent coexister. La façon dont vous faites cela dépend énormément d'une gamme de configurations très détaillées que nous ne connaissons pas actuellement, donc si vous voulez de l'aide, vous devrez nous revenir avec BEAUCOUP plus d'informations, autant que vous le pouvez S'il vous plaît.

— Chopper3
source

3

+1. Ce serait ma conjecture aussi. Je me demande si quelque chose comme LogMeIn pourrait être une solution plus facile que d'essayer de trouver une solution de contournement pour faire fonctionner la session RDP.

— joeqwerty

Mettez une deuxième carte réseau dans la boîte et demandez au client VPN de provenir de celui avec la route par défaut assignée.

— SpacemanSpiff

Vous pourriez être sur quelque chose ici Tom. Voir modification en question.

— Dan

Comment cela se produirait-il si le paramètre de passerelle distante était désactivé et qu'il se connectait via la route locale (même sous-réseau)?

— Joris

5

Cela peut être une pratique habituelle - par défaut, sur une boîte Windows, (cela peut avoir changé), tout le trafic est forcé dans le tunnel VPN, donc oui, votre RDP va chuter.

Je suggère d'aller dans les paramètres avancés de votre VPN sur votre serveur et de vous assurer qu'il n'envoie pas tout le trafic via le VPN.

Vérifiez également que le réseau de destination n'utilise pas les mêmes paramètres de sous-réseau que vous, sinon, vous rencontrerez à nouveau les symptômes que vous décrivez.

— Mister IT Guru
source

Juste pour vérifier, vous êtes réellement assis physiquement devant l'ordinateur local # 1, non?

— Mister IT Guru

Oui c'est vrai. J'ai essayé de définir «Utiliser la passerelle par défaut sur le réseau distant» comme non sélectionné. Pas de chance.

— Dan

Aussi - c'est un sous-réseau différent,

— Dan

1

J'ai eu le même problème. Vérifiez si le fournisseur vpn peut vous ajouter à un groupe qui a un ensemble de règles pour le `` tunneling fractionné '' - cela se fait du côté hôte vpn et si le serveur ne l'a pas activé, vous ne pourrez pas faire ce que vous essaient de.

Voyant que votre vpn a l'adresse 192. * lorsque vous vous connectez, il détruira l'interface sur laquelle vous vous connectez (vous coupant ainsi).

Si le tunneling fractionné n'est pas activé sur le serveur VPN (contactez l'administrateur du serveur VPN à ce sujet!), Vous ne pourrez pas vous connecter.

Tout cela suppose que vous définissez correctement vos connexions VPN locales (il y ressemble).

— Marm0t
source

Merci - Je ne vois aucune option pour le «tunneling divisé» sur le serveur VPN. Pour être clair - j'utilise simplement un routeur ADSL (Draytek) avec une fonctionnalité de serveur VPN intégrée. Il peut ne pas avoir d'options avancées ...

— Dan

Ce routeur a-t-il un démon pptp en cours d'exécution? Si c'est le cas, vous devrez le désactiver. Cela pourrait interférer avec les paquets GRE.

— Mister IT Guru

1

J'ai eu ce problème auparavant, et la solution est le «tunneling fractionné», cela signifie envoyer le trafic Internet à la passerelle par défaut et le trafic au réseau VPN à l'aide du tunnel.

Ce que vous devez faire est de configurer une route statique vers votre machine sur l'ordinateur # 2. Et en définissant la priorité de cet itinéraire sur 0

Ainsi, le résultat final sera une route par défaut 0.0.0.0/0 vers l'adresse IP de la passerelle VPN et une route statique vers votre machine en utilisant la passerelle par défaut.

Dans Windows, ce que vous feriez serait quelque chose comme ceci:

 route add 10.1.1.140 netmask 255.255.255.255 <defaultGW> -P

où defaultGW est l'adresse IP de votre routeur.

Cela garantira que le trafic allant au 10.1.1.140 ne sera pas acheminé vers le tunnel.

si vous avez un accès physique à l'ordinateur n ° 2, connectez-vous au VPN et faites-nous connaître la table de routage de la machine:

route print

un avant de se connecter au vpn et un après.

Avec ces informations, nous pouvons vous aider à configurer le "tunnel partagé"

J'espère pouvoir vous aider

— Hugo Garcia
source

J'ai ajouté des tables de routage à la question ci-dessus. Merci pour votre contribution.

— Dan

Lorsque vous vous connectez au VPN sur PC # 2, pouvez-vous toujours surfer sur le WEB? et si vous le pouvez, pouvez-vous vérifier que vous sortez avec la même IP publique? whatismyip.net devrait vous donner l'adresse IP que vous utilisez pour sortir dans le monde. une autre question, utilisez-vous l'interface de numérotation Windows pour vous connecter au VPN ou à un autre client VPN?

— Hugo Garcia

1

J'ai constaté que l'utilisation de l'adresse IPv6 pour se connecter n'entraîne pas la rupture de la session RDP par le VPN.

Dans ma configuration, j'ai un invité et un hôte Windows Virtualbox et mon VPN sur l'invité force TOUT le trafic via le VPN (ceci est configuré par le serveur, je ne peux pas changer cela)

Si je me connecte de mon hôte à l'invité via l'adresse ipv4 (par exemple 192.168.1.x), dès que j'initie la connexion VPN sur l'invité, la session RDP se rompt. Cependant, si je connecte RDP via le nom d'hôte invité (qui se résout en adresse IPv6), la connexion VPN ne rompt pas la session RDP.

— wal
source

0

Difficile à dire sans plus d'informations, mais de nombreux clients VPN ont la mauvaise habitude de déconnecter (logiquement) leur ordinateur hôte du LAN lors de la configuration de la connexion VPN. C'est-à-dire que vous pouvez être connecté soit à votre LAN, soit au VPN, mais pas aux deux.

Si votre client VPN fait cela, votre session RDP serait évidemment tuée comme effet secondaire de vous couper du LAN.

Je ne sais pas pourquoi les clients VPN font cela, que ce soit une mesure intentionnelle (sécurité?) Ou juste un effet secondaire de la reconfiguration du réseau, mais je l'ai souvent rencontré.

Consultez le manuel pour plus de détails et pour savoir comment résoudre ce problème.

— sleske
source

1

Les clients VPN font cela pour empêcher les personnes de relier deux réseaux (en utilisant le routage) et de voler toutes vos données à partir de vos systèmes exposés (ou même d'être simplement compromises par des logiciels malveillants), une attaque de cette manière semblera provenir du système qui fait la liaison, ne laissant pratiquement aucune preuve

— Mister IT Guru

0

Normalement, j'ai utilisé des sessions RDP "imbriquées" via VPN sans problème spécial (à part un léger ralentissement) Le schéma sous-jacent était Client-> VPN-> RDP First Server-> Internet-> RDP Second Server. Le seul problème que vous pourriez avoir, je pense, est que le premier serveur peut avoir un pare-feu qui bloque l'appel sortant du protocole RDP. En utilisant un VPN, vous pouvez "entrer" dans le réseau de serveurs mais ce n'est pas une garantie que le même serveur ou d'autres machines LAN puissent établir une session RDP avec un serveur LAN externe. Si votre deuxième serveur est dans le LAN du premier, veuillez vérifier qu'il peut être atteint par une session RDP (par exemple: peut avoir un pare-feu local bloquant le port RDP) et que Windows permet de l'utiliser. La coupure immédiate de la deuxième session RDP signifie qu'il y a un "problème" de réseau (pare-feu, auth et ainsi de suite) sur la route vers le deuxième serveur, une vérification précise des appels sortants du premier serveur est donc requise. Selon moi, la solution est plus simple que vous ne le pensez aussi si le premier serveur n'a qu'une seule carte réseau. Pendant longtemps, j'ai fonctionné avec des sessions rdp imbriquées avec des serveurs montant Windows 2000, Windows 2003 et 2008 en utilisant un serveur VPN sur un serveur Windows 2003 puis en imbriquant des sessions RDP pour les deux autres, parfois plus, à partir de la première. Veuillez donc vérifier les conditions réseau du premier serveur. Windows 2003 et 2008 utilisant un serveur VPN sur un serveur Windows 2003 puis imbriquant les sessions RDP pour les deux autres, parfois plus ensemble, à partir de la première. Veuillez donc vérifier les conditions réseau du premier serveur. Windows 2003 et 2008 utilisant un serveur VPN sur un serveur Windows 2003 puis imbriquant les sessions RDP pour les deux autres, parfois plus ensemble, à partir de la première. Veuillez donc vérifier les conditions réseau du premier serveur.

0

Vous avez mentionné que "Utiliser la passerelle par défaut" n'est pas coché - ce qui, si cela est acceptable (aucun routage requis en dehors du sous-réseau 192.168.0.0/24), aurait dû résoudre votre problème.

Que vous reste-t-il avec des sons comme potentiellement le pare-feu gênant? Pouvez-vous désactiver complètement le pare-feu Windows (ou tout autre produit que vous utilisez) et vérifier que le symptôme existe toujours?

Êtes-vous en mesure de reconnecter la session interrompue après que la liaison VPN a été établie et reste active?

— Goyuix
source

J'ai essayé avec tous les pare-feu désactivés et je ne peux pas reconnecter le RDP pendant que le VPN est actif.

— Dan

0

Edit : j'ai raté la réponse de Sleskes expliquant la même chose.

Peut-être que certains produits de sécurité installés (pare-feu, "sécurité Internet", antivirus, ...) détectent la connexion PPTP et ont les mêmes fonctionnalités?

Notez que certains de ces produits ont des options qui sont profondément enfouies dans l'interface graphique derrière des cases à cocher sans prétention.

— Joris
source

0

Il est probable que le client VPN soit configuré pour acheminer TOUT le trafic dans le tunnel, pas seulement le trafic vers les réseaux vers lesquels le VPN est acheminé. Cela supprime toutes les connexions actuellement ouvertes et modifie le comportement de routage sur le serveur, d'où la raison pour laquelle votre connexion est interrompue.

— tomstephens89
source

0

Cela ne résout pas le problème spécifique mentionné, mais c'est ce que j'ai utilisé pour résoudre le même type de problème en prenant en charge une variété de clients utilisant une variété de clients vpn qui ne sont pas tous compatibles et certains qui créent une connexion vpn tunnel fermée. J'ai un serveur vmware qui héberge plusieurs machines virtuelles et utilise le client vSphere pour se connecter à la session Windows et je peux ouvrir une connexion VPN tunnel fermée et ne pas perdre l'accès à la session Windows.

— Jeff Haskett
source