ProHoster > Blog > Administration > Wie man die heimische IPsec VPN Fehlersuche durchfĂŒhrt. Teil 1

Wie man die heimische IPsec VPN Fehlersuche durchfĂŒhrt. Teil 1

Wie man die heimische IPsec VPN Fehlersuche durchfĂŒhrt. Teil 1

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:

Wie man die heimische IPsec VPN Fehlersuche durchfĂŒhrt. Teil 1

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 3057ms

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

In 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 0

Ich 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 64

Ich 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.1

Fazit: 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 4

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

Ich 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 140

Ich 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 L3VPN

Das 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 any

Ich 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 any

Schritt 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 any

Jetzt 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 ms

Sieg. 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 480

Am 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: decapsulated

Ergebnisse

Der Student hat die Ausgabe ruiniert.
Sei vorsichtiger mit den MÄ-Regeln.

Anonymer Ingenieur
t.me/anonimous_engineer

Quelle: habr.com

ZuverlĂ€ssiges Hosting fĂŒr Websites mit DDoS-Schutz kaufen, VPS VDS Server đŸ”„ ZuverlĂ€ssiges Hosting fĂŒr Websites mit DDoS-Schutz kaufen, VPS VDS Server - ProHoster