Situation
Sortie. Je bois un café. L'étudiant a configuré une connexion VPN entre deux points et a disparu. Je vérifie : le tunnel est bien présent, mais il n'y a pas de trafic dans le tunnel. L'étudiant ne répond pas aux appels.
Je mets la bouilloire à chauffer et me plonges dans le dépannage de C-Terra Gateway. Je partage mon expérience et ma méthodologie.
Données d'origine
Deux sites géographiquement séparés sont reliés par un tunnel GRE. Il faut chiffrer le GRE :
Je vérifie le bon fonctionnement du tunnel GRE. Pour cela, je lance un ping depuis l'appareil R1 vers l'interface GRE de l'appareil R2. C'est le trafic cible à chiffrer. Pas de réponse :
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) octets de données.
--- statistiques ping 1.1.1.2 ---
4 paquets transmis, 0 reçus, 100% de perte, temps 3057msJe consulte les logs sur Gate1 et Gate2. Le log annonce avec joie que le tunnel IPsec a été établi avec succès, aucun problème :
root@Gate1:~# cat /var/log/cspvpngate.log
5 août 16:14:23 localhost vpnsvc: 00100119 Connexion IPSec 5 établie, sélecteur de trafic 172.17.0.1->172.16.0.1, proto 47, pairs 10.10.10.251, id "10.10.10.251", Filtre
IPsec:Protect:CMAP:1:LIST, Action IPsec IPsecAction:CMAP:1, Règle IKERule:CMAP:1Dans les statistiques du tunnel IPsec sur Gate1, je constate que le tunnel existe bien, mais le compteur Rcvd est à zéro :
root@Gate1:~# sa_mgr show
Sessions ISAKMP : 0 initiées, 0 répondues
Connexions ISAKMP :
Num Conn-id (Adresse locale, Port)-(Adresse distante, Port) État Envoyé Reçu
1 3 (10.10.10.251,500)-(10.10.10.252,500) actif 1070 1014
Connexions IPsec :
Num Conn-id (Adresse locale, Port)-(Adresse distante, Port) Protocole Action Type Envoyé Reçu
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0Je dépanne C-Terra ainsi : je cherche où les paquets cibles se perdent sur le chemin de R1 à R2. Au cours du processus (spoil) je vais trouver une erreur.
Dépannage
Étape 1. Que reçoit Gate1 de R1
J'utilise le sniffer de paquets intégré – tcpdump. Je lance le sniffer sur l'interface interne (Gi0/1 en notation Cisco-like ou eth1 en notation Debian OS) :
root@Gate1:~# tcpdump -i eth1
tcpdump : sortie détaillée suppressée, utilisez -v ou -vv pour un décodage complet des protocoles
écoutant sur eth1, type de lien EN10MB (Ethernet), taille de capture 262144 octets
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1 : GREv0, key=0x1, length 92 : IP 1.1.1.1 > 1.1.1.2 : sollicitation ICMP, id 2083, seq 1, length 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1 : GREv0, key=0x1, length 92 : IP 1.1.1.1 > 1.1.1.2 : sollicitation ICMP, id 2083, seq 2, length 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1 : GREv0, key=0x1, length 92 : IP 1.1.1.1 > 1.1.1.2 : sollicitation ICMP, id 2083, seq 3, length 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1 : GREv0, key=0x1, length 92 : IP 1.1.1.1 > 1.1.1.2 : sollicitation ICMP, id 2083, seq 4, length 64Je vois que Gate1 reçoit des paquets GRE de R1. Je continue.
Étape 2. Que fait Gate1 avec les paquets GRE
Avec l'outil klogview, je regarde ce qui se passe avec les paquets GRE à l'intérieur VPN du pilote C-Terra :
root@Gate1:~# klogview -f 0xffffffff
résultat de filtration pour le paquet sortant 172.16.0.1->172.17.0.1, proto 47, len 112, si eth0: chaîne 4 "IPsecPolicy:CMAP", filtre 8, id événement IPsec:Protect:CMAP:1:LIST, statut PASS
encapsulant avec SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, si eth0
paquet sortant passé 10.10.10.251->10.10.10.252, proto 50, len 160, si eth0: encapsulé
Je vois que le trafic GRE ciblé (proto 47) 172.16.0.1 -> 172.17.0.1 a été autorisé (PASS) par la règle de chiffrement LIST dans la carte cryptographique CMAP et a été chiffré (encapsulé). Ensuite, le paquet a été routé (passed out). Il n'y a pas de trafic de réponse dans la sortie de klogview.
Je vérifie les listes d'accès sur l'appareil Gate1. Je vois une liste d'accès LIST, qui définit le trafic ciblé pour le chiffrement, donc les règles MÉ ne sont pas configurées :
Gate1#show access-lists
Liste d'accès IP étendue LIST
10 autoriser gre hôte 172.16.0.1 hôte 172.17.0.1Conclusion : le problème ne vient pas de l'appareil Gate1.
Informations supplémentaires sur klogview
Le pilote VPN traite tout le trafic réseau, pas seulement celui qui doit être chiffré. Voici les messages visibles dans klogview si le pilote VPN a traité le trafic réseau et l'a transmis en clair :
root@R1:~# ping 172.17.0.1 -c 4root@Gate1:~# klogview -f 0xffffffff
résultat de filtration pour le paquet sortant 172.16.0.1->172.17.0.1, proto 1, len 84, si eth0: chaîne 4 "IPsecPolicy:CMAP": pas de correspondance
paquet sortant passé 172.16.0.1->172.17.0.1, proto 1, len 84, si eth0: filtréJe vois que le trafic ICMP (proto 1) 172.16.0.1->172.17.0.1 n'a pas été autorisé (pas de correspondance) dans les règles de chiffrement de la carte cryptographique CMAP. Le paquet a été routé (passed out) en clair.
Étape 3. Que reçoit Gate2 de Gate1
Je lance un sniffer sur l'interface WAN (eth0) de Gate2 :
root@Gate2:~# tcpdump -i eth0
tcpdump : sortie verbeuse supprimée, utilisez -v ou -vv pour un décodage complet du protocole
écoute sur eth0, type de lien EN10MB (Ethernet), taille de capture 262144 octets
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252 : ESP(spi=0x30088112,seq=0x1), longueur 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252 : ESP(spi=0x30088112,seq=0x2), longueur 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252 : ESP(spi=0x30088112,seq=0x3), longueur 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252 : ESP(spi=0x30088112,seq=0x4), longueur 140Je vois que Gate2 reçoit des paquets ESP de Gate1.
Étape 4. Que fait Gate2 avec les paquets ESP
Je lance l'outil klogview sur Gate2 :
root@Gate2:~# klogview -f 0xffffffff
résultat de filtration pour le paquet entrant 10.10.10.251->10.10.10.252, proto 50, len 160, si eth0: chaîne 17 "FilterChain:L3VPN", filtre 21, statut DROP
paquet entrant rejeté 10.10.10.251->10.10.10.252, proto 50, len 160, si eth0: pare-feu
Je vois que les paquets ESP (proto 50) ont été rejetés (DROP) par la règle (L3VPN) du pare-feu. Je m'assure que la liste d'accès L3VPN est bien associée à Gi0/0 :
Gate2#show ip interface gi0/0
GigabitEthernet0/0 est en ligne, le protocole de ligne est en ligne
L'adresse Internet est 10.10.10.252/24
MTU est 1500 octets
Liste d'accès sortante n'est pas définie
Liste d'accès entrante est L3VPNLe problème a été détecté.
Étape 5. Quel est le problème avec la liste d'accès
Je regarde ce qu'est la liste d'accès L3VPN :
Gate2#show access-list L3VPN
Liste d'accès IP étendue L3VPN
10 autoriser udp hôte 10.10.10.251 n'importe quel eq isakmp
20 autoriser udp hôte 10.10.10.251 n'importe quel eq non500-isakmp
30 autoriser icmp hôte 10.10.10.251 n'importe quelJe vois que les paquets ISAKMP sont autorisés, donc le tunnel IPsec est établi. Cependant, il n'y a pas de règle autorisante pour ESP. Apparemment, l'étudiant a confondu icmp et esp.
Je corrige la liste d'accès :
Gate2(config)#
liste d'accès ip étendue L3VPN
no 30
30 autoriser esp hôte 10.10.10.251 n'importe quelÉtape 6. Je vérifie la fonctionnalité
Tout d'abord, je m'assure que la liste d'accès L3VPN est correcte :
Gate2#show access-list L3VPN
Liste d'accès IP étendue L3VPN
10 autoriser udp hôte 10.10.10.251 n'importe quel eq isakmp
20 autoriser udp hôte 10.10.10.251 n'importe quel eq non500-isakmp
30 autoriser esp hôte 10.10.10.251 n'importe quelMaintenant, je lance le trafic cible depuis l'appareil R1 :
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) octets de données.
64 octets de 1.1.1.2 : icmp_seq=1 ttl=64 temps=35,3 ms
64 octets de 1.1.1.2 : icmp_seq=2 ttl=64 temps=3,01 ms
64 octets de 1.1.1.2 : icmp_seq=3 ttl=64 temps=2,65 ms
64 octets de 1.1.1.2 : icmp_seq=4 ttl=64 temps=2,87 ms
--- statistiques ping 1.1.1.2 ---
4 paquets transmis, 4 reçus, 0% de perte de paquets, temps 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 msVictoire. Le tunnel GRE a été établi. Le compteur du trafic entrant dans les statistiques IPsec n'est pas nul :
root@Gate1:~# sa_mgr show
Sessions ISAKMP : 0 initiées, 0 répondues
Connexions ISAKMP :
Num Conn-id (Adresse locale,Port)-(Adresse distante,Port) État Envoyé Reçu
1 3 (10.10.10.251,500)-(10.10.10.252,500) actif 1474 1350
Connexions IPsec :
Num Conn-id (Adresse locale,Port)-(Adresse distante,Port) Protocole Action Type Envoyé Reçu
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480Sur le passerelle Gate2, des messages apparaissent dans le klogview indiquant que le trafic cible 172.16.0.1->172.17.0.1 a été correctement (PASS) déchiffré (decapsulated) par la règle LIST dans la carte cryptographique CMAP :
root@Gate2:~# klogview -f 0xffffffff
résultat de filtration pour le paquet entrant 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0 : chaîne 18 « IPsecPolicy:CMAP », filtre 25, id événement IPsec:Protect:CMAP:1:LIST, état PASS
passé dans le paquet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0 : décapsuléRésultats
L'étudiant a gâché la sortie.
Soyez prudent avec les règles ME.
Ingénieur anonyme
t.me/anonimous_engineer
Source : habr.com
