OpenVPN fonctionne à la maison mais pas sur un réseau : UDP ou TCP ?

Le même profil se connecte à la maison et se bloque sur un réseau d’hôtel, de campus ou d’agence. Les identifiants n’ont pas changé, donc la variable intéressante est le chemin : ce qui arrive aux paquets avant que OpenVPN ne les lise. Comparer quatre causes candidates dans l’ordre où on peut les tester vaut mieux que deviner côté certificats. Chacune laisse une trace différente, et c’est la trace qui les sépare.

Quelle étape a échoué indique quelle comparaison compte

Le journal du client note déjà jusqu’où vous êtes allé. Une ligne disant que la négociation de clé TLS n’a pas eu lieu dans le délai signifie qu’un premier paquet est parti et que rien d’utilisable n’est revenu, ce qui pointe vers le chemin. Un rejet de certificat n’y ressemble pas du tout : une réponse arrive, puis une erreur de vérification précise en nomme la raison. Notez la dernière ligne avant la boucle de nouvelle tentative, car c’est la valeur que vous comparez entre réseaux.

Capturez pendant la nouvelle tentative, pas après. Sur le client, tcpdump -ni any udp port 1194 montre si une réponse revient. Répétez-le sur l’interface WAN d’un serveur que vous contrôlez, ce qui révèle si ces paquets atteignent l’extrémité distante.

Le trafic unilatéral est le résultat le plus utile disponible ici, parce qu’il transforme une plainte intermittente en direction à investiguer. Conservez les fichiers de capture, car le prochain rapport du même problème se clôt plus facilement avec des preuves qu’avec une description.

Filtrage UDP contre port fermé

Beaucoup de réseaux d’accès jugent l’UDP soutenu suspect, et certains fournisseurs sont d’accord. Un port fermé produit le même silence côté client. La différence est la sélectivité : un filtre a tendance à trier quelles destinations ou quels ports il abandonne, alors qu’un port fermé refuse tout ce qui vise ce port unique.

Un profil TCP sur le port 443 est le contournement habituel, parce qu’il ressemble à un flux HTTPS ordinaire et passe la plupart des portails captifs et des filtres de sortie. Deux conditions doivent être réunies. Le serveur doit écouter avec proto tcp-server et le client doit correspondre avec proto tcp-client, et l’opérateur doit publier ce point de terminaison alternatif. Réécrire un profil UDP qui fonctionne pour revendiquer TCP 443 ne mène nulle part quand personne n’écoute à l’autre bout.

Un port fermé est un problème de configuration et non de censure. Un serveur derrière une box domestique a besoin que son port UDP soit redirigé, et le pare-feu de la box doit l’autoriser. Quand le port n’a jamais été autorisé, chaque client échoue à la négociation quels que soient les identifiants, et la panne suit le serveur plutôt que le réseau.

Les protocoles plus anciens se comparent mal sur cet axe. PPTP a besoin de TCP 1723 plus GRE, et GRE est le protocole IP 47 et non un port, donc aucune redirection de port ordinaire ne l’exprime.

Quand c’est le commutateur qui jette les paquets

Un commutateur administré peut jeter le tunnel exprès. Certains modèles HPE et Aruba exposent une commande de protection contre les inondations UDP, parfois libellée Prevent UDP Blat Attack, dans leur section de sécurité avancée. Une fois cette commande active, un serveur derrière le commutateur ne répond plus rien et chaque client expire de la même façon. La désactiver et enregistrer la configuration en cours, c’est toute la réparation, mais seulement après avoir établi que le commutateur est réellement sur le chemin.

Les preuves contraires sont ce qui sépare une chute due au commutateur d’un blocage opérateur. Lisez les compteurs d’interface et le journal de protection contre les inondations avant d’ouvrir un ticket chez le fournisseur. Les routeurs grand public avec protection DoS ou anti-inondation échouent de la même manière, et tout intermédiaire avec un délai d’inactivité UDP court aussi. Une poignée de main qui ne se termine jamais suggère une chute, tandis qu’un tunnel qui meurt après des minutes de silence suggère le délai d’expiration.

Notez chaque appareil entre le client et le serveur avant de changer de profil. Une correction appliquée à la mauvaise couche paraît juste jusqu’au réseau suivant. Cette liste dit aussi au prochain ingénieur où regarder sans refaire toute l’enquête.

Un chevauchement d’adresses qui ressemble à une panne DNS

Un réseau d’accès numéroté dans 10.0.0.0/8 peut chevaucher le bassin du tunnel, et le résolveur habite généralement dans ce bassin. Quand un portable reçoit une adresse comme 10.184.178.50 avec un masque /8 en Wi-Fi, toute destination 10.x est locale par définition. Les paquets pour 10.4.0.1 vont alors au LAN, le tunnel reste debout et la résolution de noms échoue.

ip addr expose le chevauchement d’un coup d’œil, et ip route get 10.4.0.1 montre où le paquet serait réellement livré. Comme le symptôme visible est une panne du résolveur, ce cas survit souvent à plusieurs rondes de changements DNS.

Renumérotez le bassin ou gardez ce réseau d’accès hors périmètre. Aucun réglage côté client ne se remet d’un chevauchement.

Choisir entre un TCP de secours et une correction du chemin

Choisissez le TCP de secours quand vous ne contrôlez pas le chemin et que les utilisateurs doivent travailler aujourd’hui, et acceptez ses coûts : TCP dans TCP se comporte mal sur les liens avec pertes, et le secours demande un écouteur que vous exploitez. Choisissez la correction du chemin quand le blocage se trouve sur une infrastructure qui vous appartient, car une règle de pare-feu coûte moins qu’un second écouteur. Dans tous les cas, parcourez les couches dans l’ordre : lien, transport externe, négociation, routage interne. L’étape qui a échoué sur ce réseau est le seul fait qui compte.

Enregistrez le résultat par réseau plutôt que par utilisateur. Le prochain rapport de la même panne part alors d’une étape connue au lieu d’une théorie sur les certificats. Cet enregistrement est aussi ce qui justifie un second écouteur permanent, si un jour il en faut un.