Comment la traversée NAT encapsule l’ESP dans UDP

Deux clients derrière le même routeur parlent à une seule passerelle IPsec, et l’un n’arrête pas de tomber pendant que l’autre reste connecté. L’ESP natif est le protocole IP 50 sans ports, donc un traducteur n’a rien sur quoi indexer une correspondance quand plusieurs clients partagent une adresse. La traversée NAT comble cette lacune en encapsulant l’ESP dans UDP sur 4500, et cet en-tête explique la plupart des symptômes qui suivent. Il désigne aussi l’équipement à modifier.

Pourquoi le plan de données passe au port 4500

Lors de la configuration, IKEv2 compare les adresses et les ports que chaque côté croit utiliser, en échangeant des empreintes dans ses notifications de détection NAT. Quand les empreintes diffèrent, un traducteur se trouve quelque part sur le chemin, et les deux pairs basculent le trafic protégé vers l’encapsulation UDP. C’est pourquoi une session qui a rencontré un traducteur ne ressemble pas à une session qui n’en a pas rencontré.

L’enveloppe est un emballage, pas un changement de protocole : L’ESP conserve son en-tête, son contrôle d’intégrité et son chiffrement, et UDP ne fournit que les ports dont le traducteur a besoin. Le port 500 transporte l’échange IKE ; le 4500 transporte les données encapsulées après la détection, et souvent aussi les messages IKE ultérieurs. Aucun des deux ports ne transforme le flux en connexion TCP, une hypothèse qui trompe la plupart des gens qui lisent une capture.

Vérifiez les deux étapes dans l’ordre

Prouvez d’abord l’échange de contrôle, puis le chemin de données, et gardez les deux séparés dans vos notes. Une capture qui montre du trafic sur 500 et jamais sur 4500 signifie généralement que le chemin de données est filtré, donc la correction relève de la règle du pare-feu et non du client.

Surveillez les deux ports avec tcpdump -ni any 'udp port 500 or udp port 4500', et lisez la table de traduction du routeur pendant qu’une session est active. Cette table montre le port source que la passerelle verra réellement, et une capture sur l’ordinateur portable diffère par conception : l’ordinateur croit 500 tandis que la passerelle voit 4500 avec un port source traduit, et les deux ont raison. Le même flux, avant et après la traduction :

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

Symptômes que l’enveloppe explique, et deux qu’elle n’explique pas

Un routeur qui autorise l’échange de contrôle et bloque les données encapsulées produit le rapport « tunnel monté, rien ne passe ». Les tables de correspondance expirent, donc une session inactive a besoin du trafic de maintien que les pairs envoient exprès, et ces paquets ne sont pas des contrôles de santé. Quand plusieurs clients derrière une passerelle échouent ensemble, examinez la traduction de cette passerelle et toute ancienne fonction de passage direct. L’enveloppe n’explique ni une application qui échoue pour tous les clients après le montage du tunnel, ni un avertissement de certificat sur une page de blocage ; les deux se situent au-dessus de cette couche.

Lisez la table de correspondance pour deux clients à la fois : si les deux affichent le même port traduit, l’équipement ne les sépare pas comme la passerelle l’exige. Un mode de passage direct qui remet l’ESP natif à un seul hôte n’équivaut pas à servir plusieurs clients traduits, même si les fournisseurs décrivent les deux comme compatibles avec IPsec. Le double NAT ajoute une couche de correspondance et un autre point d’expiration, mais il ne coupe pas automatiquement les connexions sortantes.

Le trafic de maintien mérite sa propre ligne dans le manuel d’exploitation, car c’est lui qui garde le chemin de retour ouvert pendant les périodes d’inactivité. Activez-le là où le fournisseur le documente, et vérifiez-le en premier quand une session meurt après quelques minutes de silence plutôt qu’à la première utilisation.

Changez le propriétaire de la correspondance, puis retestez

Suivez les réglages de traversée NAT pris en charge sur les deux pairs au lieu de deviner un port. Modifier le port source local sur un client ne peut pas changer le service qui écoute à l’autre extrémité, et cela casse généralement la correspondance déjà établie. Si le client se trouve derrière un équipement que vous ne contrôlez pas, le changement appartient à son propriétaire.

Après tout changement, répétez les deux contrôles d’étape et confirmez qu’un paquet de données passe, pas seulement que l’écran d’état est devenu vert. Consignez les tuples, la sortie de la table de correspondance et le changement de règle dans une seule note, pour que la personne suivante ne reparte pas de l’échange de contrôle. Les notes de strongSwan sur la traversée NAT couvrent l’encapsulation et les réglages de maintien derrière les deux étapes.