🥇Hogyan hibatávolítsunk belföldi IPsec VPN-t. 1. rész

Helyzet

Kimeneti. Kávét iszom. A hallgató VPN kapcsolatot állított be két pont között és eltűnt. Ellenőrzöm: a tunel valóban létezik, de a tunelben nincs forgalom. A hallgató nem válaszol a hívásokra.

Kettle-t teszek fel, és belemerülök a S-Terra Gateway hibaelhárításába. Megosztom tapasztalataimat és metodológiámat.

Forrásadatok

Két földrajzilag elkülönített helyszín GRE alagúttal van összekötve. A GRE-t titkosítani kell:

Ellenőrzöm a GRE alagút működését. Ehhez pingelést indítok az R1 eszközről a GRE interfészre az R2 eszközön. Ez a célforgalom a titkosításhoz. Nincs válasz:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bájt adat.

--- 1.1.1.2 ping statisztikák ---
4 csomag küldve, 0 fogadva, 100% csomagveszteség, idő 3057ms

Nézem a naplókat a Gate1 és Gate2-n. A napló örömmel jelenti, hogy az IPsec alagút sikeresen létrejött, nincsenek problémák:

root@Gate1:~# cat /var/log/cspvpngate.log
Aug  5 16:14:23 localhost vpnsvc: 00100119  IPSec kapcsolat 5 létrejött, forgalmi szelektor 172.17.0.1->172.16.0.1, proto 47, társ 10.10.10.251, id "10.10.10.251", Szűrő 
IPsec:Protect:CMAP:1:LIST, IPsecAction IPsecAction:CMAP:1, IKERule IKERule:CMAP:1

Az IPsec alagút statisztikáiban a Gate1-en látom, hogy az alagút valóban létezik, de az Rcvd számláló nullázva van:

root@Gate1:~# sa_mgr show
ISAKMP ülések: 0 kezdeményezett, 0 válaszolt

ISAKMP kapcsolatok:
Num Conn-id (Helyi IP,Port)-(Táv IP,Port) Állapot Küldött Fogadott
1 3 (10.10.10.251,500)-(10.10.10.252,500) aktív 1070 1014

IPsec kapcsolatok:
Num Conn-id (Helyi IP,Port)-(Táv IP,Port) Protokoll Művelet Típus Küldött Fogadott
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0

A S-Terra hibaelhárítást úgy végzem, hogy megkeresem, hol vesznek el a célcsomagok az R1-R2 között. Közben (spoiler) hibát találok.

Hibaelhárítás

1. lépés. Mit kap a Gate1 az R1-től

Beépített csomagnézőt – tcpdump – használok. A csomagnézőt elindítom a belső (Gi0/1 a Cisco-stílusban vagy eth1 a Debian OS-ben) interfészen:

root@Gate1:~# tcpdump -i eth1

tcpdump: a részletes kimenet elnyomva, használja a -v vagy -vv-t a teljes protokoll dekódolásához
figyelek az eth1-en, link-típus EN10MB (Ethernet), rögzítési méret 262144 bájt
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, kulcs=0x1, hossz 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo kérés, id 2083, seq 1, hossz 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, kulcs=0x1, hossz 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo kérés, id 2083, seq 2, hossz 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, kulcs=0x1, hossz 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo kérés, id 2083, seq 3, hossz 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, kulcs=0x1, hossz 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo kérés, id 2083, seq 4, hossz 64

Látom, hogy a Gate1 GRE csomagokat kap az R1-től. Tovább haladok.

2. lépés. Mit csinál a Gate1 a GRE csomagokkal

A klogview segédprogramot használva nézem, mi történik a GRE csomagokkal belül VPN a S-Terra meghajtóban:

root@Gate1:~# klogview -f 0xffffffff

szűrési eredmény a kimenő csomagra 172.16.0.1->172.17.0.1, protokoll 47, hossz 112, ha eth0: lánc 4 "IPsecPolicy:CMAP", szűrő 8, esemény azonosító IPsec:Protect:CMAP:1:LIST, állapot PASS
burkolás SA 31: 172.16.0.1->172.17.0.1, protokoll 47, hossz 112, ha eth0
kimenő csomag áthalad 10.10.10.251->10.10.10.252, protokoll 50, hossz 160, ha eth0: burkolva

Látom, hogy a célnak megfelelő GRE forgalom (protokoll 47) 172.16.0.1 -> 172.17.0.1 bekerült (PASS) a LIST titkosítási szabály alá a titkosító térképen CMAP, és titkosítva lett (burkolva). A csomagot ezután továbbirányították (kimenő csomag). Nincs válaszforgalom a klogview kimenetében.

Ellenőrzöm a hozzáférési listákat a Gate1 eszközön. Látom, hogy van egy hozzáférési lista, a LIST, amely meghatározza a célnak megfelelő forgalmat a titkosításhoz, tehát a MÁK szabályok nincsenek beállítva:

