OpenVPN ne se connecte pas au Wi-Fi de l’hôtel ? Essayez TCP 443

Ouvrez le client, appuyez sur Connect et lisez la ligne d’état plutôt que la boîte de dialogue qui suit. Un profil qui se bloque sur Connecting ou Waiting for server après un réseau d’hôtel, de campus ou mobile a généralement perdu son transport quelque part sur le chemin, pas ses identifiants. La prochaine étape utile est d’apprendre ce que ce réseau transporte avant de toucher au serveur. Ne changez rien tant que le même profil n’a pas fonctionné ailleurs.

Testez d’abord depuis un partage de connexion de téléphone. Si le tunnel monte là, le serveur, le certificat et le compte sont tous bons, et la seule variable restante est le réseau devant vous.

Commencez par le client : lisez la ligne d’état

La ligne d’état indique quelle étape a échoué. Un client bloqué sur Connecting résout encore le nom d’hôte ou ouvre le socket externe ; celui qui atteint Waiting for server a un chemin mais pas de réponse ; celui qui s’authentifie puis décroche a un problème entièrement différent. Le journal du client et les champs remote et proto du profil montrent ce que le client tente de faire, et --verb 4 sur un client en ligne de commande imprime le même détail. C’est la comparaison avec le réseau devant vous qui transforme « le VPN est bloqué » en affirmation précise.

Sondez ensuite le réseau avec les outils que vous avez déjà. nc -vzu 203.0.113.10 1194 envoie un datagramme UDP, curl -v telnet://203.0.113.10:443 indique si une poignée de main TCP aboutit, et un navigateur qui charge une page HTTPS prouve seulement que le 443 sortant atteint cet hôte unique. Les petites sondes répondent à ce que le client VPN ne peut pas : quel port et quel protocole quittent réellement ce réseau.

Trois comportements réseau se ressemblent vus du client et exigent des réponses différentes. Le 443 sortant peut être ouvert, seul un proxy peut être autorisé, ou le 443 peut être redirigé de façon transparente vers une boîte d’inspection incapable de lire ce qu’il transporte. Le premier se corrige par le changement de profil ci-dessous, le deuxième par les réglages du proxy, et le troisième peut terminer une poignée de main puis se bloquer quand l’inspecteur décide qu’il n’aime pas le flux. Savoir auquel vous avez affaire fait la différence entre une modification de dix minutes et un après-midi à réinstaller des clients.

Déplacez l’écouteur et le profil ensemble

Côté serveur, réglez l’écouteur sur ce que le réseau permet : port 443 et proto tcp dans la configuration du serveur, puis redémarrez le service et confirmez le socket avec ss -lntp. Côté client, le profil doit suivre, car le transport et le port sont hors du tunnel : proto tcp et port 443 dans le .ovpn, ou les champs correspondants dans l’écran de réglages de l’application. Un profil encore pointé vers UDP 1194 échoue exactement comme avant, et la tentation est d’accuser un pare-feu déjà corrigé. Si le même hôte répond aussi en HTTPS sur le 443, les deux écouteurs ne peuvent pas partager cette adresse et ce protocole ; donnez une seconde adresse au VPN ou placez un démultiplexeur devant.

Suivez la première connexion avec tcpdump -ni any port 443 aux deux extrémités. Les paquets qui quittent le client et n’arrivent jamais signifient que le réseau filtre malgré tout, ou que l’adresse du profil n’est pas celle que vous supposez. Les paquets qui arrivent sans réponse vous renvoient au journal du serveur, où une incompatibilité de protocole apparaît immédiatement comme un paquet rejeté.

Quand seul un proxy sort du réseau

Certains réseaux d’invités n’autorisent rien d’autre qu’un proxy HTTP, ce qui est une contrainte différente d’un port fermé et exclut plus qu’OpenVPN. Les clients qui ne parlent que PPTP, L2TP/IPsec ou IPsec nu n’ont aucun moyen de passer, car ces conceptions attendent que leur protocole extérieur atteigne directement le serveur. OpenVPN le peut, avec http-proxy proxy.example.net 8080 dans le profil client, à condition que le proxy autorise la méthode CONNECT vers votre port. Un proxy SOCKS est encore plus simple, car il transmet le flux sans se soucier de son contenu.

Là où le client n’a pas de prise en charge du proxy, un tunnel SSH sur 443 est généralement ce qui reste. Il ajoute une seconde couche, et l’opérateur du réseau peut avoir un avis dessus, alors traitez-le comme un pont pour un seul trajet plutôt que comme une architecture.

Chiffrez le coût du repli avant de le conserver

TCP dans TCP a un coût connu. Quand la connexion extérieure est TCP et que la charge utile l’est aussi, un segment perdu déclenche une retransmission aux deux couches, et la connexion intérieure recule devant une perte qu’elle ne peut pas voir. La navigation y survit ; les sessions interactives et les appels le ressentent. Gardez l’écouteur TCP 443 comme repli pour les réseaux qui l’exigent, et laissez UDP par défaut pour tout ce qui le laisse encore passer.

Notez le choix dans le nom du profil et dans les notes de support : quel port, quel protocole et quel réseau l’a motivé. Demandez ensuite à l’administrateur du réseau si ce port reste ouvert après le prochain renouvellement du matériel, car un repli qui disparaît silencieusement est pire que pas de repli du tout.