NAT symétrique et VPN : mesurez le mappage, pas l’étiquette

Un fil de support se termine par le verdict « NAT symétrique, le VPN ne fonctionnera pas ici », et le client est ensuite réinstallé trois fois sans raison. L’étiquette fait des dégâts parce qu’elle répond à une question que personne n’a posée. Un client qui se connecte vers l’extérieur à un serveur fixe crée un mappage dès qu’il envoie le premier paquet, et la réponse est autorisée à revenir selon des règles que presque tous les réseaux appliquent. Ce que le mappage dépendant de l’extrémité complique réellement, c’est deux pairs qui tentent de s’atteindre en même temps, et c’est un autre test.

Deux questions se cachent derrière une étiquette

La première question est de savoir si un hôte derrière ce réseau peut ouvrir une session vers une adresse publique et un port connus. Pour un client tunnel, c’est le cas normal, et la réponse est presque toujours oui. Le routeur enregistre la source interne, attribue un port externe et laisse passer la réponse parce qu’elle appartient à une session commencée de l’intérieur.

La seconde question est de savoir si deux hôtes derrière des réseaux différents peuvent découvrir un chemin partagé et s’envoyer des paquets sans serveur au milieu. Cela dépend de la manière dont chaque réseau attribue ces ports externes, et c’est le seul endroit où le comportement du mappage compte.

Confondre les deux produit le diagnostic erroné classique : une fonction entre pairs échoue, quelqu’un lance un test de type NAT, voit la pire catégorie et conclut que le tunnel ordinaire ne peut pas fonctionner non plus. Le tunnel n’a jamais été ce qui a échoué.

Mappage et filtrage sont deux propriétés distinctes

La terminologie du RFC est plus précise que les noms employés par les fournisseurs, et elle vaut la peine d’être reprise dans le ticket parce qu’elle tranche les débats. Le mappage est la manière dont le port externe est attribué. Le filtrage est la question de savoir quels paquets entrants sont autorisés à passer. Un réseau peut être strict sur l’un et libéral sur l’autre, et c’est cette combinaison qu’un protocole entre pairs doit survivre.

La troisième ligne est ce que la plupart des routeurs grand public et des opérateurs mobiles entendent par symétrique. Notez que l’étiquette ne décrit que l’attribution. Un réseau doté de ce mappage et d’un filtrage libéral peut encore accepter des paquets entrants vers le port qu’il vient d’attribuer, et c’est pourquoi le perçage de trous réussit sur certains et échoue sur d’autres.

Le filtrage a ses trois cas et son nom propre pour chacun. Écrire « NAT symétrique » dans un ticket quand on veut dire « filtrage dépendant de l’adresse et du port » envoie la personne suivante au mauvais chapitre du manuel. Les deux se comportent différemment à l’essai, donc l’erreur n’est pas académique.

Mesurez le mappage au lieu de le nommer

Vous pouvez observer le port attribué directement depuis le côté serveur de tout service UDP que vous contrôlez. Lancez une capture sur l’hôte public, envoyez depuis le client et lisez le port source avec lequel le paquet est arrivé :

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

La ligne d’extrémité est la plus utile des trois, parce que WireGuard enregistre la dernière adresse et le dernier port reçus de chaque pair. Comparez ce port à celui que le client croit utiliser. Ils différeront chaque fois qu’une traduction a lieu, et la question importante est de savoir si la valeur reste stable.

Répétez l’observation vers un second port de destination ou un second serveur et comparez de nouveau. Si le port externe change selon la destination, le mappage dépend de l’adresse et du port. S’il reste identique, le réseau vous donne un seul mappage et la découverte a une chance.

Les outils fondés sur STUN rapportent la même classification en une étape, et ils sont utilisables quand le réseau autorise l’UDP sortant vers un serveur STUN public. Quand ce n’est pas le cas, la méthode de capture ci-dessus fonctionne toujours et ne demande rien d’autre qu’un hôte que vous contrôlez déjà.

Choisissez un correctif adapté à la panne

Si la fonction qui échoue est entre pairs, les réponses prises en charge sont un relais, un service de rendez-vous que les deux pairs peuvent joindre, ou une topologie différente. TURN existe exactement pour cela, et un produit qui embarque son propre relais vous dit qu’il s’attend à ce que certains réseaux soient hostiles.

Si la fonction qui échoue est un tunnel ordinaire, le comportement du mappage n’est pas votre problème et rien de ce qui précède ne s’applique. Vérifiez que le client émet réellement, que le serveur voit le paquet et que la réponse revient. Cette séquence représente trois observations et n’exige aucune connaissance de la catégorie NAT du routeur.

Ce qui ne fonctionne pas, c’est de disperser des changements de port local jusqu’à ce que quelque chose se connecte. Changer le port source du client ne change pas la façon dont le réseau attribue les mappages. Un succès fortuit au cinquième essai est un faux positif, et il sera cité comme correctif pendant des mois.

Consignez l’architecture, pas le verdict

Une note utile indique quel protocole, dans quel sens la session commence, si un relais est sur le chemin et ce qui a été observé sur le fil. « NAT symétrique, ne fonctionne pas » est inutilisable, parce que c’est à la fois faux sur le tunnel et muet sur le chemin entre pairs.

Incluez la stabilité du port mesurée et le comportement du filtrage si vous les avez testés. Ces deux faits permettent à quelqu’un d’autre de prédire si une nouvelle fonction fonctionnera sur ce réseau sans refaire toute l’enquête. Ils vieillissent aussi mieux qu’une catégorie de fournisseur qui signifie quelque chose de légèrement différent sur chaque page d’aide.

Enfin, gardez la terminologie du RFC 4787 à portée de main quand vous rédigez. Employer les termes précis coûte une phrase et évite au lecteur suivant de répéter le même diagnostic erroné, et c’est tout l’intérêt d’écrire la note.