L2TP/IPsec à travers NAT : ce qui casse vraiment et pourquoi

L’affirmation selon laquelle NAT casse L2TP/IPsec est à moitié vraie et donc inutile. La traduction d’adresses est normale, le traversal NAT existe précisément pour y survivre, et des millions de clients se connectent chaque jour derrière un routeur. Ce qui casse, c’est une étape précise d’un échange précis : IKE ne reçoit jamais de réponse, le tunnel encapsulé est rejeté par une politique qui n’autorise qu’un protocole, ou le mapping de traduction expire pendant que le tunnel est inactif. Une fois que vous savez à quelle étape vous êtes, le correctif est généralement une seule règle ou un keepalive, pas une nouvelle conception de VPN.

Le mythe est la mauvaise question

La question utile n’est pas « est-ce que NAT casse cela » mais « quelle partie de l’échange est traduite, et qu’en fait l’appareil qui traduit ». L2TP/IPsec est un protocole en couches : IKE négocie, ESP protège, et L2TP transporte PPP à l’intérieur de cette protection. La traduction d’adresses interagit différemment avec chaque couche, et les signatures de panne se distinguent si vous regardez l’étape de négociation plutôt que la boîte de dialogue d’erreur.

Un routeur qui navigue sur le web avec succès prouve seulement que TCP avec traduction de port source fonctionne. Il ne dit rien sur UDP 500, UDP 4500 ou le protocole 50, et ce sont ces trois choses dont dépend ce déploiement.

Étape 1 : IKE doit au moins recevoir une réponse

Le premier échange part vers le répondeur sur UDP 500. Si aucune réponse ne revient, rien d’autre n’importe : la clé prépartagée, la proposition et les identifiants restent non lus. Surveillez la requête et la réponse au lieu de déduire du délai d’attente du client :

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

Une requête sans réponse signifie généralement qu’un pare-feu ou l’opérateur en amont jette le paquet, pas que le serveur l’a rejeté. Une réponse avec une charge de notification nommant une proposition ou un problème de certificat signifie que les paquets sont arrivés et que la négociation a échoué sur le contenu, ce qui est une réparation complètement différente.

Quand les deux pairs sont derrière une traduction, l’initiateur doit seulement atteindre le répondeur, donc la plupart des déploiements côté client fonctionnent dès l’étape 1. L’hébergement côté serveur est là où commence le problème entrant, et c’est pourquoi les deux situations ne devraient jamais être traitées comme une seule.

Étape 2 : l’encapsulation change ce que voit le pare-feu

ESP est un protocole IP, pas un port TCP ou UDP, et la traduction d’adresses de ports ordinaire n’a aucun champ de port à réécrire. C’est pourquoi le traversal NAT place la charge protégée dans UDP 4500 : l’encapsulation donne à l’appareil qui traduit quelque chose qu’il sait traduire. Une fois cela fait, une règle de pare-feu écrite uniquement pour UDP 500 autorise la négociation et rejette le tunnel, ce qui produit le résultat déroutant où le journal montre une phase 1 réussie et aucun trafic.

L’échange IKE lui-même peut aussi passer sur UDP 4500 après détection d’un NAT, ce qui surprend ceux qui ont autorisé 500 et rien d’autre. Autorisez les deux ports dans les deux sens sur le chemin, et rappelez-vous qu’un pare-feu à états ne maintient le flux que tant qu’il voit du trafic.

Le protocole 50 compte encore sur les chemins sans traduction, et sur ceux où un boîtier intermédiaire est configuré pour l’autoriser. Si vous diagnostiquez par élimination, désactivez l’hypothèse au lieu d’ajouter des règles en bloc : autorisez 500, 4500 et ESP, confirmez que le tunnel monte, puis retirez ce qui s’est révélé inutile. Une règle que personne ne peut expliquer est une règle que personne ne retirera lorsqu’elle deviendra la cause de la prochaine panne. Consignez le resserrement dans le journal des changements avec l’étape qu’il a corrigée, pour que l’ingénieur suivant parte de vos preuves et non de la même règle empirique.

Étape 3 : le mapping expire et le tunnel meurt

Un appareil qui traduit conserve un état pour les flux qu’il transmet, et cet état a une durée de vie. Un tunnel L2TP/IPsec transporte peu de trafic quand personne ne l’utilise, donc un tunnel inactif peut survivre à son mapping et cesser de recevoir le trafic de retour. Le client reste convaincu d’être connecté, le serveur ne voit rien, et le premier symptôme est généralement un délai d’attente applicatif plutôt qu’une erreur VPN.

La détection de pair mort et les keepalives NAT existent pour cela, et les deux extrémités doivent être prêtes à les envoyer. Si votre serveur est derrière une traduction, l’exigence côté Windows est un réglage de registre documenté qui fait supposer au serveur une encapsulation UDP pour ses propres paquets sortants ; sans lui, le répondeur envoie de l’ESP que l’appareil qui traduit ne peut pas remapper. C’est un problème de configuration serveur, pas client.

Un changement d’adresse WAN produit le même résultat par un autre chemin : le mapping est reconstruit autour d’une nouvelle adresse, et l’ancienne association de sécurité pointe désormais vers un tuple qui n’existe plus. Le comportement de reconnexion relève de l’implémentation client, et c’est pourquoi « se reconnecter après le redémarrage du routeur » fonctionne sur un client et nécessite un interrupteur manuel sur un autre.

Héberger derrière un NAT d’opérateur est un problème différent

Si vous voulez héberger un serveur L2TP/IPsec chez vous et l’atteindre depuis l’extérieur, l’exigence est une joignabilité entrante non sollicitée, et ce n’est pas ce que fournit le traversal NAT. Un NAT d’opérateur devant votre routeur signifie qu’aucun port que vous pouvez rediriger ne vous rendra joignable, car l’adresse publique est partagée et le mapping est uniquement sortant.

Aucune case IPsec pass-through ne change cela, et aucune configuration client ne le compense. Les réponses prises en charge sont une adresse réellement joignable, un point de terminaison hébergé ou une architecture où chaque participant établit une connexion sortante. La spécification d’encapsulation UDP résout le problème de traduction pour les flux qui existent ; elle ne crée pas de chemin entrant là où l’opérateur n’en propose pas.

Comparez donc les réseaux au lieu de deviner. Emmenez le même appareil et le même profil sur un autre réseau autorisé et observez quelle étape y échoue. Si cela fonctionne ailleurs, la différence est dans le chemin, et cela réduit la recherche aux trois étapes ci-dessus plutôt qu’à toute la configuration.