Situation
Freier Tag. Trinke Kaffee. Der Student baute eine VPN-Verbindung zwischen zwei Punkten auf und verschwand. Ich überprüfe: Es gibt tatsächlich einen Tunnel, aber im Tunnel herrscht kein Verkehr. Der Student beantwortet keine Anrufe.
Ich setze den Wasserkocher auf und tauche in die Fehlerbehebung für das S-Terra Gateway ein. Ich teile meine Erfahrungen und Methodik.
Ausgangsdaten
Die beiden geografisch getrennten Standorte sind durch einen GRE-Tunnel verbunden. GRE muss verschlüsselt werden:
Ich überprüfe die Funktionalität des GRE-Tunnels. Dazu führe ich einen Ping vom Gerät R1 zur GRE-Schnittstelle des Geräts R2 aus. Dies ist der Zieldatenverkehr für die Verschlüsselung. 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 mir die Protokolle von Gate1 und Gate2 an. Das Protokoll meldet freudig, dass der IPsec-Tunnel erfolgreich gestartet wurde, keine Probleme:
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:1In der Statistik des IPsec-Tunnels auf Gate1 sehe ich, dass es tatsächlich einen Tunnel gibt, aber der Rсvd-Zähler ist auf Null zurückgesetzt:
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 0Ich belästige S-Terra folgendermaßen: Ich suche nach den Stellen, an denen die Zielpakete auf dem Weg von R1 nach R2 verloren gehen. Dabei (Spoiler) werde ich einen Fehler finden.
Fehlerbehebung
Schritt 1. Was Gate1 von R1 empfängt
Ich verwende den integrierten Paket-Sniffer - tcpdump. Ich starte den Sniffer auf der internen Schnittstelle (Gi0/1 in Cisco-ähnlicher Notation oder eth1 in Debian OS-Notation):
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 empfängt. Ich mache weiter.
Schritt 2. Was Gate1 mit GRE-Paketen macht
Mit dem Dienstprogramm klogview kann ich sehen, was mit GRE-Paketen im S-Terra VPN-Treiber passiert:
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
Ich sehe, dass der Ziel-GRE-Verkehr (Proto 47) 172.16.0.1 -> 172.17.0.1 unter die LIST-Verschlüsselungsregel in der CMAP-Kryptokarte fiel und gekapselt wurde. Als nächstes wurde das Paket weitergeleitet (verteilt). In der klogview-Ausgabe gibt es keinen Antwortverkehr.
Ich überprüfe die Zugriffslisten auf dem Gate1-Gerät. Ich sehe eine Zugriffsliste LIST, die den Zielverkehr für die Verschlüsselung definiert, was bedeutet, dass keine Firewall-Regeln konfiguriert sind:
Gate1#show access-lists
Extended IP access list LIST
10 permit gre host 172.16.0.1 host 172.17.0.1Fazit: Das Problem liegt nicht beim Gate1-Gerät.
Mehr über klogview
Der VPN-Treiber verarbeitet den gesamten Netzwerkverkehr, nicht nur den Verkehr, der verschlüsselt werden muss. Dies sind die in klogview sichtbaren Meldungen, wenn der VPN-Treiber den Netzwerkverkehr verarbeitet und unverschlüsselt übertragen hat:
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: filteredIch sehe, dass der ICMP-Verkehr (Proto 1) 172.16.0.1->172.17.0.1 nicht in den Verschlüsselungsregeln der CMAP-Kryptokarte enthalten war (keine Übereinstimmung). Das Paket wurde im Klartext weitergeleitet (verteilt).
Schritt 3. Was Gate2 von Gate1 empfängt
Ich starte den Sniffer auf der WAN (eth0) Gate2-Schnittstelle:
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 140Ich sehe, dass Gate2 ESP-Pakete von Gate1 empfängt.
Schritt 4. Was Gate2 mit ESP-Paketen macht
Ich starte das Dienstprogramm klogview auf 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
Ich sehe, dass ESP-Pakete (Proto 50) von der Firewall-Regel (L3VPN) verworfen wurden (DROP). Ich stelle sicher, dass Gi0/0 tatsächlich eine L3VPN-Zugriffsliste angehängt ist:
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 L3VPNIch habe das Problem entdeckt.
Schritt 5. Was stimmt mit der Zugriffsliste nicht?
Ich schaue mir an, was die L3VPN-Zugriffsliste ist:
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 anyIch sehe, dass ISAKMP-Pakete erlaubt sind, sodass ein IPsec-Tunnel aufgebaut wird. Es gibt jedoch keine Aktivierungsregel für ESP. Anscheinend hat der Student ICMP und ESP verwechselt.
Bearbeiten der Zugriffsliste:
Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 anySchritt 6. Funktionalität prüfen
Zunächst stelle ich sicher, dass die L3VPN-Zugriffsliste korrekt ist:
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 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 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 msSieg. Der GRE-Tunnel wurde errichtet. Der Zähler für eingehenden Datenverkehr in der IPsec-Statistik ist nicht Null:
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 480Auf dem Gate2-Gateway wurden in der klogview-Ausgabe Meldungen angezeigt, dass der Zielverkehr 172.16.0.1->172.17.0.1 durch die LIST-Regel in der CMAP-Krypto-Map erfolgreich entschlüsselt (PASS) wurde:
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: decapsulatedErgebnisse
Ein Student hat seinen freien Tag ruiniert.
Seien Sie vorsichtig mit den ME-Regeln.
Anonymer Ingenieur
t.me/anonymous_engineer
Source: habr.com