Le FAI bloque-t-il l'UDP, ou est-ce l'application dans le tunnel ?

Quelqu'un signale que le VPN « bloque l'UDP », et cette phrase cache deux affirmations complètement différentes. L'une porte sur le transport que le réseau d'accès peut voir, l'autre sur les paquets d'une application après leur déchiffrement à l'intérieur du tunnel. Un tunnel chiffré peut être filtré de l'extérieur sans aucune clé, et une application UDP interne peut échouer pour des raisons qui n'ont rien à voir avec le filtrage. Décidez quelle affirmation vous testez avant de rassembler des preuves.

Deux en-têtes, un mot

Dans un déploiement IPsec avec NAT-traversal, le paquet externe est UDP, adressé entre les deux extrémités du VPN, généralement sur le port 4500. À l'intérieur, la charge utile chiffrée transporte tout ce que le tunnel achemine, ce qui peut être lui-même TCP ou UDP. Le mot UDP apparaît donc deux fois, avec des sens et une visibilité différents.

Un réseau intermédiaire voit l'en-tête externe et rien de l'interne. Il peut autoriser, façonner ou abandonner le flux externe, et il n'a besoin de déchiffrer quoi que ce soit pour cela. Cette asymétrie est toute la raison pour laquelle les deux affirmations se confondent : le même mot décrit ce que le réseau filtre et ce que l'application envoie. Notez la couche à côté du mot chaque fois que vous consignez un constat, et la confusion disparaît en grande partie.

L'en-tête interne ne devient visible qu'à l'extrémité réceptrice, après déchiffrement. À partir de là, le paquet est acheminé comme n'importe quel autre, selon les routes, la politique et le filtrage propre à l'extrémité. Ce sont des décisions distinctes prises par des équipements différents.

Ce que le réseau peut encore voir

Le chiffrement masque la charge utile et l'en-tête de transport interne, pas le fait qu'un flux existe. Les adresses des extrémités, les ports, la taille des paquets et le minutage restent visibles, et cela suffit pour classer le trafic de façon heuristique ou pour bloquer une destination précise.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

La première capture montre le flux externe sur l'interface physique, et la seconde le flux interne sur l'interface du tunnel. Lancer les deux en même temps répond directement à la question : si le flux externe existe et que l'interne n'existe pas, l'application n'a jamais rien envoyé dans le tunnel. Si les deux existent et que rien ne revient, le problème est au-delà du tunnel, à la destination ou sur le chemin de retour.

RFC 3948 définit l'encapsulation UDP externe, et la spécification ESP définit la disposition protégée à l'intérieur. Aucun des deux documents ne promet qu'un réseau d'accès laissera passer le flux externe, c'est pourquoi un test d'accessibilité sur le tuple externe vaut la peine d'être exécuté avant toute théorie sur l'interne. Un tuple externe bloqué produit un tunnel qui ne se forme jamais, pas un tunnel qui se forme puis perd une application.

Pourquoi une application UDP échoue dans un tunnel qui fonctionne

Un tunnel qui transporte une application web mais pas une application UDP a plusieurs explications plausibles, et le filtrage du protocole interne par le FAI n'est pas la première. La plus courante est la couverture : les deux applications n'entrent pas toutes les deux dans le même tunnel, parce que la route vers la destination UDP manque ou que les règles de tunnel divisé du client l'excluent.

La deuxième est l'extrémité. Un serveur VPN qui autorise une liste de protocoles, un pare-feu à la destination ou un service qui n'écoute jamais sur le port attendu produiront tous un délai d'attente qui ressemble exactement à un blocage réseau.

La troisième est la taille des paquets. Les applications UDP envoient souvent des datagrammes plus gros qu'une requête web, et l'encapsulation réduit la MTU utilisable, si bien qu'après une poignée de main réussie le silence peut suivre sur la première charge utile de taille maximale. Ce schéma se lit facilement comme un blocage, parce que les petits paquets passent et les gros disparaissent. Une sonde MTU rapide règle la question en moins d'une minute, et la réponse est généralement une charge utile plus petite ou un MSS corrigé plutôt qu'un filtre réseau.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

La première commande vérifie si un gros paquet survit au chemin avec la fragmentation désactivée, ce qui expose rapidement un problème de MTU. La seconde envoie un flux UDP petit et borné et rapporte les pertes et la gigue. Un flux qui démarre puis cale pointe vers la taille plutôt que vers un blocage.

Signalez la couche, pas le protocole

Écrivez le constat sous l'une des trois formes : acheminement externe échoué, transfert interne échoué, ou application échouée. Chacune a un responsable différent, et les mélanger envoie le ticket à la mauvaise équipe.

Changer un port local ne peut pas créer un écouteur correspondant à l'autre bout, donc un contournement côté client qui semble aider est généralement la preuve que la destination d'origine était erronée. De même, un profil alternatif fourni prouve quelque chose sur l'accessibilité et rien sur la bonne configuration de l'application.

Gardez aussi l'inférence séparée de l'observation. L'analyse de trafic peut suggérer ce qu'est un flux sans le déchiffrer, et c'est un constat utile, mais ce n'est pas la même affirmation que lire l'en-tête interne. Précisez laquelle vous avez réellement.