Le VPN se connecte à la maison mais expire sur le Wi-Fi de l'hôtel

Le portable rejoint le Wi-Fi de la maison, le client se connecte en trois secondes, et le même profil échoue à l'hôtel une heure plus tard. Rien n'a été mis à jour entre-temps. Parcourir cela avec un client devant vous consiste surtout à savoir quelle erreur appartient à quelle étape, car l'information utile est dans le code que le client imprime, pas dans le fait qu'il ait échoué. Suivez les quatre étapes ci-dessous dans l'ordre et vous saurez si un nom, un paquet, un port ou une règle vous a refusé.

Lisez le code d'erreur comme une étape, pas comme un verdict

Le client franchit trois jalons distincts avant qu'un tunnel existe. Il résout le nom du serveur, il obtient une réponse de quelque chose sur le réseau, et il négocie une association de sécurité. Chaque jalon a son propre message d'échec, et Windows en particulier est généreux en codes distincts une fois qu'on sait à quelle étape ils appartiennent.

Deux de ces codes signifient que le réseau est innocent. Un 789 signifie que les paquets circulaient et que les deux extrémités n'étaient pas d'accord sur la cryptographie, ce qui est un problème de configuration que vous pouvez corriger chez vous. Un 868 signifie qu'aucun paquet n'a jamais eu besoin de sortir, donc la conception du tunnel est sans importance tant que le nom n'est pas résolu. Trier le code dans la bonne étape fait gagner plus de temps que n'importe quelle capture, parce que cela vous dit laquelle des trois étapes suivantes sauter.

Soyez prudemment nuancé si le client n'est pas Windows. Les clients tiers réduisent la plupart de ces cas à « connexion échouée », et c'est pourquoi les deux étapes suivantes ne s'appuient pas du tout sur le message.

Vérifiez le nom avant d'accuser le tunnel

Les réseaux d'hôtels et d'aéroports interceptent le DNS en permanence, et un résolveur qui répond avec une adresse de portail produit un échec qui ressemble exactement à un serveur mort. Comparez ce que dit le résolveur local avec ce que dit un résolveur public :

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

Si les deux réponses diffèrent, vous êtes redirigé et le reste du diagnostic est perdu tant que ce n'est pas résolu. Une adresse de portail, en particulier, acceptera volontiers la connexion TCP puis se bloquera, et c'est pourquoi cela peut ressembler à un blocage de pare-feu quand vous testez avec un navigateur.

Confirmez maintenant que l'adresse que vous voulez joindre est bien celle qui est utilisée. Certains clients mettent en cache la résolution précédente pour toute la durée de vie du profil, si bien qu'une reconnexion après le changement de DNS passe encore par l'ancienne adresse. Fermez complètement le client avant de retester, au lieu d'appuyer sur déconnecter puis connecter dans la même fenêtre.

Découvrez quel paquet extérieur disparaît

Le tunnel a un flux extérieur qui appartient entièrement au chemin entre vous et le serveur, et c'est ce flux que les boîtiers intermédiaires classifient et suppriment. Capturez-le sur le client, puis comparez un réseau qui fonctionne avec celui qui échoue. Sous Windows, la capture intégrée suffit pour un premier regard :

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Ce que vous voulez voir, c'est si vos paquets sortent réellement et si quelque chose revient. Des paquets sortants sans rien en retour signifient que le chemin ou l'extrémité distante les supprime ; rien qui sorte du tout signifie que le client n'a jamais atteint l'envoi, ce qui renvoie à la résolution de noms ou à une règle de pare-feu locale.

Répétez le même test sur un partage de connexion de téléphone. C'est la comparaison la plus instructive dont vous disposez, car elle retire du chemin chaque boîtier de l'hôtel tout en gardant le portable, le client et les identifiants identiques. Si le tunnel monte sur le partage de connexion, arrêtez de regarder le serveur. S'il échoue aussi là, vous avez un problème de client ou de compte que le réseau n'a jamais causé.

Changez un transport et retestez

Une fois que vous savez que le flux extérieur est supprimé, la question pratique est de savoir quel flux le réseau autorise. La plupart des réseaux restreints autorisent le TCP 443 sortant parce qu'ils ne peuvent pas fonctionner autrement, donc déplacer l'écouteur là-bas est la réponse habituelle. Sur OpenVPN, c'est un commutateur côté client tant que le serveur n'est pas modifié :

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

Les clients IPsec ont un levier équivalent dans leurs propres panneaux de réglages, généralement décrit comme IPsec sur TCP ou traversée NAT. Le changer est aussi un diagnostic : si le tunnel monte sur TCP et meurt sur UDP, vous avez prouvé que le réseau filtre l'UDP, et vous avez aussi trouvé le réglage qu'il vous faudra à chaque visite de ce site.

Résistez à la tentation de désactiver des fonctions du routeur dès le premier essai. Couper l'inspection avec état ou la protection contre les flots sur un réseau d'hôtel ne vous est de toute façon pas accessible, et sur votre propre matériel cela échange une vraie protection contre un seul portable. Notez quel réglage a changé le résultat, remettez-le ensuite et cherchez un transport que le réseau autorise déjà.

Vérifiez le même profil sur le second réseau

Avant de fermer le ticket, prouvez que le changement a survécu à la sortie du bâtiment. Reconnectez-vous sur le réseau d'origine avec les réglages d'origine, capturez les trente premières secondes et confirmez que le client atteint le même état qu'au partage de connexion :

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

La distinction que révèle la dernière commande mérite d'être conservée : le profil peut annoncer un tunnel connecté alors que le routage à l'intérieur est faux, et cela produit «le VPN est monté mais rien ne fonctionne », ce qui est un autre article. Si le type de tunnel a changé après votre modification, le profil n'est pas celui que vous avez testé.

Écrivez ensuite la conclusion là où la personne suivante regardera. « Le profil entreprise a besoin de TCP 443 sur ce site ; l'hôtel filtre UDP 500 » est une phrase sur laquelle un collègue peut agir. « Le VPN est instable dans les hôtels » ne l'est pas, et cela garantit que la même heure sera de nouveau dépensée le mois prochain.