Clever Geek Handbook

Fehlerbehebung bei einem inländischen IPSec-VPN. Teil 1





Lage



Ausgabe. Trinke Kaffee. Der Schüler stellte eine VPN-Verbindung zwischen zwei Punkten her und verschwand. Ich überprüfe: Der Tunnel existiert wirklich, aber es gibt keinen Verkehr im Tunnel. Der Schüler beantwortet keine Anrufe.



Ich stelle den Wasserkocher auf und tauche in die Fehlerbehebung des C-Terra Gateway ein. Ich teile meine Erfahrungen und Methoden.



Ausgangsdaten



Die beiden geografisch getrennten Standorte sind durch einen GRE-Tunnel verbunden. GRE muss verschlüsselt werden:







Überprüfen, ob der GRE-Tunnel funktioniert. Dazu pinge ich vom R1-Gerät zur GRE-Schnittstelle des R2-Geräts. Dies ist gezielter Datenverkehr zur 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 3057ms


Ich schaue mir die Protokolle von Gate1 und Gate2 an. Das Protokoll meldet glücklich, dass der IPSec-Tunnel erfolgreich angestiegen ist, kein Problem: 



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:1


In der Statistik des IPSec-Tunnels auf Gate1 sehe ich, dass der Tunnel tatsächlich existiert, aber der Rcvd-Zähler auf Null gesetzt ist: 



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 0


Ich behebe C-Terra folgendermaßen: Ich suche, wo Zielpakete auf dem Weg von R1 nach R2 verloren gehen. Dabei (Spoiler) werde ich einen Fehler finden.



Fehlerbehebung



Schritt 1. Was Gate1 von R1 bekommt Ich



verwende den eingebauten 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 64


Ich sehe, dass Gate1 GRE-Pakete von R1 empfängt. Weitermachen.



Schritt 2. Was Gate1 mit GRE-Paketen macht



Mit dem Dienstprogramm klogview kann ich sehen, was mit GRE-Paketen im C-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 GRE-Zielverkehr (Proto 47) 172.16.0.1 -> 172.17.0.1 unter die LIST-Verschlüsselungsregel in der CMAP-Kryptokarte fiel (PASS) und verschlüsselt (gekapselt) wurde. Das Paket wurde dann weitergeleitet (ohnmächtig). In der Klogview-Ausgabe ist kein Antwortverkehr vorhanden.



Überprüfen der Zugriffslisten auf dem Gate1-Gerät. Ich sehe eine Zugriffsliste LIST, die den Zielverkehr für die Verschlüsselung definiert, was bedeutet, dass die ME-Regeln nicht konfiguriert sind: 



Gate1#show access-lists
Extended IP access list LIST
    10 permit gre host 172.16.0.1 host 172.17.0.1


Fazit: Das Problem liegt nicht am Gate1-Gerät.



Weitere Informationen zum klogview



VPN-Treiber verarbeitet den gesamten Netzwerkverkehr, nicht nur den, der verschlüsselt werden muss. Diese Meldungen werden in klogview angezeigt, wenn der VPN-Treiber den Netzwerkverkehr verarbeitet und unverschlüsselt übertragen hat: 



root@R1:~# ping 172.17.0.1 -c 4


root@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: filtered


Ich sehe, dass der ICMP-Verkehr (Proto 1) 172.16.0.1-> 172.17.0.1 in den Verschlüsselungsregeln der CMAP-Krypto-Map nicht (keine Übereinstimmung) gefunden wurde. Das Paket wurde im Klartext weitergeleitet (ohnmächtig).



Schritt 3. Was Gate2 von Gate1 empfängt Starten Sie den



Sniffer auf der WAN (eth0) -Schnittstelle von 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 140


Ich sehe, dass Gate2 ESP-Pakete von Gate1 empfängt.



Schritt 4. Was Gate2 mit ESP-Paketen macht



Starten Sie 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) durch die Regel (L3VPN) der Firewall verworfen wurden (DROP). Ich stelle sicher, dass die L3VPN-Zugriffsliste wirklich an Gi0 / 0 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 L3VPN


Ich habe das Problem gefunden.



Schritt 5. Was ist mit der Zugriffsliste falsch



? Sehen Sie, wie die L3VPN-Zugriffsliste aussieht: 



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 any


Ich sehe, dass ISAKMP-Pakete erlaubt sind, also wird ein IPSec-Tunnel eingerichtet. Es gibt jedoch keine zulässige Regel für ESP. Anscheinend hat der Student icmp und esp verwechselt.



Ich korrigiere die Zugriffsliste: 



Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 any


Schritt 6. Überprüfen der Funktionalität



Stellen Sie zunächst 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 any


Jetzt starte ich gezielten Verkehr vom R1-Gerät: 



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 ms


Sieg. Der GRE-Tunnel wurde eingerichtet. 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 480


Auf Gate2 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 (PASS) entschlüsselt (entkapselt) 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: decapsulated


Ergebnisse Der



Student hat den freien Tag verdorben.

Sei vorsichtig mit den Regeln des ME.



Anonymer Ingenieur

t.me/anonimous_engineer


More articles:


All Articles