OpenVPN sur le 443 toujours bloqué ? Vérifiez ce que le réseau inspecte

Le tunnel se connecte depuis une ligne domestique et se bloque sur un réseau d’hôtel ou de bureau, et déplacer le serveur sur le port 443 n’a rien changé. Ce résultat est assez courant pour avoir une forme : le port était la partie facile, et le reste de la décision appartient à tout ce qui se trouve entre le client et le serveur. Deux questions règlent la plupart des cas, et aucune ne porte sur les chiffrements. Le réseau accepte-t-il une poignée de main TLS vers cette adresse, et le client garde-t-il une route vers son propre enrobage tant que le tunnel est monté ?

La poignée de main en dit plus que le numéro

Un écouteur VPN natif sur TCP 443 parle son propre protocole dès le premier paquet. Un ClientHello a un champ de version, une valeur aléatoire et une liste d’extensions, et un appareil qui lit quelques centaines d’octets voit la différence sans rien déchiffrer. Les numéros de port sont faciles à satisfaire, et c’est la forme du protocole que le filtre vérifie réellement. Les règles s’écrivent aussi souvent par protocole, donc une politique qui inspecte TLS ne dit rien d’UDP.

Un proxy transparent qui exige une session TLS valide coupe la connexion pendant la mise en place, souvent après que la poignée de main TCP est terminée. Ce détail compte plus tard, car il signifie que le journal du client s’arrête une fois la socket établie.

Envelopper le flux crée deux points de défaillance

Un enrobage TLS comme stunnel rétablit la forme attendue : le client se connecte à un écouteur local, l’enrobage ouvre une vraie session TLS vers le serveur sur le 443, et un second enrobage sur le serveur transmet les octets déchiffrés au démon VPN. La session extérieure ressemble désormais à n’importe quelle connexion HTTPS. Le démon VPN du serveur ne devrait écouter que sur le loopback, car rien en dehors de l’enrobage n’a besoin de l’atteindre.

Trois choses distinctes doivent s’aligner pour ce montage. Le profil du client pointe vers l’écouteur local, le certificat du serveur correspond au nom que le client vérifie, et le transfert côté serveur vise le port que le démon utilise réellement. Trompez-vous sur l’une d’elles et la connexion meurt avant d’atteindre la couche VPN. Un écart de certificat apparaît alors comme une erreur d’enrobage et non comme une erreur VPN, et c’est pourquoi les deux journaux valent d’être lus côte à côte.

La route vers l’enrobage est le piège

Une fois le tunnel monté, la route par défaut pointe dedans, et la session TLS extérieure a besoin d’un chemin qui n’entre pas dans le tunnel qu’elle transporte. Un client VPN ordinaire protège l’adresse qu’il appelle ; un client enrobé appelle son propre loopback, donc l’adresse de destination de l’enrobage est invisible pour cette protection.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Les adresses exactes sont à remplir par vous, et la route doit exister pendant toute la vie de la connexion, pas seulement au démarrage. Un petit script d’enrobage qui ajoute la route avant le client et la retire ensuite est plus fiable qu’une commande mémorisée.

Sur Android, l’équivalent de cette exception est un réglage par application : excluez l’application d’enrobage du tunnel pour que son propre trafic sorte par la connexion mobile. Sans l’exclusion, l’enrobage est routé dans le tunnel qu’il essaie de construire, et la boucle de reconnexion ressemble à un problème de serveur.

Lisez le minutage avant de changer quoi que ce soit

Une session qui meurt après le même intervalle à chaque fois est une signature de politique et non une défaillance cryptographique, et les limites de flux de longue durée produisent exactement ce schéma. Une connexion qui se réinitialise juste après la poignée de main suggère un proxy qui n’a pas aimé la chaîne de certificats.

Comparez l’émetteur du certificat d’un site HTTPS ordinaire depuis les deux réseaux. Si l’émetteur diffère sur le réseau restreint, quelque chose termine TLS au milieu, et aucun enrobage ne survivra à cette interception sans changement. La même comparaison vous dit si le blocage vise le nom de votre serveur ou chaque session TLS à cette adresse.

Notez le comportement observé : combien de temps la session a duré, si la socket s’est ouverte, si l’enrobage a journalisé une poignée de main. Chacun de ces points resserre le test suivant.

Testez une variable à la fois

Vérifiez d’abord UDP, car certains réseaux le suppriment entièrement et un échec UDP ne dit rien sur le 443. Essayez ensuite TCP 443 sans l’enrobage, puis l’enrobage sur le 443. Lisez le journal du client à chaque étape et arrêtez-vous dès que le comportement change.

Changez un élément par essai. Un nouveau port, un nouvel enrobage et un nouveau chiffrement dans la même passe vous laissent incapable de dire lequel des trois comptait.