strongSwan ESP-in-UDP : quand il n'y a pas de NAT à détecter

La détection de NAT trouve la traduction d'adresses, pas la politique du pare-feu. Une connexion de site sans NAT peut tout de même exiger un choix explicite d'ESP-in-UDP.

La détection de NAT répond à une question : les adresses ou les ports ont-ils changé en transit ? Elle ne dit pas si un pare-feu autorise le protocole IP 50. Des passerelles de site sans aucune traduction peuvent malgré tout se trouver derrière une politique qui rejette l'ESP natif, et cette exigence doit être configurée plutôt que découverte. Le mécanisme est ESP-in-UDP, et c'est une décision, non un repli qui apparaît de lui-même.

La détection est de l'arithmétique sur des adresses, pas une sonde de pare-feu

IKEv2 transporte des charges utiles de détection de NAT contenant des hachages des adresses et des ports source et destination. Chaque côté compare ce qu'il a reçu avec ce qu'il voit localement, et une discordance lui indique que quelque chose a traduit le paquet. Rien dans cet échange ne teste si un routeur intermédiaire achemine le protocole 50.

La conséquence pratique mérite d'être dite franchement. Un tunnel qui fonctionnait avec l'ESP natif ne découvrira pas de lui-même un pare-feu nouvellement restrictif, et sa tentative suivante échoue au stade des données alors qu'IKE continue de réussir. Vous verrez des associations de sécurité IKE établies et aucun trafic protégé, ce qui ressemble à un défaut de routage jusqu'à ce que vous capturiez sur le fil.

L'encapsulation est donc une propriété de la connexion que vous configurez, non un résultat que les pairs négocient à partir du comportement du réseau.

Comment encap change l'échange

Dans un déploiement moderne de strongSwan géré via swanctl.conf, le réglage encap = yes sur la connexion influence l'échange de détection de NAT pour que les deux pairs utilisent l'encapsulation UDP pour ESP. Les paquets protégés voyagent alors dans UDP, conventionnellement sur le port 4500, et les deux extrémités doivent s'accorder sur cette disposition.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Ce fragment appartient à une véritable définition de connexion et n'est pas un profil de site complet. Conservez les adresses des pairs, l'authentification et les sélecteurs de trafic child que vous utilisez déjà ; la seule clé ajoutée change la façon dont les données protégées sont enveloppées, pas ce qu'elles protègent.

Le guide strongSwan du NAT-traversal décrit ce comportement, y compris l'interaction avec le port flottant lorsque MOBIKE est utilisé.

Utilisez le réglage qui correspond à votre backend

strongSwan a deux backends de configuration, et la clé diffère entre eux. Une swanctl.conf connexion prend encap, tandis qu'une ipsec.conf connexion héritée prend forceencaps. Glisser le mot-clé d'un backend dans l'autre produit une configuration qui se charge sans se plaindre et ne change rien, ce qui est pire qu'une erreur.

Vérifiez quel démon tourne réellement avant de modifier quoi que ce soit. Sur de nombreuses distributions, les deux fichiers existent parce que l'un est un reliquat d'une migration antérieure, et l'actif est celui que démarre l'unité de service. Lisez cette unité au lieu de deviner d'après les horodatages des fichiers. Une vérification de cinq secondes ici évite des heures de test d'un réglage que rien n'a chargé.

Appliquez le changement via le propriétaire de la connexion et rétablissez l'association pendant une fenêtre contrôlée. Un child déjà installé conserve son encapsulation actuelle jusqu'à son remplacement, donc une simple modification de fichier ne prouve pas que la nouvelle disposition est utilisée.

Vérifiez les données enveloppées, pas seulement le port

Capturez sur la passerelle pendant que le trafic protégé circule, puis comparez cela avec la propre vue de strongSwan :

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

L'ESP natif apparaît comme protocole IP 50 et ne ressemble pas du tout à UDP. L'ESP enveloppé apparaît comme des datagrammes UDP sur 4500 dont la charge utile n'est pas IKE. Le trafic IKE sur ce même port ne prouve pas l'encapsulation, car MOBIKE peut y déplacer IKE pendant que le chemin de données reste natif, donc lisez la charge utile, pas le numéro de port.

Gardez aussi à l'esprit la MTU du chemin. L'enveloppe ajoute une surcharge, et un chemin qui transportait de l'ESP natif peut nécessiter des ajustements lorsque les paquets grossissent. Le traitement ICMP requis devrait déjà faire partie de la conception ; l'encapsulation ne supprime pas cette dépendance.

Acceptez le changement lorsque le nouveau trafic applicatif dans le tunnel est visible dans la capture comme ESP enveloppé aux deux extrémités, et lorsque le service interne et sa route de retour fonctionnent encore. Tout le reste est une configuration qui semble correcte dans un fichier.

Articles similaires