La route par défaut XFRM a avalé IKE et ESP : conservez le chemin extérieur

Le trafic est protégé, le tunnel est monté, puis il meurt à la renégociation suivante. Une route par défaut via l'interface XFRM décrivait le trafic que vous vouliez protéger. Elle a aussi avalé les paquets nécessaires pour continuer à le protéger.

Les deux destinations concernées ne sont pas interchangeables. Le routage doit le dire explicitement.

Où va réellement la recherche du pair

Notez les règles actives, la table qui contient la route XFRM et l'adresse publique du pair. Regardez ensuite le chemin que prendrait la connexion extérieure avec sa source et sa marque réelles. Une destination générique ne vous apprend rien sur ce chemin de contrôle. Seules la source et la marque réelles donnent une réponse utile.

Une connexion initiale réussie prouve aussi peu. L'échec apparaît souvent après qu'une installation de route a changé la réponse. Le démarrage réussit, puis la première renégociation échoue.

ip rule show
ip route show table 220
ip -4 route get 198.51.100.44 from 10.40.0.2
ip xfrm policy list

Si la recherche du pair aboutit dans l'interface XFRM, les paquets extérieurs sont routés vers le tunnel qu'ils construisent. C'est la boucle, visible en une seule commande.

Options d'exclusion sur une passerelle moderne

La documentation de strongSwan sur le VPN basé sur le routage présente deux réponses pratiques. L'une marque IKE et ESP pour que la règle vers la table XFRM ne les vise pas. L'autre laisse une route de pair ou une exclusion que la recherche peut encore atteindre.

Prenez celle que votre jeu de règles peut exprimer sans effets de bord. Une marque est propre quand le reste de la pile utilise déjà des marques. Elle est dangereuse quand le même masque signifie autre chose dans une autre règle. Les deux types de paquets ont de toute façon besoin du traitement.

Marquer IKE seul laisse les paquets de données sur le chemin capturé. Cela produit un tunnel qui fait la poignée de main puis ne transporte rien.

La marque est un bit du fwmark du paquet que rien d'autre sur la passerelle ne revendique : 0x1 avec le masque 0x1 est le choix habituel, et il faut la définir à deux endroits pour que l'exclusion fonctionne. Charon en a besoin sur la socket IKE, et les réglages de marque entrante et sortante de la connexion enfant ont besoin de la même valeur pour que les paquets encapsulés sortent marqués eux aussi. Un masque de 0x1 plutôt que 0xffffffff laisse les bits restants libres, ce qui compte quand un autre sous-système marque déjà des paquets sur le même hôte. Les deux étant définis, la règle s'écrit comme une exclusion, de sorte que les paquets marqués sautent la table qui contient la route XFRM et retombent dans la table principale :

ip rule add not fwmark 0x1/0x1 lookup 220 pref 1000
ip -4 route get 198.51.100.44 from 10.40.0.2 mark 0x1

Lisez ensuite la réponse avec la marque appliquée. Sans elle, vous inspectez le chemin que prend le trafic protégé, soit le contraire de la question de cette section.

Ce que l'installation automatique suppose de la compilation

Installation automatique de route pour une interface XFRM dépend de la version de strongSwan et de sa configuration. L'ID de l'interface, la politique installée et l'association doivent tous désigner les objets prévus. Une incohérence se manifeste par une route qui pointe discrètement vers un endroit réel.

Copier un numéro de table ou un masque de marque depuis une autre passerelle est la façon dont les collisions commencent. Vérifiez d'abord ce qui l'utilise déjà. Une collision affecte un trafic bien au-delà du tunnel que vous vouliez modifier, et le symptôme pointe rarement vers la copie.

Les changements d'adresse du pair font partie de la conception. Une route d'hôte pour l'adresse d'hier n'est pas un plan de reprise du point de terminaison, alors qu'une marque survit à ce changement.

Surveillez la première renégociation

Vérifiez le chemin extérieur une fois les routes protégées installées, pas avant. Surveillez ensuite la renégociation suivante et un échange applicatif. L'échec apparaît généralement à cette transition et non au démarrage.

ip -4 route get 198.51.100.44
sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or esp'

Retirer temporairement la route par défaut protégée rétablit généralement la connectivité. Ce résultat est diagnostique, pas définitif.

L'objectif est une séparation stable entre le trafic interne et les paquets extérieurs qui le transportent. Écrivez le mécanisme choisi et sa table ou sa marque dans les notes de la passerelle. Sinon, la prochaine personne qui touche aux règles réintroduira la boucle.