Gate1#show access-lists
Kiterjesztett IP hozzáférési lista LIST
    10 engedélyezett gre host 172.16.0.1 host 172.17.0.1

Kimenet: a probléma nem a Gate1 eszközön van.

További információ a klogview-ról

A VPN illesztőprogram az összes hálózati forgalmat kezeli, nem csak azt, amelyet titkosítani kell. Ezek az üzenetek láthatók a klogview- ban, ha a VPN illesztőprogram a hálózati forgalmat kezelte, és azt titkosítatlan formában továbbította:

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

szűrési eredmény a kimenő csomagra 172.16.0.1->172.17.0.1, protokoll 1, hossz 84, ha eth0: lánc 4 "IPsecPolicy:CMAP": nincs egyezés
kimenő csomag áthalad 172.16.0.1->172.17.0.1, protokoll 1, hossz 84, ha eth0: szűrve

Látom, hogy az ICMP forgalom (protokoll 1) 172.16.0.1->172.17.0.1 nem került (nincs egyezés) a titkosítási szabályok alá a titkosító térképen CMAP. A csomagot nyitott formában továbbirányították (kimenő csomag).

3. lépés. Mit kap Gate2 Gate1-től

Elindítom a sniffert a WAN (eth0) interfészen Gate2-n:

root@Gate2:~# tcpdump -i eth0
tcpdump: részletes kimenet elrejtve, használja a -v vagy -vv opciót a teljes protokoll dekódolásához
figyelés az eth0-n, link-típus EN10MB (Ethernet), rögzítési méret 262144 byte
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), hossz 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), hossz 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), hossz 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), hossz 140

Látom, hogy Gate2 ESP csomagokat kap Gate1-től.

4. lépés. Mit csinál Gate2 az ESP csomagokkal

Elindítom a klogview eszközt a Gate2-n:

root@Gate2:~# klogview -f 0xffffffff
szűrési eredmény a bejövő csomagra 10.10.10.251->10.10.10.252, protokoll 50, hossz 160, ha eth0: lánc 17 "FilterChain:L3VPN", szűrő 21, állapot DROP
beérkező csomag eldobva 10.10.10.251->10.10.10.252, protokoll 50, hossz 160, ha eth0: tűzfal

Látom, hogy az ESP csomagok (protokoll 50) el lettek dobva (DROP) a tűzfal (L3VPN) által. Meggyőződöm róla, hogy a Gi0/0 valóban kapcsolódik a L3VPN hozzáférési listához:

Gate2#show ip interface gi0/0
GigabitEthernet0/0 fel van állítva, vonali protokoll fel van állítva
  Internet cím 10.10.10.252/24
  MTU 1500 byte
  Kimenő hozzáférési lista nincs beállítva
  Bejövő hozzáférési lista: L3VPN

Felfedeztem a problémát.

5. lépés. Mi nem stimmel a hozzáférési listával

Megnézem, mire való a L3VPN hozzáférési lista:

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

Látom, hogy az ISAKMP csomagok engedélyezve vannak, így IPsec alagút létesül. De az ESP-hez engedélyező szabály nem található. Valószínűleg a diák összezavarta az icmp-t és az esp-t.

Javítom a hozzáférési listát:

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

6. lépés. Ellenőrzöm a működést

Először is meggyőződöm arról, hogy a L3VPN hozzáférési lista helyes:

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

Most az R1 eszközről indítom a célforgalmat:

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 statisztika ---
4 csomagot küldtek, 4-et fogadtak, 0% csomagveszteség, idő 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 ms

Győzelem. A GRE alagút létrejött. Az IPsec statisztikákban az érkező forgalom számlálója nem nulla:

root@Gate1:~# sa_mgr show
ISAKMP sessionök: 0 indított, 0 válaszolt

ISAKMP kapcsolatok:
Num Conn-id (Helyi cím,Port)-(Távoli cím,Port) Állapot Elküldve Fogadva
1 3 (10.10.10.251,500)-(10.10.10.252,500) aktív 1474 1350

IPsec kapcsolatok:
Num Conn-id (Helyi cím,Port)-(Távoli cím,Port) Protokoll Akció Típus Elküldve Fogadva
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480

A Gate2 átjárón a klogview kimenetében megjelentek üzenetek, miszerint a célforgalom 172.16.0.1->172.17.0.1 sikeresen (PASS) dekódolva lett a LIST szabály alapján a CMAP titkosítótérképen:

root@Gate2:~# klogview -f 0xffffffff
szűrési eredmény az 172.16.0.1->172.17.0.1 csomagra, proto 47, len 112, if eth0: lánc 18 "IPsecPolicy:CMAP", szűrő 25, esemény azonosító IPsec:Protect:CMAP:1:LIST, státusz PASS
átment a 172.16.0.1->172.17.0.1 csomagon, proto 47, len 112, if eth0: dekapszulázva

Összegzés

A diák elrontotta a kimeneti adatokat.
Óvatosabban a MÉ szabályokkal.

Névtelen mérnök
t.me/anonimous_engineer

Forrás: habr.com