Situation
Wochenende. 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 Traffic im Tunnel. Der Student reagiert nicht auf Anrufe.
Ich setze den Wasserkocher auf und tauche in die Fehlersuche des S-Terra Gateways ein. Ich teile meine Erfahrungen und Methodik.
Stammdaten
Zwei räumlich getrennte Standorte sind über einen GRE-Tunnel verbunden. GRE muss verschlüsselt werden:
Ich überprüfe die Funktionsfähigkeit des GRE-Tunnels. Dazu starte ich ein Ping vom Gerät R1 zur GRE-Schnittstelle des Geräts R2. Dies ist der Zieltraffic 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 of data.
--- 1.1.1.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057msIch schaue die Protokolle auf Gate1 und Gate2 durch. Das Protokoll freut sich zu berichten, 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, 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:1In der Statistik des IPsec-Tunnels auf Gate1 sehe ich, dass der Tunnel tatsächlich existiert, aber der Zähler Rcvd ist auf Null gesetzt:
root@Gate1:~# sa_mgr show
ISAKMP-Sitzungen: 0 initiiert, 0 geantwortet
ISAKMP-Verbindungen:
Num Conn-id (Lokale Addr,Port)-(Entfernte Addr,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 Addr,Port)-(Entfernte Addr,Port) Protokoll Aktionsart Gesendet Empfangen
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0Ich troubleshoot das S-Terra so: Ich suche, wo die Zielpakete auf dem Weg von R1 nach R2 verloren gehen. Im Prozess (Spoiler) finde ich einen Fehler.
Fehlersuche
Schritt 1. Was erhält Gate1 von R1?
Ich benutze den eingebauten Paket-Sniffer – tcpdump. Ich starte den Sniffer am internen (Gi0/1 in Cisco-ähnlicher Notation oder eth1 in Debian-OS-Notation) Interface:
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 64Ich sehe, dass Gate1 GRE-Pakete von R1 erhält. Ich gehe weiter.
Schritt 2. Was macht Gate1 mit den GRE-Paketen?
Mit dem Tool klogview schaue ich, was mit den GRE-Paketen innerhalb passiert. VPN des S-Terra-Treibers:
root@Gate1:~# klogview -f 0xffffffff
Filterergebnis für ausgehendes Paket 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 4 "IPsecPolicy:CMAP", filter 8, Ereignis-ID IPsec:Schützen: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: gekapselt
Ich sehe, dass der Ziel-GRE-Verkehr (proto 47) 172.16.0.1 -> 172.17.0.1 das Verschlüsselungsregel LIST in der Kryptokarte CMAP erreicht hat (PASS) und somit verschlüsselt wurde (gekapselt). Anschließend wurde das Paket weitergeleitet (passed out). Im klogview gibt es keinen Antwortverkehr.
Ich überprüfe die Zugriffslisten auf dem Gerät Gate1. Ich sehe eine ZugriffsListe LIST, die den Zielverkehr zur Verschlüsselung definiert, das bedeutet, dass keine ME-Regeln konfiguriert sind:
Gate1#show access-lists
Erweiterte IP-ZugriffsListe LIST
10 erlauben gre Host 172.16.0.1 Host 172.17.0.1Fazit: Das Problem liegt nicht auf dem Gerät Gate1.
Zusätzlich zu klogview
Der VPN-Treiber verarbeitet gesamten Netzwerkverkehr, nicht nur den, der verschlüsselt werden soll. Solche Meldungen sind im klogview sichtbar, wenn der VPN-Treiber Netzwerkverkehr bearbeitet und unverschlüsselt übergibt:
root@R1:~# ping 172.17.0.1 -c 4root@Gate1:~# klogview -f 0xffffffff
Filterergebnis für eingehendes 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) 172.16.0.1->172.17.0.1 nicht in die Verschlüsselungsregeln der Kryptokarte CMAP passt (kein Treffer). Das Paket wurde unverschlüsselt weitergeleitet (passed out).
Schritt 3. Was erhält Gate2 von Gate1
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 eine vollständige Protokolldekodierung
höre 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 empfängt.
Schritt 4. Was macht Gate2 mit den ESP-Paketen
Ich starte das klogview-Tool auf Gate2:
root@Gate2:~# klogview -f 0xffffffff
Filterergebnis für eingehendes Paket 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: chain 17 "FilterChain:L3VPN", filter 21, Status DROP
abgelehntes Paket 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: Firewall
Ich sehe, dass die ESP-Pakete (proto 50) abgelehnt wurden (DROP) durch die Regel (L3VPN) der Firewall. Ich stelle fest, dass tatsächlich eine ZugriffsListe L3VPN an Gi0/0 angehängt ist:
Gate2#show ip interface gi0/0
GigabitEthernet0/0 ist aktiv, Linie Protokoll ist aktiv
Internet-Adresse ist 10.10.10.252/24
MTU ist 1500 Bytes
Ausgehende ZugriffsListe ist nicht gesetzt
Eingehende ZugriffsListe ist L3VPNDas Problem wurde identifiziert.
Schritt 5. Was stimmt nicht mit der ZugriffsListe
Ich schaue mir an, wie die ZugriffsListe L3VPN aussieht:
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 sehe, dass ISAKMP-Pakete erlaubt sind, daher wird der IPsec-Tunnel eingerichtet. Es gibt jedoch keine erlaubende Regel für ESP. Offensichtlich hat der Student icmp und esp verwechselt.
Ich korrigiere die ZugriffsListe:
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
Zuerst stelle ich sicher, dass die ZugriffsListe L3VPN 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 Zieltraffic 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 gesendet, 4 empfangen, 0% Paketverlust, Zeit 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 msSieg. Der GRE-Tunnel wurde hergestellt. Der Zähler für den eingehenden Datenverkehr in der IPsec-Statistik ist nicht null:
root@Gate1:~# sa_mgr show
ISAKMP-Sitzungen: 0 initiiert, 0 geantwortet
ISAKMP-Verbindungen:
Num Conn-id (Lokale Adresse,Port)-(Remote Adresse,Port) Zustand 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 Gate2-Gateway erscheinen im klogview Nachrichten, dass der Zieltraffic 172.16.0.1->172.17.0.1 erfolgreich (PASS) entschlüsselt (decapsulated) wurde durch Regel LIST in der Kryptokarte CMAP:
root@Gate2:~# klogview -f 0xffffffff
Filtrationsergebnis für in 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
erfolgreich verarbeitet in Paket 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulatedErgebnisse
Der Student hat die Ausgabe ruiniert.
Sei vorsichtiger mit den MÄ-Regeln.
Anonymer Ingenieur
t.me/anonimous_engineer
Quelle: habr.com
