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
Réponses:
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.
la source
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.
la source
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).
la source
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:
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:
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
la source
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.
la source
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.
la source
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.
la source
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?
la source
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.
la source
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.
la source
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.
la source