Pourquoi un profil OpenVPN fonctionne à la maison mais échoue à l'hôtel

Le Wi-Fi du bureau et une chambre d'hôtel peuvent offrir au même ordinateur portable deux réseaux très différents, et le profil entre les deux n'en sait rien. Ce qui fonctionne à la maison suppose une liaison montante permissive, une résolution de noms fonctionnelle et un sous-réseau local qui n'entre en collision avec rien de ce que le tunnel transporte. Chacune de ces hypothèses peut échouer séparément.

La bonne façon de déboguer cela est de traiter le réseau comme quatre faits distincts, puis de les tester dans l'ordre. Deviner le profil en premier produit généralement un changement qui ne corrige rien et masque les preuves.

Quatre faits réseau changent d'un lieu à l'autre

Le premier fait est de savoir si le réseau local vous laisse sortir, tout simplement. Un portail captif admet un appareil sur une page de connexion et bloque tout le reste jusqu'à ce que cette page soit terminée, ce qui signifie que le tunnel ne peut pas démarrer, aussi correct que soit le profil.

Le deuxième est la résolution de noms. Un portail qui intercepte DNS répond à chaque requête avec sa propre adresse, si bien que le nom d'hôte du VPN se résout vers le portail et que le client tente de construire un tunnel vers une page web.

Le troisième est le filtrage du transport. Les réseaux qui veulent n'autoriser que la navigation laissent passer TCP 443 vers des destinations arbitraires et abandonnent presque tout le reste, y compris UDP.

Le quatrième est l'adressage. Le sous-réseau local peut chevaucher un réseau derrière le tunnel, ou la liaison montante peut n'offrir aucun chemin IPv4 utilisable.

Résolution de noms et portail captif

Remplacez le nom d'hôte du profil par l'adresse numérique du serveur et réessayez. Si l'IP se connecte et pas le nom, la résolution est en cause, et le profil lui-même est correct.

Ouvrez un navigateur et essayez une page HTTP ordinaire avant de toucher au VPN. Une redirection vers une page de connexion signifie que le portail est encore en attente ; complétez-le, puis reconnectez-vous. Beaucoup d'hôtels font aussi expirer la session au bout de quelques heures, ce qui ressemble à une déconnexion en milieu de journée plutôt qu'à un problème de connexion.

Si l'adresse numérique échoue aussi, la résolution n'est pas l'explication, passez donc au transport. Gardez l'adresse testée, car elle indique à la vérification suivante si les paquets ont seulement quitté la machine.

Filtrage du transport : UDP d'abord, TCP 443 en secours

Un flux OpenVPN sur UDP 1194 ne ressemble à rien que reconnaisse un pare-feu d'hôtel, il est donc abandonné sans erreur. Le client réessaie jusqu'à l'expiration de son délai, et l'utilisateur voit une connexion qui ne s'établit jamais plutôt qu'un refus. Les pare-feu qui se comportent ainsi journalisent rarement l'abandon quelque part de visible. L'absence de refus est elle-même l'indice.

TCP 443 est le secours fiable, car le réseau ne peut pas le distinguer d'un HTTPS ordinaire. Utilisez le profil TCP de l'opérateur quand il en existe un, puisque le serveur doit aussi écouter sur ce transport et ce port ; ne changer que le client produit un autre type d'échec. S'il n'existe aucun profil TCP, demandez à l'opérateur plutôt que d'en inventer un en modifiant le port. Le côté serveur doit être d'accord, et un décalage ressemble de nouveau à un problème de pare-feu.

Attendez-vous à un coût de performance. TCP dans TCP amplifie les retransmissions sur une liaison avec pertes, si bien qu'un tunnel TCP qui fonctionne peut encore sembler lent sur un réseau d'hôtel congestionné. C'est un compromis pour la joignabilité, pas un défaut à traquer.

Collisions d'adresses et liaisons sans IPv4

Un tunnel peut s'établir et ne rien transporter. Quand le LAN local et un réseau distant partagent un préfixe comme 192.168.1.0/24, le client considère l'hôte distant comme directement connecté et envoie le paquet vers la liaison locale au lieu du tunnel. Le symptôme est une connexion réussie avec un sous-réseau inaccessible, ce qui se lit facilement comme un problème de route côté serveur.

La correction permanente est de déplacer le LAN distant vers une plage privée peu courante. Choisir une plage que personne n'utilise chez soi, comme 10.42.0.0/24, évite le problème pour chaque lieu futur au lieu d'un seul. Le contournement local consiste à éviter cet hôtel, ce point d'accès ou ce routeur, ce qui n'est pas une correction du tout.

Les liaisons mobiles ajoutent deux variantes. Le NAT opérateur signifie que les connexions entrantes n'arrivent pas, ce qui compte si vous hébergez un serveur mais pas pour un client sortant. Un APN configuré en IPv6 seul avec traduction NAT64 peut faire échouer un client qui exige un vrai chemin IPv4, et le remède habituel est de changer le protocole de l'APN en IPv4 ou en double pile.

Symptômes une fois le tunnel monté

Un tunnel qui se connecte puis se tait est généralement un problème de keepalive ou de MTU, pas un port bloqué. Une connexion qui tombe après un nombre fixe de minutes indique un minuteur de keepalive ou de renégociation. Configurez le client pour sonder son pair et redémarrer quand les réponses cessent, et testez un MTU de tunnel plus petit si les ping passent alors que les gros transferts calent.

Avant de demander de l'aide, notez trois choses : l'adresse essayée et si elle a répondu, le transport et le port utilisés, et le sous-réseau local du réseau qui a échoué. Ensemble, elles séparent la résolution de noms du filtrage du transport et d'une collision d'adresses, qui sont les causes qui survivent au contact des preuves.