Situation
Sonntag. Ich trinke Kaffee. Der Student hat eine VPN-Verbindung zwischen zwei Punkten eingerichtet und ist verschwunden. Ich überprüfe: Der Tunnel existiert tatsächlich, aber es gibt keinen Verkehr im Tunnel. Der Student antwortet nicht auf Anrufe.
Ich setze den Wasserkocher auf und tauche in die Fehlersuche des C-Terra Gateways ein. Ich teile meine Erfahrungen und Methoden.
Rohdaten
Zwei geografisch getrennte Standorte sind durch ein GRE-Tunnel verbunden. GRE muss verschlüsselt werden:
Ich überprüfe die Funktionalität des GRE-Tunnels. Dazu führe ich einen Ping von Gerät R1 zum GRE-Interface von Gerät R2 aus. Das ist der Zielverkehr zur Verschlüsselung. Es gibt keine Antwort:
root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) Bytes Daten.
--- 1.1.1.2 Ping-Statistik ---
4 Pakete gesendet, 0 empfangen, 100% Paketverlust, Zeit 3057msIch schaue die Logs auf Gate1 und Gate2 an. Das Log berichtet erfreut, dass die IPsec-Verbindung erfolgreich hergestellt wurde, keine Probleme:
root@Gate1:~# cat /var/log/cspvpngate.log
Aug 5 16:14:23 localhost vpnsvc: 00100119 IPSec-Verbindung 5 hergestellt, Verkehrsauswahl 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:1In der Statistik des IPsec-Tunnels auf Gate1 sehe ich, dass der Tunnel tatsächlich vorhanden ist, aber der Rсvd-Zähler auf null gesetzt wurde:
root@Gate1:~# sa_mgr show
ISAKMP-Sitzungen: 0 initiiert, 0 geantwortet
ISAKMP-Verbindungen:
Num Conn-id (Lokale Adresse,Port)-(Remote Adresse,Port) Status Gesendet Empfangen
1 3 (10.10.10.251,500)-(10.10.10.252,500) aktiv 1070 1014
IPsec-Verbindungen:
Num Conn-id (Lokale Adresse,Port)-(Remote Adresse,Port) Protokoll Aktionsart Gesendet Empfangen
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0Ich habe ein Problem mit C-Terra, ich suche, wo die Zielpakete auf dem Weg von R1 nach R2 verloren gehen. Im Verlauf (Spoiler) finde ich einen Fehler.
Fehlerbehebung
Schritt 1. Was erhält Gate1 von R1
Ich benutze den integrierten Paket-Sniffer – tcpdump. Ich starte den Sniffer auf dem internen (Gi0/1 in Cisco-Notation oder eth1 in Debian-Notation) Interface:
root@Gate1:~# tcpdump -i eth1
tcpdump: Ausführliche Ausgabe unterdrückt, verwenden Sie -v oder -vv für vollständige Protokolldekodierung
höre auf eth1, link-type EN10MB (Ethernet), Erfassungsgröße 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-Anfrage, 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-Anfrage, 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-Anfrage, 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-Anfrage, id 2083, seq 4, length 64Ich sehe, dass Gate1 von R1 GRE-Pakete erhält. Ich mache weiter.
Schritt 2. Was macht Gate1 mit GRE-Paketen
Mit dem Tool klogview schaue ich, was mit den GRE-Paketen im Inneren passiert VPN des C-Terra-Treibers:
root@Gate1:~# klogview -f 0xffffffff
Filterergebnis für das ausgehende Paket 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 4 "IPsecPolicy:CMAP", filter 8, Ereignis-ID IPsec:Protect:CMAP:1:LIST, Status PASS
Kapselung mit SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
ausgehendes Paket 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: kapselisiert
Ich sehe, dass der Ziel-GRE-Verkehr (proto 47) 172.16.0.1 -> 172.17.0.1 dem Verschlüsselungsregel LIST in der kryptographischen Karte CMAP unterliegt und verschlüsselt wurde (kapselisiert). Das Paket wurde dann weitergeleitet (passed out). In der Ausgabe von klogview gibt es keinen Antwortverkehr.
Ich überprüfe die Zugriffskontrolllisten auf dem Gerät Gate1. Ich sehe eine Zugriffskontrollliste LIST, die den Zielverkehr für die Verschlüsselung definiert; das bedeutet, dass keine MEP-Regeln konfiguriert sind:
Gate1#show access-lists
Erweiterte IP-Zugriffsliste LIST
10 erlauben gre host 172.16.0.1 host 172.17.0.1Ausgabe: Das Problem liegt nicht am Gerät Gate1.
Zusätzliches zu klogview
Der VPN-Treiber verarbeitet gesamten Netzwerkverkehr, nicht nur den, der verschlüsselt werden soll. So erscheinen Nachrichten in klogview, wenn der VPN-Treiber den Netzwerkverkehr verarbeitet und unverschlüsselt weiterleitet:
root@R1:~# ping 172.17.0.1 -c 4root@Gate1:~# klogview -f 0xffffffff
Filterergebnis für das ausgehende Paket 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: chain 4 "IPsecPolicy:CMAP": kein Treffer
ausgehendes Paket 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: gefiltertIch sehe, dass der ICMP-Verkehr (proto 1) von 172.16.0.1 nach 172.17.0.1 nicht in die Regeln der Crypto-Karte CMAP gepasst hat (no match). Das Paket wurde unverschlüsselt weitergeleitet.
Schritt 3. Was Gate2 von Gate1 erhält
Ich starte den Sniffer am WAN (eth0)-Schnittstelle von Gate2:
root@Gate2:~# tcpdump -i eth0
tcpdump: ausführliche Ausgabe unterdrückt, verwenden Sie -v oder -vv für vollständige Protokolldekodierung
lausche auf eth0, Linktyp EN10MB (Ethernet), Erfassungsgröße 262144 Bytes
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), Länge 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), Länge 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), Länge 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), Länge 140Ich sehe, dass Gate2 ESP-Pakete von Gate1 erhält.
Schritt 4. Was Gate2 mit den ESP-Paketen macht
Ich starte das Tool klogview auf Gate2:
root@Gate2:~# klogview -f 0xffffffff
Filterergebnis für in Paket 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: Kette 17 "FilterChain:L3VPN", Filter 21, Status DROP
ausgeworfen im Paket 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: Firewall
Ich sehe, dass die ESP-Pakete (proto 50) vom Firewall-Regel (L3VPN) verworfen wurden (DROP). Ich stelle sicher, dass die Zugriffssteuerungsliste L3VPN tatsächlich an Gi0/0 gebunden ist:
Gate2#show ip interface gi0/0
GigabitEthernet0/0 ist aktiv, Leitungssignal ist aktiv
Internetadresse ist 10.10.10.252/24
MTU ist 1500 Bytes
Ausgangszugriffssteuerung ist nicht gesetzt
Eingehende Zugriffsliste ist L3VPNIch habe das Problem gefunden.
Schritt 5. Was stimmt nicht mit der Zugriffssteuerungsliste
Ich sehe mir die Zugriffsberechtigungen der L3VPN-Liste an:
Gate2#show access-list L3VPN
Erweiterte IP-Zugriffsliste L3VPN
10 erlauben udp host 10.10.10.251 any eq isakmp
20 erlauben udp host 10.10.10.251 any eq non500-isakmp
30 erlauben icmp host 10.10.10.251 anyIch stelle fest, dass ISAKMP-Pakete erlaubt sind, weshalb das IPsec-Tunnel eingerichtet wird. Allerdings fehlt die Erlaubnisregel für ESP. Anscheinend hat der Student icmp und esp verwechselt.
Ich korrigiere die Zugriffsregel:
Gate2(config)#
ip access-list extended L3VPN
no 30
30 erlauben esp host 10.10.10.251 anySchritt 6. Ich überprüfe die Funktionsfähigkeit
Zunächst stelle ich sicher, dass die L3VPN-Zugriffsliste korrekt ist:
Gate2#show access-list L3VPN
Erweiterte IP-Zugriffsliste L3VPN
10 erlauben udp host 10.10.10.251 any eq isakmp
20 erlauben udp host 10.10.10.251 any eq non500-isakmp
30 erlauben esp host 10.10.10.251 anyJetzt starte ich den Zielverkehr von Gerät 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 von 1.1.1.2: icmp_seq=1 ttl=64 Zeit=35,3 ms
64 bytes von 1.1.1.2: icmp_seq=2 ttl=64 Zeit=3,01 ms
64 bytes von 1.1.1.2: icmp_seq=3 ttl=64 Zeit=2,65 ms
64 bytes von 1.1.1.2: icmp_seq=4 ttl=64 Zeit=2,87 ms
--- 1.1.1.2 ping statistiken ---
4 Pakete übertragen, 4 empfangen, 0% Paketverlust, Zeit 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 msSieg. Der GRE-Tunnel ist eingerichtet. Der Zähler des eingehenden Datenverkehrs in den IPsec-Statistiken ist nicht null:
root@Gate1:~# sa_mgr show
ISAKMP-Sitzungen: 0 initiiert, 0 beantwortet
ISAKMP-Verbindungen:
Num Conn-id (Lokale Adresse,Port)-(Remote Adresse,Port) Status Gesendet Empfangen
1 3 (10.10.10.251,500)-(10.10.10.252,500) aktiv 1474 1350
IPsec-Verbindungen:
Num Conn-id (Lokale Adresse,Port)-(Remote Adresse,Port) Protokoll Aktionsart Gesendet Empfangen
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480Am Gateway Gate2 erscheinen in der Ausgabe von klogview Nachrichten, dass der Zielverkehr 172.16.0.1->172.17.0.1 erfolgreich (PASS) durch die Regel LIST in der Kryptokarte CMAP entschlüsselt (decapsulated) wurde:
root@Gate2:~# klogview -f 0xffffffff
Filtrationsergebnis für eingehendes Paket 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
bestanden im Paket 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsuliertErgebnisse
Der Student hat das Wochenende ruiniert.
Seien Sie vorsichtig mit M&E-Regeln.
Anonymer Ingenieur
t.me/anonimous_engineer
Quelle: habr.com
