Le TCP 443 aide-t-il vraiment ? Seulement si le serveur écoute là

Le TCP 443 est une solution de repli avec une condition préalable, pas un déguisement qui fait passer un tunnel à travers n’importe quel filtre. Il aide quand l’opérateur publie déjà un écouteur TCP sur ce port et que le chemin tolère une connexion qui reste ouverte pendant des heures. Il échoue, souvent en délai d’attente, quand l’une des deux manque, et le délai d’attente dit rarement laquelle. Décider de changer demande trois questions, et une seule porte sur le numéro de port.

Un numéro de port n’est pas une promesse de transport

Un port nomme une extrémité ; le TCP en fait un flux d’octets ordonné ; OpenVPN décide de ce qui circule dans ce flux. Un serveur web sur le même numéro utilise une organisation applicative complètement différente, si bien que partager le port 443 rend les deux semblables pour un filtre et rien de plus. Le numéro est un indice que lit un filtre, pas une propriété qui change ce que contiennent les paquets. Les traiter comme identiques parce qu’ils partagent un port est l’erreur derrière l’essentiel de la confusion ici.

Les boîtiers intermédiaires prennent rarement une décision simple d’autoriser ou de refuser sur un port. Beaucoup inspectent les premiers octets, certains épinglent une destination, et d’autres réinitialisent les connexions qui restent ouvertes trop longtemps. C’est pourquoi le même profil peut fonctionner depuis un réseau et expirer depuis un autre, et pourquoi une solution de repli mérite d’être testée comme une option prise en charge plutôt que crue sur parole. Quand un filtre examine le trafic, le numéro de port n’est que la première chose qu’il regarde.

Confirmez l’écouteur avant de toucher au profil

Le serveur doit être configuré pour TCP sur le port, et le profil du client doit demander le même transport. Réécrire un profil UDP pour demander TCP ne crée pas l’écouteur, et le délai d’attente qui en résulte ne se distingue pas d’un pare-feu qui rejette le port. Téléchargez le profil TCP propre à l’opérateur quand il en existe un, car certains services publient une extrémité et des réglages d’identité distincts pour chaque transport. L’édition à la main convient à un test contrôlé et reste une mauvaise façon de deviner la configuration voulue par un fournisseur.

Les deux côtés de cette correspondance figurent dans la configuration, et les options de liaison du projet OpenVPN documentent les deux formes. Le couple minimal ressemble à ceci :

# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443

Trois conditions décident si le repli en vaut la peine

La première condition est que l’opérateur propose le transport tout court ; sans cela, rien d’autre ne compte. La deuxième est que le chemin maintienne une session de longue durée, car certains réseaux réinitialisent les connexions qui restent ouvertes au lieu de bloquer le port d’emblée. La troisième est de savoir si le repli est une exception délibérée ou un bricolage qui cache une panne que vous n’avez pas corrigée.

Chaque condition a une vérification peu coûteuse. Un échec sur l’une d’elles se voit de la même façon côté client :

Avant de comparer les transports, terminez toute connexion à un portail captif. Un réseau qui n’a pas admis votre appareil bloque les deux transports, et la comparaison mesure alors le portail plutôt que le tunnel. Connectez-vous, confirmez que la navigation ordinaire fonctionne, et seulement ensuite lancez le test.

Le coût que vous acceptez : TCP dans TCP

Le TCP retransmet les segments perdus et préserve leur ordre. Quand une application qui utilise aussi TCP tourne dans un tunnel TCP, deux couches de récupération réagissent à la même perte, et c’est cette interaction qui rend le tunnel lent sur un chemin avec pertes. Le symptôme est un délai et une gigue plutôt qu’une défaillance nette, ce qui facilite le blâme de l’extrémité distante. Mesurez depuis le client avec les deux transports avant de conclure.

L’UDP évite cette imbrication, et c’est la raison principale pour laquelle les opérateurs le préfèrent et ne proposent TCP qu’en alternative. Une connexion TCP stable reste plus utile qu’une connexion UDP inaccessible, donc la comparaison se fait entre deux coûts réels et non entre une bonne et une mauvaise option. Gardez l’appareil et le réseau d’accès stables pendant la comparaison, sinon le résultat décrit la mauvaise variable.

Certaines fonctions du client ne sont documentées que pour un transport, si bien qu’un profil de repli peut perdre en silence un comportement dont vous dépendiez. Lisez l’exigence de transport de l’option avant de traiter le profil TCP comme un simple échange.

Les pannes qu’un autre transport ne touche pas

Un certificat expiré a toujours besoin d’une vérification d’horloge ou d’un renouvellement, et un compte refusé a toujours besoin des bons identifiants. Conservez les contrôles d’identité du serveur fournis par l’opérateur, car un numéro de port familier n’authentifie personne. Un port qui répond dit seulement que quelque chose écoute.

Si le tunnel monte et que les destinations échouent encore, le problème restant est le routage ou la résolution de noms après la connexion, pas le transport. Suivez ce chemin au lieu de faire le tour des ports, car c’est ainsi qu’un après-midi disparaît. Le profil vous dit quel transport essayer ; il ne vous dit jamais pourquoi le chemin UDP a échoué.