Pourquoi une politique de sécurité IPsec n’est pas une entrée de la table de routage

Pingez 10.20.0.5 à travers le tunnel et rien ne revient, alors que la table de routage affirme que ce sous-réseau est joignable. Le routage et IPsec répondent à des questions différentes, et une seule des deux concerne la joignabilité. La recherche directe choisit un chemin, puis la base de données de politique de sécurité décide si ce chemin doit être protégé, laissé tel quel ou refusé. Quand les deux sont en désaccord, le paquet meurt en silence, alors lisez-les dans cet ordre.

Commencez par la recherche, pas par la table

Demandez au noyau ce qu’il ferait réellement : ip route get 10.20.0.5 affiche la route choisie, l’interface de sortie et l’adresse source qu’il utiliserait. Un préfixe, une règle de politique, une marque ou une source préférée peuvent changer cette réponse, et c’est pourquoi la recherche en direct vaut mieux que la lecture de la table à l’œil.

Testez une destination à l’intérieur de la plage protégée, pas l’adresse de la passerelle. Atteindre la passerelle d’en face prouve seulement qu’une route existe ; cela ne dit rien du sous-réseau dont vous avez réellement besoin. Confirmez ensuite que l’interface choisie par la recherche est bien celle que vous attendez du tunnel.

Faites correspondre les sélecteurs des deux côtés

La base de données de politique a ses propres entrées, et chacune nomme une direction, une source, une destination et un protocole, puis indique ce qui doit arriver aux paquets correspondants. Utilisez ip xfrm policy pour les lister ; les indicateurs montrent si l’action est protéger, contourner ou bloquer. Une politique dont les sélecteurs sont plus larges ou plus étroits que votre flux de test ne correspondra pas, et le paquet sort sans protection. C’est la panne que vous cherchez, pas une route manquante.

Comparez les valeurs réelles : source, destination, protocole et ports. Si la recherche a résolu une paire d’adresses alors que l’entrée de politique en couvre une autre, les deux vues décrivent un trafic différent. Relancez les deux avec le même tuple avant de conclure, sinon vous modifierez une politique qui n’a jamais été sur le chemin.

Une correspondance de politique n’est pas un état installé

Une politique correspondante dit seulement que le paquet doit être protégé ; le noyau a encore besoin d’une association de sécurité pour assurer la protection. Listez-les avec ip xfrm state, ou avec swanctl --list-sas quand strongSwan mène la négociation, et lisez les sélecteurs et les compteurs de chaque entrée.

Quand une politique correspond et qu’aucune association ne couvre les mêmes sélecteurs, le paquet est rejeté au lieu d’être envoyé en clair. C’est le rejet à rechercher quand le tunnel est monté mais qu’un seul sous-réseau échoue. Les compteurs disent le reste : une association qui n’augmente jamais n’a jamais été sélectionnée, tandis qu’une qui augmente et finit quand même en rejet désigne le côté distant. Corriger les sélecteurs et renouveler les clés sont deux réparations différentes, alors décidez laquelle il vous faut avant de toucher à la configuration.

Ce qu’un tunnel basé sur la route exige encore

Une interface XFRM fait ressembler le tunnel à un périphérique dans lequel vous pouvez router, ce qui est réellement utile. Elle ne supprime pas la politique et l’état qui décident de ce qui se passe une fois le paquet arrivé là. La route apporte un saut suivant et rien de plus.

Si le périphérique existe et que la route pointe dedans alors qu’aucune association ne correspond aux sélecteurs internes, le paquet est écarté, et aucune quantité d’édition de routes ne produit de clés ni de sélecteurs. Vérifiez l’interface avec la même source et la même destination que celles que vous avez routées, puis comparez cela à la liste des états.

Réglez la propriété avant de modifier quoi que ce soit

Un pare-feu d’hôte ajoute une troisième décision que ni l’une ni l’autre des deux bases de données ne connaît. Une route correcte plus une politique correspondante plus une association installée peuvent encore finir en paquet rejeté, et l’application ne signale que le délai d’attente. Confirmez que le pare-feu autorise le trafic protégé avant d’accuser IPsec. Capturer sur le périphérique du tunnel et sur l’interface physique montre de quel côté du chiffrement le paquet a disparu.

La propriété de la configuration décide si votre correction survit à un redémarrage. Un composant peut installer l’état tandis qu’un autre gère les routes, et une modification manuelle du second est écrasée la prochaine fois que le tunnel monte. Modifiez la configuration propriétaire, puis relisez les deux vues ; RFC 4301 garde les deux bases de données distinctes quand vous devez expliquer cette séparation à quelqu’un d’autre.