Comment IPsec basé sur les routes fonctionne avec une interface XFRM

IPsec basé sur les routes confie à la table de routage une décision que prenaient auparavant les sélecteurs de politique. Sous Linux, la pièce qui le rend possible est l'interface XFRM : un périphérique virtuel dont le trafic est mis en correspondance avec l'état IPsec par un identifiant d'interface plutôt que par un sélecteur. En créer une prend une seule commande et ne prouve rien sur l'existence d'un tunnel. Le périphérique est un crochet entre le routage et la politique de sécurité, et les deux côtés de ce crochet doivent être configurés avant que quoi que ce soit soit protégé.

Ce que l'appareil est et ce qu'il n'est pas

Une interface XFRM est une poignée de routage. Les paquets routés vers elle sont mis en correspondance avec des politiques XFRM qui référencent le même identifiant d'interface, et si une politique et un état existent, ils sont encapsulés. Sans eux, l'interface existe, les compteurs restent immobiles et le trafic ne va nulle part utilement.

C'est la première séparation diagnostique. Une route vers le périphérique est un fait de routage, un état installé est un fait de sécurité, et un compteur qui monte sur le périphérique n'est ni l'un ni l'autre. Quand les gens disent que le tunnel est monté parce que l'interface affiche UP, ils décrivent les indicateurs de liaison d'un périphérique virtuel qui n'a pas de pair propre. L'indicateur signifie que le périphérique a été créé et activé, rien de plus.

Une autre frontière : l'identifiant d'interface n'est pas un nom. Deux périphériques avec des noms proches et des identifiants différents ne partagent pas d'état, et une connexion configurée avec le mauvais identifiant installe un état qu'aucune route n'utilisera jamais.

Construisez-en un dans le bon ordre

Commencez par le périphérique extérieur et un nombre que vous mettrez aussi dans la configuration du démon. L'exemple utilise eth0 comme interface extérieure et 42 comme identifiant, des adresses que vous devriez remplacer par les vôtres.

Montez le périphérique, puis confirmez l'identifiant enregistré par le noyau avant de toucher à la configuration VPN :

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Configurez maintenant la connexion dans strongSwan avec le même identifiant, car le démon doit installer des politiques et des états qui y font référence. Réglez les sélecteurs de trafic local et distant sur la plage que vous comptez router, puis routez cette plage vers le périphérique. La configuration du démon et la table de routage doivent s'accorder à la fois sur l'identifiant et sur les destinations, et aucune ne fournit l'autre.

Gardez IKE et ESP hors de la route du tunnel

Une route par défaut pointant vers le périphérique XFRM capture les paquets encapsulés ainsi que le trafic qu'ils transportent. Le résultat est une boucle : la passerelle tente d'envoyer son propre ESP par le tunnel qu'ESP est censé construire.

Le correctif est une route plus spécifique pour l'adresse extérieure du pair via l'interface physique, qui l'emporte sur la route par défaut parce qu'elle correspond à plus de bits. Le routage basé sur des marques fait le même travail lorsque plusieurs tunnels partagent une table, et strongSwan documente les deux approches pour les déploiements basés sur les routes.

Quoi que vous choisissiez, vérifiez que le paquet extérieur sort non encapsulé. Une vérification rapide consiste à pinguer l'adresse extérieure du pair une fois le tunnel monté ; si cela échoue alors que l'interface est montée, soupçonnez une capture plutôt que la joignabilité. Le même raisonnement s'applique au port IKE, car le trafic UDP du démon lui-même ne doit pas être routé vers le périphérique qu'il tente d'établir.

Vérifiez les compteurs à deux endroits avant d'accuser le chiffrement

Les compteurs d'interface et les compteurs d'état mesurent des étapes différentes. Les paquets routés vers le périphérique incrémentent celui-ci même lorsqu'aucun état ne correspond, tandis que les compteurs d'état ne bougent que pour le trafic réellement encapsulé.

Lisez les deux, puis lisez la vue du démon sur l'association enfant :

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Des compteurs de périphérique qui montent avec une sortie d'état vide signifient que le routage fonctionne et que la politique ne correspond pas, généralement une erreur d'identifiant ou de sélecteur. Des compteurs d'état qui montent alors que le côté distant ne signale rien signifient que les paquets partent mais n'arrivent pas ou échouent à l'authentification, ce qui pointe vers le chemin ou la configuration du pair. Une association enfant listée sans trafic est un problème de sélecteur à un bout, pas un chiffre cassé.

Décidez qui installe les routes

Deux propriétaires pour une table de routage sont la source habituelle de flapping. Si le démon installe les routes automatiquement, votre gestionnaire de réseau ne doit pas installer aussi une route par défaut via le même périphérique, et une route manuelle ajoutée par un script de démarrage sera supprimée à la prochaine reconfiguration du démon.

Choisissez un propriétaire et écrivez-le. Quand le démon possède les routes, gardez le script de démarrage hors de la table et laissez la définition de connexion décrire les sélecteurs de trafic. Quand le gestionnaire de réseau les possède, désactivez l'installation automatique et acceptez que le démon ne réparera pas une route manquante à la reconnexion.

Les règles de transfert et de pare-feu sont une décision distincte par-dessus, car une passerelle qui fait passer le trafic d'autres hôtes a besoin des deux. IPsec basé sur les routes rend ce trafic facile à exprimer avec des outils de routage ordinaires ; il ne rend pas la couche de politique facultative.