IPsec sur un WAN privé : limites de politique SRX à vérifier

Un WAN privé peut transporter les paquets externes d’un tunnel IPsec, donc les adresses du pair n’ont pas à être des adresses internet publiques. Ce qui change, c’est le chemin emprunté par ces paquets externes et les autorisations sur l’interface qui les reçoit. Sur un SRX, le chemin de contrôle externe, la liaison de l’interface de tunnel et la politique de trafic transféré sont trois objets distincts. Diagnostiquer l’un alors que les deux autres sont faux est la raison habituelle pour laquelle un tunnel reste inactif.

Notez d’abord le chemin IKE externe

Notez quatre valeurs avant de toucher à la politique : l’adresse du pair, l’interface locale qui reçoit IKE, le contexte de routage qui atteint le pair et la route qui sélectionne cette interface. Les paquets IKE sont adressés au SRX lui-même, ils ont donc besoin d’une autorisation host-inbound dans la zone de réception, pas d’une politique de trafic transféré. Une adresse WAN privée ne supprime pas cette exigence, car le paquet se termine toujours sur l’équipement.

Vérifiez l’état installé avec show security ike sa et la configuration avec show configuration security ike. La première indique si la phase 1 existe ; la seconde indique ce que l’équipement croit devoir faire.

Liez l’interface de tunnel à la bonne politique

Un VPN basé sur le routage lie une interface de tunnel à un objet VPN, et les préfixes protégés sont routés vers cette interface. Notez quelle interface, quelle route et quelle politique autorisent les applications entre les zones concernées. Une zone nommée trust est un conteneur de politiques, et le nom ne prouve pas que les paquets de contrôle ou de données requis sont autorisés.

Lisez les liaisons réelles plutôt qu’un ancien schéma : show configuration security ipsec vpn pour le réglage de liaison à l’interface et show configuration security policies pour les règles qui référencent la zone du tunnel.

Si la route protégée pointe ailleurs, le tunnel peut être actif alors que le trafic n’y entre jamais. C’est un problème de routage déguisé en IPsec.

Gardez la route du pair sur l’underlay

La route vers le pair externe doit se résoudre via l’underlay, et non de façon récursive via le tunnel qu’elle établit. Si la route du pair pointe vers l’interface de tunnel, les paquets IKE poursuivent leur propre tunnel et la phase 1 ne se termine jamais. Le chemin de retour du trafic protégé a besoin de sa propre route et de sa propre politique correctes, et c’est généralement la moitié manquante lorsqu’un sens fonctionne. Lisez l’entrée de la table de routage pour l’adresse du pair et confirmez que l’interface de sortie est l’interface WAN.

Vérifiez-le avec show route 198.51.100.10, en remplaçant par l’adresse réelle du pair, et confirmez que le saut suivant n’est pas une interface de tunnel.

Vérifiez le contrôle et le service dans l’ordre

Progressez vers le haut : état de la phase 1, état de la phase 2, puis un flux applicatif réel. show security ipsec sa liste les associations de sécurité, et show security flow session destination-prefix 10.60.0.0/16 indique si des sessions transférées sont créées pour le réseau protégé.

Une relation de contrôle saine et un chemin de données fonctionnel sont deux résultats différents, et réussir la phase 2 ne dit rien sur le fait que la politique autorise l’application. Testez un flux autorisé et un que la politique devrait rejeter, afin que la différence soit visible.

Notez ensemble la route du pair, l’autorisation host-inbound, la liaison du tunnel, la route interne et la politique de l’application. Ces cinq enregistrements montrent quelle couche possède une future panne sans compter sur une étiquette de port.