IPsec dans IPsec : quelles adresses le tunnel extérieur doit porter

L'IPsec imbriqué est plus facile à raisonner lorsque les deux couches se terminent sur des machines différentes. Quatre passerelles, deux tunnels et une seule question qui décide si la conception fonctionne : que voit réellement le tunnel extérieur lorsque le tunnel intérieur a fini avec le paquet ? Répondez à cela et les sélecteurs, les routes et l'ordre de dépannage suivent. Trompez-vous et vous passerez une journée à déboguer un tunnel qui est techniquement monté.

Le modèle à quatre passerelles

Les passerelles extérieures A et B construisent le premier tunnel entre les deux sites. Derrière A se trouve la passerelle interne C avec l'adresse de transit 10.60.0.2; derrière B se trouve la passerelle interne D avec l'adresse de transit 10.70.0.2. Les réseaux applicatifs vivent derrière C et D, et chaque adresse de l'exemple est délibérément non chevauchante.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Répartir les couches sur quatre hôtes signifie que chaque machine applique une frontière. Un seul hôte exécutant les deux couches doit concilier deux jeux de politiques, deux tables de routage et deux modes de défaillance sur une même machine, ce qui est possible et bien plus difficile à observer.

Chaque couche ne retire que sa propre protection

C chiffre un paquet applicatif pour D. Le résultat est adressé de C vers D, et c'est ce qui atteint A. Tout ce qui est en aval dépend de cette réécriture.

A le chiffre à nouveau pour B. B déchiffre la couche extérieure, voit un paquet de C vers D et le transmet toujours chiffré. D retire la protection intérieure et livre le paquet applicatif.

Ainsi, A et B voient les extrémités internes et leurs métadonnées, mais ne sont pas les parties qui déchiffrent la charge utile applicative. C'est une propriété réelle de la conception et non l'affirmation que C, D ou les hôtes applicatifs sont dignes de confiance.

Les sélecteurs extérieurs nomment les passerelles internes

C'est ici que la plupart de ces montages échouent. Pour un tunnel extérieur basé sur des politiques, les sélecteurs que vous négociez doivent contenir les adresses que A et B traitent réellement : 10.60.0.2/32 et 10.70.0.2/32, dans le bon ordre local et distant.

Mettre les sous-réseaux applicatifs finaux dans les sélecteurs extérieurs ne fonctionne pas, car lorsqu'un paquet atteint A, l'encapsulation intérieure a déjà réécrit ce que A doit protéger. La politique extérieure ne correspondrait alors à rien, et le tunnel monterait sans transporter de données.

Ne réduisez pas non plus l'autorisation extérieure à UDP 500. La connexion intérieure a son propre chemin de données, qui utilise ESP ou l'encapsulation UDP selon ce qu'elle a négocié, et la politique extérieure doit autoriser ce protocole.

Vérifiez le résultat avec swanctl --list-sas sur chaque passerelle et confirmez que les associations de sécurité enfants rapportent les adresses que vous vouliez, et non celles que vous supposiez. Si la liste montre les sous-réseaux applicatifs, la politique extérieure a été écrite pour la mauvaise couche. Corrigez les sélecteurs avant de déboguer le routage, car le routage semblera correct et les compteurs ne bougeront pas.

Le transfert et le piège de la récursion

Les sélecteurs ne remplacent pas le routage. A et B doivent transmettre le trafic entre C et D dans les deux sens, ce qui implique le transfert IP activé, des routes qui pointent vers le tunnel et un chemin de retour qui existe de l'autre côté.

Si le tunnel extérieur utilise des interfaces XFRM, les routes sélectionnent l'interface tandis que les politiques négociées contraignent encore ce qu'elle transporte. Une interface n'élargit pas ce qui est protégé ; elle change seulement la façon dont le noyau prend le paquet.

Le piège est la récursion. La route de A vers l'extrémité extérieure de B doit suivre le réseau sous-jacent, pas le tunnel que A établit, sinon l'encapsulation tente de voyager en elle-même et la connexion ne s'établit jamais.

Inspectez la traduction avant d'ajouter des couches

Examinez tout NAT source sur A et B avant de régler quoi que ce soit d'autre. Une règle qui réécrit l'adresse de C avant que la politique IPsec ne s'applique peut casser les sélecteurs convenus, et elle peut aussi changer ce que D reçoit de l'autre côté.

Le masquage large ne devient pas plus sûr avec deux couches. Il cache quelle adresse voit l'extrémité distante, et c'est exactement l'information dont vous avez besoin quand le tunnel est monté et que l'application ne fonctionne pas.

Si une règle NAT est vraiment nécessaire, notez avec quelle adresse chaque côté croit parler. Cette seule ligne résout la plupart des discussions pour savoir si le tunnel ou la traduction est en cause. Elle indique aussi au prochain ingénieur où regarder lorsque la règle sera retirée un an plus tard. Un ping ne fera rien de tout cela.

Prouvez le fail-closed et vérifiez la MTU

La disparition d'une route n'est pas en soi une politique fail-closed. Une autre table, une route par défaut ou une règle de politique peuvent silencieusement fournir une solution de repli, et le seul moyen de le savoir est de descendre le tunnel extérieur et d'observer ce que fait le trafic applicatif. Faites-le exprès, dans une fenêtre, plutôt que de le découvrir par accident.

Testez trois états : tunnel extérieur arrêté, tunnel intérieur arrêté et rétablissement une fois les deux revenus. Utilisez les compteurs de politique sur chaque passerelle, car deux sessions IKE établies prouvent seulement que la négociation du plan de contrôle a réussi.

Prévoyez les deux encapsulations. Un IKE fonctionnel est un résultat de petits paquets, et les paquets applicatifs pleine taille peuvent encore échouer une fois deux en-têtes ajoutés ; testez avec une taille de charge utile connue sur le chemin réel au lieu de supposer que les chiffres s'additionnent. L'arithmétique est facile, le chemin ne l'est pas.