Situation
Production. Je bois du café. L'élève a mis en place une connexion VPN entre deux points et a disparu. Je vérifie: le tunnel existe vraiment, mais il n'y a pas de trafic dans le tunnel. L'élève ne répond pas aux appels.
Je mets la bouilloire et me plonge dans le dépannage de la passerelle C-Terra. Je partage mon expérience et ma méthodologie.
Donnée initiale
Les deux sites géographiquement séparés sont reliés par un tunnel GRE. GRE doit être chiffré:
vérification du fonctionnement du tunnel GRE. Pour ce faire, je cingle du périphérique R1 à l'interface GRE du périphérique R2. Il s'agit du trafic ciblé pour le chiffrement. Pas de réponse:
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
--- 1.1.1.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057msJe regarde les journaux sur Gate1 et Gate2. Le journal signale avec bonheur que le tunnel IPsec a augmenté avec succès, pas de problème:
root@Gate1:~# cat /var/log/cspvpngate.log
Aug 5 16:14:23 localhost vpnsvc: 00100119 <4:1> IPSec connection 5 established, traffic selector 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id "10.10.10.251", Filter
IPsec:Protect:CMAP:1:LIST, IPsecAction IPsecAction:CMAP:1, IKERule IKERule:CMAP:1Dans les statistiques du tunnel IPsec sur Gate1, je vois que le tunnel existe vraiment, mais le compteur Rcvd est remis à zéro:
root@Gate1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded
ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1070 1014
IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0Je dépanne C-Terra comme ceci: je cherche où les paquets cibles sont perdus sur le chemin de R1 à R2. Dans le processus (spoiler), je trouverai une erreur.
DĂ©pannage
Étape 1. Ce que Gate1 obtient de R1 J'utilise
le renifleur de paquets intégré - tcpdump. Je lance le sniffer sur l'interface interne (Gi0 / 1 en notation de type Cisco ou eth1 en notation Debian OS):
root@Gate1:~# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
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: ICMP echo request, 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: ICMP echo request, 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: ICMP echo request, 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: ICMP echo request, id 2083, seq 4, length 64Je vois que Gate1 reçoit des paquets GRE de R1. Passer à autre chose.
Étape 2. Que fait Gate1 avec les paquets GRE
À l'aide de l'utilitaire klogview, je peux voir ce qui se passe avec les paquets GRE à l'intérieur du pilote VPN C-Terra:
root@Gate1:~# klogview -f 0xffffffff
filtration result for out packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 4 "IPsecPolicy:CMAP", filter 8, event id IPsec:Protect:CMAP:1:LIST, status PASS
encapsulating with SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
passed out packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: encapsulated
Je vois que le trafic GRE cible (proto 47) 172.16.0.1 -> 172.17.0.1 est tombé (PASS) sous la règle de cryptage LIST dans la carte cryptographique CMAP et a été crypté (encapsulé). Le paquet a ensuite été acheminé (évanoui). Il n'y a pas de trafic de réponse dans la sortie de klogview.
Vérification des listes d'accès sur l'appareil Gate1. Je vois une liste de liste d'accès, qui détermine le trafic cible pour le chiffrement, ce qui signifie que les règles ME ne sont pas configurées:
Gate1#show access-lists
Extended IP access list LIST
10 permit gre host 172.16.0.1 host 172.17.0.1Conclusion: le problème ne vient pas du périphérique Gate1.
En savoir plus sur le
pilote VPN klogview gère tout le trafic réseau, pas seulement celui qui doit être chiffré. Ces messages sont visibles dans klogview si le pilote VPN a traité le trafic réseau et l'a transmis non chiffré:
root@R1:~# ping 172.17.0.1 -c 4root@Gate1:~# klogview -f 0xffffffff
filtration result for out packet 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: chain 4 "IPsecPolicy:CMAP": no match
passed out packet 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filteredJe vois que le trafic ICMP (proto 1) 172.16.0.1-> 172.17.0.1 n'a pas obtenu (pas de correspondance) dans les règles de cryptage de la carte de cryptage CMAP. Le paquet a été acheminé (évanoui) en texte clair.
Étape 3. Ce que Gate2 reçoit de Gate1 Lancez le
renifleur sur l'interface WAN (eth0) de Gate2:
root@Gate2:~# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), length 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), length 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), length 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), length 140Je vois que Gate2 reçoit des paquets ESP de Gate1.
Étape 4. Que fait Gate2 avec les packages ESP
Lancez l'utilitaire klogview sur Gate2:
root@Gate2:~# klogview -f 0xffffffff
filtration result for in packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: chain 17 "FilterChain:L3VPN", filter 21, status DROP
dropped in packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall
Je vois que les paquets ESP (proto 50) ont été abandonnés (DROP) par la règle (L3VPN) du pare-feu. Je m'assure que la liste d'accès L3VPN est vraiment attachée à Gi0 / 0:
Gate2#show ip interface gi0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 10.10.10.252/24
MTU is 1500 bytes
Outgoing access list is not set
Inbound access list is L3VPNJ'ai trouvé le problème.
Étape 5. Quel est le problème avec la
liste d' accès Voyez à quoi ressemble la liste d'accès L3VPN:
Gate2#show access-list L3VPN
Extended IP access list L3VPN
10 permit udp host 10.10.10.251 any eq isakmp
20 permit udp host 10.10.10.251 any eq non500-isakmp
30 permit icmp host 10.10.10.251 anyJe vois que les paquets ISAKMP sont autorisés, donc un tunnel IPsec est établi. Mais il n'y a pas de règle permissive pour l'ESP. Apparemment, l'étudiant a confondu icmp et esp.
Je corrige la liste d'accès:
Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 anyÉtape 6. Vérification de la fonctionnalité
Tout d'abord, assurez-vous que la liste d'accès L3VPN est correcte:
Gate2#show access-list L3VPN
Extended IP access list L3VPN
10 permit udp host 10.10.10.251 any eq isakmp
20 permit udp host 10.10.10.251 any eq non500-isakmp
30 permit esp host 10.10.10.251 anyMaintenant, je lance un trafic ciblé à partir de l'appareil R1:
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=35.3 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=3.01 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=2.65 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=2.87 ms
--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 msLa victoire. Le tunnel GRE a été établi. Le compteur de trafic entrant dans les statistiques IPsec n'est pas nul:
root@Gate1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded
ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1474 1350
IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480Sur Gate2, dans la sortie de klogview, des messages sont apparus indiquant que le trafic cible 172.16.0.1-> 172.17.0.1 a été avec succès (PASS) déchiffré (décapsulé) par la règle LIST dans la carte de cryptage CMAP:
root@Gate2:~# klogview -f 0xffffffff
filtration result for in packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 18 "IPsecPolicy:CMAP", filter 25, event id IPsec:Protect:CMAP:1:LIST, status PASS
passed in packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulatedRĂ©sultats L'
élève a gâché la journée.
Soyez prudent avec les règles du ME.
Ingénieur anonyme
t.me/anonimous_engineer