Mode trap de strongSwan : pourquoi le tunnel IPsec attend du trafic

Un tunnel IPsec inactif à la demande n'affiche aucun CHILD SA tant qu'un paquet ne correspond pas à sa politique trap. Lisez l'état, vérifiez le déclencheur et sachez quand start convient.

Aucun CHILD SA n'apparaît dans la sortie d'état, le tunnel semble mort, puis un ping vers le sous-réseau distant le remonte. Dans une configuration IPsec à la demande, cette séquence est le fonctionnement prévu, pas une panne. Une politique trap installe un sélecteur et attend, et le premier paquet qui correspond est ce qui démarre IKE et la négociation du CHILD SA.

Une partie de la confusion tient au vocabulaire : « up » sert pour deux états différents. La configuration est chargée et la politique du noyau existe, mais pas l'association de données. Un moniteur qui ne compte que les SA actives signalera un site sain comme hors service tant que personne ne lui envoie de trafic.

Un tunnel inactif à la demande n'a aucun CHILD SA à montrer

Une entrée trap n'authentifie rien à elle seule. Elle demande au noyau de conserver une politique pour le trafic sélectionné et de lever une acquisition lorsqu'un paquet a besoin de cette politique. Le démon reçoit l'acquisition, l'associe à la définition child et négocie à partir de là. Jusque-là, il n'y a pas non plus d'IKE SA à afficher, ce qui explique que les deux listes puissent être vides en même temps.

C'est cet ordre qui rend les journaux lisibles. L'acquisition arrive d'abord, puis IKE_SA_INIT et IKE_AUTH, puis le CHILD SA. Si le journal s'arrête juste après l'acquisition, le déclencheur a fonctionné. La négociation a échoué, et la question suivante porte sur les identifiants, les propositions ou l'accessibilité, pas sur le trap.

Avec le backend noyau Linux, vous pouvez voir la politique avant qu'aucune SA n'existe. Lancez ip xfrm policy et cherchez le sélecteur avec la direction out et un modèle pointant vers la connexion. Cette entrée est l'état à la demande, et sa présence est la première chose à confirmer.

start_action décide si quoi que ce soit attend

Chaque child dans swanctl.conf porte un start_action. start démarre au chargement de la configuration, trap installe la politique et attend, et none laisse le démarrage à autre chose. Seul trap produit le comportement « ping et ça monte » décrit ci-dessus.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Les deux sélecteurs de trafic définissent ce qui compte comme intéressant, et un paquet d'un hôte hors de ces préfixes ne déclenche pas le trap ; il est routé normalement. Élargir les sélecteurs pour rendre le déclencheur plus empressé élargit aussi la portée que le tunnel prétend protéger, alors dérivez-les du trafic que vous voulez réellement chiffrer.

La référence swanctl.conf liste les valeurs acceptées, ainsi que les actions distinctes close et DPD qui régissent ce qui se passe une fois la SA existante.

Déterminez si le déclencheur s'est activé

Commencez par swanctl --list-conns et confirmez que le child est chargé avec l'action voulue. Envoyez ensuite un paquet depuis un hôte situé dans local_ts vers une adresse située dans remote_ts et observez swanctl --list-sas. Si la sortie ne change pas, aucune acquisition n'a atteint le démon.

Deux raisons courantes d'un trap silencieux : le paquet a subi un source-NAT avant d'atteindre la politique et ne correspond plus à local_ts, ou la connexion ne s'est jamais chargée à cause d'une erreur de syntaxe ou d'identifiants. Relancez swanctl --load-all et lisez sa sortie avant de toucher aux sélecteurs. Une connexion qui n'a pas été chargée n'installe aucune politique, il n'y a donc rien que le trafic puisse déclencher.

Le sens compte aussi : un trap installé pour le trafic sortant ne démarre pas sur un paquet entrant. Si le côté distant doit monter le tunnel, il lui faut son propre trap, ou ce côté a besoin de start.

Attendre le premier paquet n'est pas toujours le bon compromis

Les sessions interactives ressentent le coût de la mise en place. La première requête paie l'échange IKE et la négociation CHILD, et un client à échéance courte peut abandonner avant que la SA existe. Un start proactif supprime ce délai du premier paquet. Mais il maintient un tunnel ouvert pour du trafic qui n'arrivera peut-être jamais.

Trois faits tranchent le choix : la fréquence d'usage du chemin, l'échéance serrée ou non de la première requête, et l'accessibilité du pair au démarrage. Du trafic par lots occasionnel et un pair parfois hors ligne au démarrage favorisent tous deux trap. Un client sensible à la latence et un pair toujours joignable favorisent start. Si les deux côtés peuvent initier, convenez de qui possède le déclencheur pour éviter des négociations en double.

Une politique installée n'est pas non plus une garantie étanche. Si l'exigence est fail-closed, le pare-feu doit supprimer le trafic sans SA, et cette règle vit hors de la définition child.

Notez les trois lignes qui cloront la prochaine discussion

Écrivez les sélecteurs, l'action de démarrage et la sortie de commande qui montre la politique présente sans SA. Ces trois lignes séparent « à la demande et inactif » de « ne se charge pas » la prochaine fois que quelqu'un signale le tunnel comme hors service. Elles prennent une minute à consigner. Sans elles, la même enquête repart de zéro.

Testez depuis un hôte réellement situé dans le sélecteur. Un ping depuis le routeur lui-même suit souvent un autre chemin et ne prouve rien sur la politique qui protège le sous-réseau derrière lui.

Articles similaires