🥇Jak troubleshootovat domácí IPsec VPN. Část 1

Situace

Víkend. Piji kávu. Student nastavil VPN spojení mezi dvěma místy a zmizel. Kontroluji: tunel opravdu existuje, ale v tunelu není žádný provoz. Na hovory student neodpovídá.

Dávám vařit vodu a ponořuji se do troubleshooting S-Terra Gateway. Sdílím své zkušenosti a metodiku.

Vstupní data

Dvě geograficky oddělené lokality jsou propojeny GRE tunelem. GRE je třeba zašifrovat:

Kontroluji funkčnost GRE tunelu. K tomu spouštím ping z zařízení R1 na GRE rozhraní zařízení R2. To je cílový provoz pro šifrování. Odpověď není:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) byte data.

--- 1.1.1.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

Podívám se do logů na Gate1 a Gate2. Log radostně informuje, že IPSec tunel byl úspěšně zprovozněn, žádné problémy:

root@Gate1:~# cat /var/log/cspvpngate.log
Aug  5 16:14:23 localhost  vpnsvc: 00100119  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

Ve statistikách IPSec tunelu na Gate1 vidím, že tunel opravdu existuje, ale počitadlo Rcvd je nulové:

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

Troubleshootím S-Terra takto: hledám, kde se ztrácí cílové pakety na cestě od R1 k R2. Během procesu (spoilery) najdu chybu.

Troubleshooting

Krok 1. Co Gate1 dostává od R1

Používám vestavěný paketový sniffer – tcpdump. Spouštím sniffer na vnitřním (Gi0/1 v notaci Cisco-like nebo eth1 v notaci OS Debian) rozhraní:

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

Vidím, že Gate1 přijímá od R1 GRE pakety. Pokračuji dál.

Krok 2. Co Gate1 dělá s GRE pakety

Pomocí utility klogview sleduji, co se děje s GRE pakety uvnitř VPN ovladače S-Terra:

root@Gate1:~# klogview -f 0xffffffff

výsledek filtrace pro odchozí paket 172.16.0.1->172.17.0.1, protokol 47, délka 112, rozhraní eth0: řetězec 4 "IPsecPolicy:CMAP", filtr 8, id události IPsec:Protect:CMAP:1:LIST, stav PASSED
zabalení s SA 31: 172.16.0.1->172.17.0.1, protokol 47, délka 112, rozhraní eth0
předaný odchozí paket 10.10.10.251->10.10.10.252, protokol 50, délka 160, rozhraní eth0: zabaleno

Vidím, že cílový GRE provoz (protokol 47) 172.16.0.1 -> 172.17.0.1 prošel (PASS) pravidlem šifrování LIST v kryptokartě CMAP a byl zašifrován (zabalen). Dále byl paket směrován (předán ven). V klogview není žádný odpovědní provoz.

Kontroluji přístupové seznamy na zařízení Gate1. Vidím jeden přístupový seznam LIST, který definuje cílový provoz pro šifrování, takže pravidla MÉ nejsou nastavena:

Gate1#show access-lists
Rozšířený IP přístupový seznam LIST
    10 povolit gre host 172.16.0.1 host 172.17.0.1

Výstup: problém není na zařízení Gate1.

Další informace o klogview

VPN ovladač zpracovává veškerý síťový provoz, nejen ten, který by měl být šifrován. Takové zprávy jsou viditelné v klogview, pokud VPN ovladač zpracoval síťový provoz a předal ho v nezašifrované podobě:

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

výsledek filtrace pro odchozí paket 172.16.0.1->172.17.0.1, protokol 1, délka 84, rozhraní eth0: řetězec 4 "IPsecPolicy:CMAP": žádná shoda
předaný odchozí paket 172.16.0.1->172.17.0.1, protokol 1, délka 84, rozhraní eth0: filtrováno

Vidím, že ICMP provoz (protokol 1) 172.16.0.1->172.17.0.1 nebyl zahrnut (žádná shoda) v pravidlech šifrování kryptokarty CMAP. Paket byl směrován (předán ven) v otevřené podobě.

Krok 3. Co Gate2 dostává od Gate1

Spouštím sniffer na WAN (eth0) rozhraní Gate2:

root@Gate2:~# tcpdump -i eth0
tcpdump: podrobné výstupy potlačeny, použijte -v nebo -vv pro úplnou dekódaci protokolu
poslouchám na eth0, typ odkazu EN10MB (Ethernet), velikost zachycení 262144 bajtů
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), délka 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), délka 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), délka 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), délka 140

Vidím, že Gate2 přijímá ESP pakety od Gate1.

Krok 4. Co Gate2 dělá s ESP pakety

Spouštím utilitu klogview na Gate2:

root@Gate2:~# klogview -f 0xffffffff
výsledek filtrace pro příchozí paket 10.10.10.251->10.10.10.252, protokol 50, délka 160, rozhraní eth0: řetězec 17 "FilterChain:L3VPN", filtr 21, stav DROP
dropped příchozí paket 10.10.10.251->10.10.10.252, protokol 50, délka 160, rozhraní eth0: firewall

Vidím, že ESP pakety (protokol 50) byly zahozeny (DROP) pravidlem (L3VPN) firewallu. Ujišťuji se, že seznam přístupu L3VPN je skutečně navázán na Gi0/0:

Gate2#show ip interface gi0/0
GigabitEthernet0/0 je nahoru, protokol linky je nahoru
  Internetová adresa je 10.10.10.252/24
  MTU je 1500 bajtů
  Odchozí přístupový seznam není nastaven
  Příchozí přístupový seznam je L3VPN

Objevil jsem problém.

Krok 5. Co není v pořádku se seznamem přístupu

Sleduji, co představuje seznam přístupu L3VPN:

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

Vidím, že jsou povolené ISAKMP pakety, takže se nastavuje IPsec tunel. Ale pravidlo pro ESP není povoleno. Zřejmě si student spletl icmp a esp.

Opravuji seznam přístupu:

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

Krok 6. Kontroluji funkčnost

Nejprve se ujistím, že je seznam přístupu L3VPN správný:

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

Teď z zařízení R1 spouštím cílový provoz:

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

Úspěch. GRE tunel byl navázán. Čítač příchozího provozu ve statistice IPsec není nulový:

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

Na bráně Gate2 se v výstupu klogview objevily zprávy, že cílový provoz 172.16.0.1->172.17.0.1 byl úspěšně (PASS) dešifrován (decapsulated) pravidlem LIST v kryptokartě CMAP:

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

Závěry

Student zkazil výstup.
Buďte opatrní s pravidly MÆ.

Anonymní inženýr
t.me/anonimous_engineer

Zdroj: habr.com