L’hôte joint le pair IPsec, pas le conteneur Docker

Vous pinglez l’hôte distant depuis la machine Linux et il répond, donc le tunnel fonctionne. Le conteneur voisin expire toujours, et l’étape suivante naturelle est de redémarrer Docker. Un conteneur sur un réseau pont démarre généralement avec une autre adresse source et entre dans l’hôte par forwarding plutôt que par le chemin de sortie propre à l’application de l’hôte, donc le test réussi a mesuré un autre paquet. Pour un tunnel strongSwan basé sur des politiques, une route ordinaire vers le sous-réseau distant ne suffit pas quand le paquet transféré ne correspond pas à la politique IPsec installée.

Le parcours ci-dessous suit une destination à travers deux sources, en lisant l’état avant de changer quoi que ce soit.

Partez d’une destination et de deux sources

Choisissez d’abord un service connu par IP, pour ne pas déboguer DNS en même temps. Notez trois faits : le préfixe pont du conteneur, l’adresse source de la requête de l’hôte qui a fonctionné, et les sélecteurs de trafic local et distant négociés pour le tunnel. Ces trois nombres expliquent presque tous les cas de ce symptôme.

Répétez ensuite la requête échouée depuis l’intérieur du conteneur et capturez la source qu’il utilise réellement. Si cette adresse n’est pas couverte par le sélecteur local, vous connaissez déjà le résultat, et aucune recréation du conteneur ne le changera.

Lisez les politiques avant de toucher à Docker

Les vérifications d’hôte en lecture seule couvrent les décisions de routage, la base de politiques et les règles qui choisissent entre elles :

ip rule show
ip route show table all
ip xfrm policy

La liste des politiques montre les sélecteurs et la direction sans avoir besoin d’un vidage d’état IPsec plein de matériel de clé, c’est pourquoi il est sûr de la coller dans un ticket. Cherchez un sélecteur local qui couvre l’adresse de l’hôte mais pas le préfixe pont. Vérifiez aussi le chevauchement : une route de conteneur qui traite la destination distante comme locale ne produira jamais le paquet transféré attendu, et le tunnel est blâmé. Gardez cette liste à côté de l’adresse source du conteneur, car ces deux éléments ensemble constituent toute la comparaison.

Si le préfixe du conteneur manque, arrêtez-vous et décidez l’architecture avant de modifier autre chose. Le reste de ce parcours suppose que vous avez convenu quelle adresse source doit apparaître sur le fil.

Vérifiez le filtrage puis la traduction

Le pare-feu pont Linux de Docker peut bloquer le forwarding indépendamment d’IPsec. Avec le backend iptables, inspectez le chemin FORWARD et les décisions DOCKER-USER, en gardant à l’esprit qu’une règle ajoutée après un verdict antérieur peut ne jamais s’exécuter. Le backend nftables s’intègre différemment, donc ne créez pas une chaîne DOCKER-USER simplement parce qu’un exemple iptables l’a nommée ; vérifiez quel backend votre démon utilise réellement.

Vérifiez ensuite la traduction de source. Une règle MASQUERADE large peut transformer un paquet qui correspondait auparavant à un sélecteur IPsec en un paquet qui n’y correspond plus, et la panne ressemble exactement à un problème de routage. Le guide de forwarding de strongSwan documente l’exemption NAT nécessaire avant une telle traduction pour le trafic déjà conforme à une politique.

Cette exemption n’est pas un moyen d’ajouter au tunnel une source de conteneur non couverte. Elle ne protège que le trafic qui correspond déjà à la conception, alors réglez d’abord les questions de sélecteur et de chemin de retour, puis faites concorder NAT et filtrage avec la réponse. Si vous vous surprenez à élargir l’exemption, c’est le sélecteur qu’il faut changer, pas la règle NAT.

Décidez ensuite routé ou traduit

Un sous-réseau de conteneur routé exige que les deux pairs acceptent ce sous-réseau et qu’un chemin de retour distant y mène, ce qui implique généralement un changement de sélecteur aux deux extrémités et une conversation avec le propriétaire du côté distant. Une conception délibérément traduite doit au contraire présenter une adresse couverte par la politique à l’étape de recherche pertinente, ce qui implique généralement une règle étroite et documentée plutôt qu’un MASQUERADE par défaut.

Aucune des deux dispositions ne découle automatiquement du tunnel fonctionnel de l’hôte, et choisir entre elles est une décision de conception avec un responsable. Notez laquelle vous avez choisie, car sinon l’ingénieur suivant la redéduira des compteurs du pare-feu.

Surveillez aussi la panne hybride : la moitié du jeu de règles traduite et l’autre non, ce qui produit un succès intermittent dépendant du port de destination et non de quoi que ce soit sur le réseau.

Vérifiez avec une connexion neuve, pas avec un redémarrage

Utilisez une connexion applicative neuve en observant des compteurs de pare-feu étroits et le récepteur distant, afin que chaque observation ait une source. Un redémarrage de Docker peut changer l’état des règles et perturbera aussi les charges de travail, ce qui vous coûte le signal propre que vous cherchiez.

Le résultat durable tient en quatre affirmations que vous pouvez montrer : la source du conteneur, le chemin protégé correspondant, le forwarding autorisé et une réponse qui revient. Quand les quatre tiennent, le conteneur joint le pair pour la même raison que l’hôte.