Le routeur entre deux pairs IPsec a-t-il besoin d’IPsec ?

Un exercice de laboratoire qui demande « configurez IPsec entre deux sites » cache deux tâches différentes. Les deux extrémités terminent le tunnel : elles négocient, authentifient, chiffrent et déchiffrent. Tout routeur intermédiaire achemine des paquets dont l’en-tête externe appartient aux extrémités, et il le fait sans savoir que le tunnel existe.

Décider quelle tâche est demandée à un équipement est la première étape de l’exercice. L’essentiel de la confusion dans les comptes rendus de laboratoire, et une bonne part de la confusion dans les schémas de production, vient du fait de traiter « prend en charge IPsec » comme une propriété plutôt que comme deux.

Acheminer n’est pas terminer

En mode tunnel, l’en-tête IP externe est adressé aux équipements qui terminent le tunnel. Un routeur au milieu consulte la destination et achemine, exactement comme pour n’importe quel autre paquet, et la charge utile qu’il transporte lui est opaque.

Cette opacité est délibérée. Le routeur ne détient pas le secret du pair, ne mène pas de négociation et n’a pas besoin de base de politiques. Il a besoin d’une route vers l’extrémité distante et de l’autorisation d’acheminer le paquet.

Confondre les deux mène à de vraies erreurs : demander à un pare-feu de transit d’« autoriser IPsec » alors que l’exigence réelle est d’autoriser le protocole 50 entre des adresses précises, ou attendre d’un équipement intermédiaire qu’il déchiffre pour l’inspection alors qu’il n’a aucune clé.

Ce que l’équipement intermédiaire doit quand même réussir

L’acheminement a ses propres exigences. Les routes doivent atteindre les deux extrémités externes, et toute politique sur le chemin doit autoriser le trafic externe réel plutôt qu’un numéro de port supposé. Une règle écrite contre TCP 443 parce que quelqu’un a supposé TLS ne correspondra pas au protocole 50.

L’ESP natif est le protocole IP 50. Ce n’est ni TCP 50 ni UDP 50, et une règle qui bloque le trafic non TCP l’écartera. Si la conception utilise l’encapsulation UDP, le transport visible passe au port d’encapsulation, et la politique doit correspondre à la conception retenue.

La taille des paquets compte aussi. Une route qui transporte une petite sonde ne prouve pas que l’échange encapsulé complet y tient. Un chemin qui abandonne les gros paquets peut laisser la négociation réussir et la charge de travail échouer, ce qui ressemble à un problème d’application. Testez avec un trafic de la taille de la charge réelle avant d’accuser le tunnel.

Pourquoi le simulateur change la question

Un simulateur n’est pas un routeur doté d’une liste de fonctions plus courte ; c’est un modèle avec un sous-ensemble documenté et ses propres règles sur ce qu’un équipement donné peut être configuré à faire. La FAQ de Packet Tracer de Cisco précise que les équipements et les protocoles sont des modèles simplifiés.

La question devient donc trois questions. L’équipement simulé achemine-t-il les paquets dont le scénario a besoin ? Le même équipement offre-t-il la surface de configuration que la leçon suppose ? Et la commande acceptée signifie-t-elle que le comportement est réellement simulé, ou seulement analysé ?

Une commande absente peut être une limite du modèle plutôt qu’une erreur dans votre configuration. Une commande présente peut accepter la syntaxe sans reproduire tous les comportements de production. Consultez l’aide de l’équipement de la version installée avant de conclure dans un sens ou dans l’autre.

Écrire une condition de réussite pour le laboratoire

Pour une leçon sur l’underlay, la condition de réussite est l’accessibilité des extrémités plus les paquets externes qui traversent l’équipement intermédiaire. Prouvez-le avec les compteurs du simulateur ou une vue des paquets, et nommez le protocole que vous vous attendez à voir.

Pour une leçon sur IPsec, ajoutez l’état de négociation et un flux protégé de LAN à LAN. Si le simulateur expose des associations de sécurité, enregistrez-les. S’il ne le fait pas, dites-le dans le compte rendu au lieu de laisser entendre que le tunnel a été vérifié.

Conservez la version du simulateur, les équipements choisis et l’objectif d’apprentissage avec le fichier de topologie. C’est cet enregistrement qui permet à quelqu’un d’autre de reproduire l’exercice et de comprendre quelles parties ont été modélisées.

La configuration de production exige ses propres preuves de plateforme. Un paquet simulé au vert est un résultat pédagogique, pas une déclaration de compatibilité sur le matériel que vous déploierez.