Dépannage des tunnels IPsec et des problèmes courants de plan de contrôle avec les captures de paquets

Introduction

Ce document décrit comment les captures de paquets, d'autres outils, aident à résoudre les problèmes de plan de contrôle lors de la négociation d'un VPN de site à site sur les routeurs Cisco IOS® XE.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Connaissances de base de la configuration CLI de Cisco IOS®.
• Connaissances fondamentales des protocoles IKEv2 et IPsec.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de logiciel suivantes :

• CSR1000V - Logiciel Cisco IOS XE version 16.12.0.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Les captures de paquets sont un outil puissant qui vous aide à vérifier si des paquets sont envoyés/reçus entre des périphériques homologues VPN. Ils confirment également si le comportement observé avec les débogages IPsec s'aligne sur le résultat collecté sur les captures puisque les débogages sont une interprétation logique, et la capture représente l'interaction physique entre les homologues. De ce fait, vous pouvez confirmer ou ignorer les problèmes de connectivité.

Outils utiles

Il existe des outils utiles qui vous aident à configurer les captures, à extraire le résultat et à l'analyser plus en détail. Certaines d'entre elles sont :

• Wireshark : il s'agit d'un analyseur de paquets open source bien connu et utilisé.
• Captures de surveillance : fonctionnalité Cisco IOS XE sur les routeurs qui vous aide à collecter des captures et vous fournit une sortie lumineuse de ce à quoi ressemble le flux de trafic, le protocole collecté et ses horodatages.

Configuration des captures sur le routeur IOS XE

Une capture utilise une liste de contrôle d’accès étendue (ACL) qui définit le type de trafic à collecter, ainsi que les adresses source et de destination des homologues VPN ou des segments du trafic intéressant. Une négociation de tunnel utilise les ports UDP 500 et 4500 si NAT-T est activé le long du chemin. Une fois la négociation terminée et le tunnel établi, le trafic intéressant utilise le protocole IP 50 (ESP) ou UDP 4500 si NAT-T est activé.

Afin de dépanner les problèmes liés au plan de contrôle, les adresses IP des homologues VPN doivent être utilisées pour capturer la façon dont le tunnel est négocié.

config terminal
ip access-list extended <ACL name>
permit udp host <local address> host <peer address>
permit udp host <peer address> host <source address>
exit
exit

La liste de contrôle d’accès configurée est utilisée pour restreindre le trafic capturé et elle est placée sur l’interface utilisée pour négocier le tunnel.

monitor capture <capture name> access-list <ACL name> buffer size <custom buffer size in MB> interface <source interface of teh router> both 

Une fois la capture configurée, elle peut être manipulée pour l'arrêter, l'effacer ou extraire le trafic collecté à l'aide des commandes suivantes :

• Vérifiez les informations générales de capture : show monitor capture
• Démarrage/arrêt de la capture : surveillance début/arrêt du cap de capture
• Vérifiez que la capture collecte les paquets : show monitor capture cap buffer
• Voir un bref résultat du trafic : show monitor capture cap buffer brief
• Effacer la capture : effacer le cache de capture du moniteur
• Extrayez le résultat de la capture :
  • écran cap buff dump                             
  • monitor capture cap export bootflash:capture.pcap

Analyse de l’établissement du tunnel avec les captures de paquets

Comme mentionné précédemment, pour négocier le tunnel IPSec, les paquets sont envoyés sur UDP avec le port 500 et le port 4500 si NAT-T est activé. Avec les captures, davantage d'informations peuvent être vues à partir de ces paquets, telles que la phase en cours de négociation (phase 1 ou phase 2), le rôle de chaque périphérique (initiateur ou répondeur) ou les valeurs SPI qui viennent d'être créées.

En affichant le bref résultat de la capture du routeur, l'interaction entre les homologues est visible, envoyant des paquets UDP.

Après avoir extrait le dump et exporté le fichier pcap du routeur, plus d'informations des paquets sont visibles à l'aide de wireshark.

Dans la section Protocole Internet du premier paquet Exchange IKE_SA_INIT envoyé, les adresses source et de destination du paquet UDP sont localisées. Dans la section User Datagram Protocol, les ports utilisés et la section Internet Security Association and Key Management Protocol indiquent la version du protocole, le type de message échangé et le rôle du périphérique, ainsi que le SPI créé. Lors de la collecte des débogages IKEv2, les mêmes informations sont présentées dans les journaux de débogage.

Lorsque la négociation d'échange IKE_AUTH a lieu, la charge utile est chiffrée, mais certaines informations sur la négociation sont visibles, telles que le SPI précédemment créé et le type de transaction effectuée.

Une fois le dernier paquet d'échange IKE_AUTH reçu, la négociation du tunnel est terminée.

Transaction lorsque NAT est entre

Nat-transversal est une autre fonctionnalité qui peut être vue lorsque la négociation de tunnel a lieu. Si un périphérique intermédiaire attribue une ou les deux adresses utilisées pour le tunnel, les périphériques changent le port UDP de 500 à 4500 lorsque la phase 2 (échange IKE_AUTH) est négociée.

Capture prise sur le côté A :

Capture prise sur la face B :

Problèmes courants liés au plan de contrôle

Il peut y avoir des facteurs locaux ou externes qui affectent la négociation de tunnel et peuvent être identifiés avec des captures aussi bien. Les scénarios suivants sont les plus courants.

Non-concordance de configuration

Ce scénario peut être résolu en examinant chaque configuration des phases 1 et 2 du périphérique. Cependant, il peut y avoir des scénarios dans lesquels il n'y a pas d'accès à l'extrémité distante. Les captures aident à identifier le périphérique qui envoie un message NO_PROPOSAL_CHOSEN dans les paquets lors de la phase 1 ou 2. Cette réponse indique que la configuration peut présenter un problème et indique la phase à ajuster.

Retransmissions

Une négociation de tunnel IPSec peut échouer en raison de l'abandon des paquets de négociation sur le chemin entre les périphériques finaux. Les paquets abandonnés peuvent être des paquets de phase 1 ou de phase 2. Dans ce cas, le périphérique qui attend un paquet de réponse retransmet le dernier paquet, et s'il n'y a pas de réponse après 5 tentatives, le tunnel est terminé et redémarré depuis le début.

Les captures de chaque côté du tunnel aident à identifier ce qui pourrait bloquer le trafic et dans quelle direction il est affecté.