IPsec multi-sous-réseaux perd le trafic retour ? Comptez les reqid

Le trafic quitte un site et ne revient jamais, les deux passerelles signalent une négociation terminée, et le seul indice est un tas de paquets sortants sans réponses. Sur un point de terminaison Linux, la cause habituelle n'est pas la force du chiffrement, le MTU ou une table de routage. C'est la granularité des entrées de politique et le numéro qui relie chaque politique à une association de sécurité. La procédure ci-dessous lit ces deux bases avant de toucher à quoi que ce soit.

Séparez le symptôme avant de modifier quoi que ce soit

Une panne à sens unique avec une négociation IKE terminée réduit le problème au chemin de données. Soit la politique sortante correspondait et la réponse a été rejetée, soit la réponse n'est jamais arrivée car l'autre côté n'avait rien pour l'acheminer. Du point de vue d'une application, les deux cas se ressemblent, et les bases xfrm les distinguent.

Ne commencez pas par le MTU. Un MTU erroné produit des blocages et des symptômes de fragmentation, pas une séparation nette de direction avec des compteurs sortants qui montent.

Lisez la base des politiques et la base d'états

Sous Linux, le chiffrement est décidé par les entrées de politique, donc une politique correspondante, et non une route, est ce qui fait entrer un paquet dans le tunnel. Lancez ip xfrm policy pour voir les sélecteurs, la direction, la priorité et le modèle de chaque entrée, et ip xfrm state pour voir les associations établies avec leurs reqid. La politique et l'association sont reliées par ce reqid.

Examinez les trois directions. Sortant et entrant couvrent le trafic vers et depuis cet hôte ; la direction de transfert compte lorsque l'hôte route pour d'autres. Une entrée absente ou discordante dans une direction explique un résultat à sens unique sans aucune faute cryptographique.

L'asymétrie classique : un seul reqid pour plusieurs sous-réseaux

Un échec courant vient d'un pair qui installe des politiques pour tous les sous-réseaux négociés sous un seul reqid, ce qui arrive avec generate_policy require de racoon. Le trafic sort alors par l'association établie en dernier, tandis que l'autre côté garde une association distincte par sous-réseau. Les réponses arrivent sur une association dont le reqid n'identifie pas la politique censée les accepter, et le noyau les rejette après déchiffrement.

Le correctif est un changement de configuration, pas une règle de pare-feu : generate_policy unique; donne à chaque politique son propre reqid, de sorte que les associations par politique du pair ont des partenaires correspondants. Appliquez-le, renégociez, et comptez les reqid distincts pour les sous-réseaux attendus avant de déclarer le succès.

Si deux sous-réseaux partagent encore un reqid alors que l'autre côté en attend deux, vous avez trouvé l'asymétrie. Notez la correspondance, car c'est la preuve que le changement suivant l'a corrigée ou préservée.

Les sélecteurs viennent de la négociation, pas de votre configuration

Les plages protégées sont ce sur quoi les deux extrémités se sont accordées, pas ce qu'un côté a demandé. Un client qui propose une paire d'hôtes face à une large plage distante reçoit la version restreinte de la passerelle, et le client ne peut pas l'élargir. Lisez les sélecteurs installés plutôt que ceux de votre fichier local.

Lorsque l'objectif est l'inverse, garder une destination hors du tunnel, ajoutez une politique de contournement avec un numéro de priorité plus bas pour qu'elle l'emporte sur l'entrée installée automatiquement. Une politique sans modèle autorise le trafic en clair, ce qui en fait une exception délibérée pour un compte rendu de changement plutôt qu'une étape de débogage.

Vérifiez dans cet ordre, et sachez revenir en arrière

Listez les politiques de chaque sous-réseau dans les deux directions, y compris le transfert si l'hôte route. Comptez les reqid distincts et confirmez-en un par politique du côté qui l'attend. Comparez les sélecteurs installés avec ceux négociés. Relisez les compteurs par association après un renouvellement de clé, car l'association inspectée peut déjà avoir disparu. Vérifiez les routes en dernier, car une route manquante vers le sous-réseau distant produit un symptôme à sens unique similaire avec des compteurs de politique propres.

Avant de modifier le pair, enregistrez la sortie actuelle des deux commandes xfrm. Si le nouveau réglage ne rétablit pas la direction de retour, restaurer cette sortie est un retour arrière plus rapide que reconstruire le tunnel de mémoire, et cela garde la comparaison honnête.