Sélecteurs de trafic IPsec : ce qu’ils couvrent et ce qu’ils ne couvrent pas

Les sélecteurs de trafic nomment le trafic interne qu’un accord IPsec protège, et la paire est négociée plutôt que supposée. Deux extrémités peuvent parfaitement s’authentifier l’une l’autre et malgré tout ne pas être d’accord sur les paquets qui appartiennent à l’intérieur du tunnel. Ce désaccord est invisible dans l’état de la connexion, qui signale généralement un tunnel sain. Lire les sélecteurs des deux extrémités, puis suivre une destination, le trouve plus vite que n’importe quelle quantité d’édition de politique.

Lisez-les des deux extrémités

Chaque extrémité décrit son propre côté comme local et l’autre côté comme distant. La même paire de préfixes apparaît donc inversée dans les deux configurations, et c’est correct et non contradictoire. Inverser la perspective est la première chose à faire quand un accord qui fonctionne semble faux sur le papier. Comparer deux fichiers côte à côte sans les inverser produit une incohérence qui n’existe pas.

Les valeurs ne sont pas toujours des sous-réseaux uniques. Les sélecteurs IKEv2 peuvent porter des plages d’adresses, des numéros de protocole et des plages de ports, et c’est ainsi qu’une politique protège un service au lieu d’un réseau entier. Un sélecteur plus étroit que le trafic prévu produit un tunnel qui transporte certaines destinations et en exclut d’autres en silence.

Écrivez les deux côtés dans un seul tableau avant de changer quoi que ce soit. L’exercice règle généralement la question sans toucher à un fichier de configuration.

Le rétrécissement est la décision du répondeur

Un initiateur propose, et le répondeur ne peut accepter qu’un sous-ensemble. IKEv2 permet au répondeur de rétrécir les sélecteurs de trafic proposés, et le résultat rétréci est ce qui est réellement installé. Lire la configuration de l’initiateur décrit donc une offre, pas l’accord.

C’est pourquoi un sous-réseau ajouté au client peut produire un tunnel qui fonctionne tout en refusant la nouvelle destination. Le serveur a rétréci l’offre à ce que sa politique autorise, tandis que le fichier du client énumère encore la plage plus large. Seul l’état négocié montre la vérité : sous Linux, ip xfrm policy et la liste des child SA dans la documentation IKEv2 de strongSwan rapportent ce qui a été installé et non ce qui a été demandé. Quand les deux divergent, c’est la politique du répondeur qu’il faut changer.

Une proposition rejetée est un symptôme différent d’une proposition rétrécie. Le rejet apparaît dans le journal de négociation et ne laisse aucune association child.

Suivez une destination de bout en bout

Choisissez une destination réelle plus l’adresse source que le client utiliserait pour elle, puis suivez cette paire à travers trois décisions indépendantes. La route choisit un chemin, le sélecteur décide si ce chemin est protégé, et le pare-feu décide si le paquet est autorisé. Chacun peut échouer de son côté, et un sélecteur large ne répare aucun des autres.

ip route get 10.20.30.41
ip xfrm policy list
swanctl --list-sas

La requête de route nomme l’interface et l’adresse source qui porteraient le paquet. La liste des politiques montre si une politique de tunnel correspondante existe pour cette paire, y compris sa direction et son niveau. La liste des SA montre les sélecteurs child négociés avec les compteurs, donc une association child à zéro paquet après une tentative de trafic est la signature de sélecteurs qui excluent ce qui est envoyé. Trois commandes, trois réponses différentes, et une seule explique une chute silencieuse.

Si les compteurs child bougent alors que l’application échoue toujours, le problème se situe au-delà du tunnel. Cela déplace l’enquête vers l’écouteur ou le pare-feu de l’hôte distant plutôt que vers les sélecteurs.

Gardez les deux objectifs séparés

Protéger un sous-réseau de bureau et envoyer toute la navigation par une sortie distante sont des exigences différentes avec des sélecteurs différents. Un profil conçu pour l’un convient rarement à l’autre, et les mélanger produit soit une fuite, soit une séparation cassée. Élargir la plage protégée signifie changer les deux extrémités et leur politique de transfert, car un changement unilatéral devient une proposition rejetée. C’est la façon la plus courante dont un tunnel qui fonctionnait cesse de fonctionner après une petite modification.

Les sélecteurs décrivent la couverture cryptographique, les routes choisissent des chemins, et les applications imposent leurs propres autorisations. Un tunnel qui couvre tout ne peut toujours pas atteindre un service lié à loopback, et une route vers le tunnel a toujours besoin d’un sélecteur incluant la destination. Vérifiez les trois contre la même requête de test, et le désaccord se nomme lui-même.