Premièrement, ce problème existe depuis près de deux ans. Jusqu'à ce que le défaut de serveur soit né, j'ai à peu près renoncé à le résoudre - mais maintenant, l'espoir renaît!
J'ai configuré un serveur Windows 2003 comme contrôleur de domaine et serveur VPN dans un bureau distant. Je suis capable de me connecter et de travailler sur le VPN à partir de tous les clients Windows que j'ai essayés, y compris XP, Vista et Windows 7 sans problème, à partir d'au moins cinq réseaux différents (entreprise et maison, domaine et non.) Cela fonctionne bien de tous.
Cependant, chaque fois que je me connecte à partir de clients sur mon réseau domestique, la connexion tombe (silencieusement) après 3 minutes ou moins. Après un court instant, il finira par m'indiquer que la connexion a été interrompue et tentera de recomposer / reconnecter (si j'ai configuré le client de cette façon.) Si je me reconnecte, la connexion se rétablira et semblera fonctionner correctement, mais encore une fois baissera silencieusement, cette fois après une période de temps apparemment plus courte.
Ce ne sont pas des gouttes intermittentes. Cela se produit à chaque fois, exactement de la même manière. La seule variable est la durée de la connexion.
Peu importe le type de trafic que j'envoie. Je peux rester inactif, envoyer des pings continus, RDP, transférer des fichiers, tout cela à la fois - cela ne fait aucune différence. Le résultat est toujours le même. Connecté pendant quelques minutes, puis mort silencieuse.
Étant donné que je doute que quelqu'un ait connu cette situation exacte, quelles mesures puis-je prendre pour dépanner mon VPN évolutif?
Contexte supplémentaire
Au cours de cette période de deux ans, j'ai changé de FAI (aux deux extrémités), ajouté un nouveau contrôleur de domaine (mon réseau) et changé de routeurs (les deux réseaux). Rien de tout cela n'a eu d'effet.
Le problème est reproductible à partir de plusieurs PC, avec différents systèmes d'exploitation, mais uniquement à partir de mon réseau.
J'ai vérifié que le comportement est indépendant du client en testant sur un appareil non Windows. J'ai configuré le VPN sur mon iPhone et connecté via wifi sur mon réseau. À l'aide d'une application appelée Scany, j'ai envoyé une requête ping au serveur en continu jusqu'à ce que la connexion tombe après environ 2 minutes - même comportement que je voyais sur les clients Windows. Par la suite, j'ai désactivé le wifi et le VPN sur AT & Ts 3G et j'ai pingé en continu sans aucune perte de requête pendant 11 minutes. Ce test a correctement isolé le problème sur mon réseau.
Le seul composant cohérent sur la période de deux ans est mon contrôleur de domaine qui gère WINS et agit également comme un serveur VPN pour les connexions entrantes. Mais, le trafic sortant ne doit pas passer par mon DC, il va directement au pare-feu / routeur, qui est directement connecté à mon modem câble.
Plus de notes
Une demande a été faite pour vérifier que mes itinéraires ne sont pas géniaux lorsque la connexion VPN est établie. J'ai jeté un coup d'œil et je ne vois rien de mal à l'évidence, mais mon expérience avec la configuration de l'itinéraire est assez limitée, donc je publie les données.
La plage de classe C de mon LAN est 192.168.1.255, la plage de classe C du LAN distant est 192.168.10.255. J'ai également masqué l'IP publique du serveur VPN (74.93.XXX.XXX).
>route print (VPN Disconnected)
===========================================================================
Interface List
17...00 ff 10 80 57 0c ......Juniper Network Connect Virtual Adapter
11...00 23 ae e6 bb 49 ......Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit
Ethernet NIC (NDIS 6.20)
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.24 10
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
192.168.1.0 255.255.255.0 On-link 192.168.1.24 266
192.168.1.24 255.255.255.255 On-link 192.168.1.24 266
192.168.1.255 255.255.255.255 On-link 192.168.1.24 266
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 192.168.1.24 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 192.168.1.24 266
===========================================================================
Persistent Routes:
None
>route print (VPN Connected)
===========================================================================
Interface List
25...........................VPN Test
17...00 ff 10 80 57 0c ......Juniper Network Connect Virtual Adapter
11...00 23 ae e6 bb 49 ......Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit
Ethernet NIC (NDIS 6.20)
1...........................Software Loopback Interface 1
12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.24 10
74.93.XXX.XXX 255.255.255.255 192.168.1.1 192.168.1.24 11
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
192.168.1.0 255.255.255.0 On-link 192.168.1.24 266
192.168.1.24 255.255.255.255 On-link 192.168.1.24 266
192.168.1.255 255.255.255.255 On-link 192.168.1.24 266
192.168.10.0 255.255.255.0 192.168.10.134 192.168.10.134 11
192.168.10.134 255.255.255.255 On-link 192.168.10.134 266
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 192.168.1.24 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 192.168.1.24 266
255.255.255.255 255.255.255.255 On-link 192.168.10.134 266
===========================================================================
Persistent Routes:
None
la source
Réponses:
Un immense merci à @Warner et @William pour leurs suggestions. En fin de compte, c'est la réponse de William qui m'a conduit à la résolution finale. Pour tous ceux qui viennent à la recherche, voici l'affaire.
Après une tonne de plaisanteries à essayer d'isoler le problème, j'ai finalement fait ce que William a suggéré et j'ai récupéré mes journaux de pare-feu. Ne m'attendant pas à trouver quelque chose d'intéressant, j'ai été surpris en voyant cette ligne:
Sachant que PPTP est la configuration de ce VPN, j'ai fait une recherche sur l'erreur. Il s'avère que d' autres personnes l' ont également vu . Plus précisément, les gens avec mon routeur exact , le D-Link DIR-655.
Il s'avère que la solution est simple.
Dans l'interface d'administration Web du routeur, accédez à l'onglet Avancé et cliquez sur Paramètres du pare-feu dans le menu de gauche. Dans la section intitulée "CONFIGURATION DE LA PASSERELLE DE NIVEAU D'APPLICATION (ALG)", décochez la case PPTP (éventuellement, décochez également IPsec si votre VPN utilise ce protocole.) Cliquez sur "Enregistrer les paramètres" et dites au routeur de redémarrer. Voila!
Malheureusement, la désactivation de ces options ALG signifie que certaines fonctionnalités de routage avancées ne fonctionneront pas. Par exemple, la prise en charge PPTP est destinée à permettre à plusieurs clients NAT de tunneler simultanément vers le même serveur VPN. Cela ne fonctionnera probablement pas si la case est décochée. Cependant, si comme moi votre VPN ne fonctionne pas du tout lorsque la case est cochée, cela ne vous dérange probablement pas.
Je ne sais toujours pas pourquoi je me souviens avoir eu ce problème auparavant avec un routeur totalement différent, mais je suis heureux que cela fonctionne néanmoins.
la source
À une supposition, il y a un composant du trafic VPN qui est requis mais qui est bloqué (par exemple au niveau d'un pare-feu) ou perdu, et qui provoque le décrochage. Vérifiez les journaux du pare-feu si vous en avez pour les paquets perdus. Vérifiez les règles pour vous assurer que tous les ports et protocoles nécessaires sont activés. Vous pouvez également vouloir effectuer une surveillance continue de l'itinéraire de votre côté pour voir si le trafic est mal dirigé après le tunnel VPN. La commande "route print" affiche ces informations sous Windows.
la source
J'avais le même défaut avec openwrt et luci, je me connectais via vpn à mon serveur openvpn sur mon routeur. La connexion serait établie, puis il continuerait à redémarrer mon modem 3G et à perdre ma connexion, la réponse était, pare-feu (merci de pointer la direction) et éditez la connexion: 1194. Ici, vous avez le choix d'où provenait la connexion VPN et par défaut c'était l'appareil, les deux autres options où lan et wan donc pour ma situation c'était wan, un changement rapide et redémarrer et fonctionne très bien ..
la source
Dépannage de base. Éliminez l'équipement. Connexion Internet directement au PC. S'il est reproductible, un autre PC. Remplacez le modem, essayez différents FAI (modem cellulaire). Continuez à descendre jusqu'à ce que vous soyez isolé, puis dépannez l'équipement auquel il est isolé.
la source