Quel VRF atteint le pair VPN et lequel transporte le paquet ?

Chaque tunnel à l’intérieur d’un contexte de routage client doit tout de même atteindre son pair distant, et cette recherche peut se faire dans une table entièrement différente. Se tromper ici produit l’une des pannes les plus déroutantes de l’IPsec conscient du VRF : le tunnel monte, les routes semblent présentes et le trafic meurt parce que l’une des deux recherches a utilisé le mauvais contexte. Exécutez les quatre étapes ci-dessous dans l’ordre et notez les deux destinations séparément.

Deux recherches, un tunnel

Le paquet encapsulé externe est adressé à l’adresse de transport du pair, et il est routé avant qu’une protection quelconque existe. Le paquet interne est adressé à un serveur client et il est routé après la désencapsulation, à l’intérieur du contexte du client. Ce sont deux destinations, deux recherches et souvent deux tables différentes.

La documentation Cisco de l’IPsec conscient du VRF les nomme VRF de porte d’entrée et VRF intérieur. La porte d’entrée porte le transport chiffré, et le contexte intérieur porte le trafic protégé. Rien dans le fait de nommer un tunnel d’après un client ne fait apparaître l’une ou l’autre des routes.

Dressez donc quatre faits avant de modifier une configuration : l’adresse de transport du pair et le contexte qui l’atteint, puis le préfixe du serveur et le contexte qui l’atteint. Si vous ne pouvez pas remplir les quatre, vous êtes sur le point de deviner. Deviner dans ce domaine coûte cher, car une route ajoutée à la mauvaise table peut faire fonctionner un flux tout en cassant silencieusement un autre. Les quatre faits demandent dix minutes à recueillir et font gagner une journée d’analyse de captures.

Confirmez la recherche de transport du pair

Commencez par la porte d’entrée, car un tunnel qui n’atteint pas son pair ne laissera jamais passer un seul paquet protégé. Sur IOS, demandez la route vers le pair à l’intérieur du VRF de transport plutôt que dans la table globale.

show ip route vrf wan-blue 203.0.113.20
show ip vrf brief
show crypto ikev2 sa

La première commande répond si l’adresse du pair est joignable dans ce contexte, la deuxième liste les VRF qui existent réellement et la troisième montre si une association de sécurité s’est formée. Une adresse de pair qui ne se résout que dans la table globale est l’erreur classique de la porte d’entrée, et elle se présente comme une négociation IKE qui ne démarre jamais.

Vérifiez aussi l’affectation d’interface. Le comportement documenté exige que le VRF de porte d’entrée du tunnel et le VRF de l’interface WAN concordent ; une divergence peut laisser sortir un paquet tout en empêchant la réponse d’être traitée dans le bon contexte.

Confirmez la recherche intérieure du serveur

Une fois la porte d’entrée prouvée, passez au contexte du client et posez la même question sur le préfixe du serveur. Cette recherche décide si un paquet désencapsulé peut être transmis plus loin.

show ip route vrf customer-blue 10.60.4.0
show crypto session detail

La première commande montre la route intérieure, et la seconde montre l’état de la session ainsi que les contextes que la plateforme lui a associés. Si la route existe mais que le détail de la session nomme le mauvais contexte intérieur, le tunnel transmet vers une table qui ne connaît pas le préfixe du client.

Une route dans la table globale ne prouve rien pour l’une ou l’autre recherche. Les routes globales servent lorsqu’un paquet n’est associé à aucun VRF, et une interface de tunnel affectée à un contexte client change cette association. Si la route intérieure manque, le paquet est désencapsulé puis abandonné faute d’entrée de transmission, ce qui ressemble à une perte de paquets et non à une erreur de routage.

Placez le réglage là où le modèle l’attend

La même documentation distingue des modèles de configuration, et un réglage qui appartient à l’un n’appartient pas forcément à l’autre. Pour les interfaces de tunnel utilisant la protection de tunnel, le VRF intérieur est défini sur l’interface de tunnel. Pour les conceptions à base de crypto map, le VRF intérieur fait partie de l’entrée de crypto map. Déplacer une commande au nom similaire entre modèles sans vérifier son rôle est la façon dont une conception qui fonctionne devient intermittente.

Le routage et l’identité sont deux sujets distincts. La joignabilité ne remplace jamais un profil de pair que l’équipement acceptera, et un renommage de VRF ne doit pas modifier les identifiants proposés. Vérifiez les deux après tout changement, car un tunnel qui négocie avec le mauvais profil peut tout de même former une association et ne rien transmettre.

Enfin, consignez les quatre faits et les commandes qui les ont prouvés dans le journal des changements. Le prochain ingénieur héritera du tunnel et non du raisonnement, et une courte note qui nomme les deux contextes vaut plus qu’un schéma que personne ne met à jour.