ProHoster > Blog > Adminisztráció > A hazai IPsec VPN hibaelhárítása. 1. rész

A hazai IPsec VPN hibaelhárítása. 1. rész

A hazai IPsec VPN hibaelhárítása. 1. rész

Helyzet

Szabadnap. Kávézom. A diák VPN-kapcsolatot hozott létre két pont között, és eltűnt. Ellenőrzöm: valóban van alagút, de nincs forgalom az alagútban. A tanuló nem válaszol a hívásokra.

Felteszem a vízforralót, és belemerülök az S-Terra Gateway hibaelhárításába. Megosztom a tapasztalataimat és a módszertanomat.

Nyers adatok

A két földrajzilag különálló helyszínt egy GRE alagút köti össze. A GRE-t titkosítani kell:

A hazai IPsec VPN hibaelhárítása. 1. rész

Ellenőrzöm a GRE alagút működését. Ehhez lefuttatom a ping-et az R1 eszközről az R2 eszköz GRE interfészére. Ez a titkosítás célforgalma. Nincs válasz:

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

Megnézem a Gate1 és Gate2 naplóit. A napló boldogan jelenti, hogy az IPsec alagút sikeresen elindult, nincs probléma:

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

A Gate1 IPsec alagútjának statisztikájában azt látom, hogy valóban van alagút, de az Rсvd számláló nullára áll:

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

Az S-Terrát így zavarom: megkeresem, hol vesznek el a célcsomagok az R1-től R2-ig tartó úton. A folyamatban (spoiler) találok egy hibát.

Hibaelhárítás

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

A beépített packet sniffert használom - tcpdump. Elindítom a sniffert a belső (Gi0/1 Cisco-szerű jelöléssel vagy eth1 Debian OS jelöléssel) felületen:

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

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

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

A klogview segédprogram segítségével láthatom, mi történik a GRE-csomagokkal az S-Terra VPN-illesztőprogramban:

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

Úgy látom, hogy a cél GRE forgalom (proto 47) 172.16.0.1 -> 172.17.0.1 a LIST titkosítási szabály alá került a CMAP titkosítási térképen, és be volt zárva. Ezután a csomagot továbbították (elájulták). Nincs válaszforgalom a klogview kimenetben.

Ellenőrzöm a hozzáférési listákat a Gate1 eszközön. Egy hozzáférési listát látok LIST, amely meghatározza a titkosítás célforgalmát, ami azt jelenti, hogy a tűzfalszabályok nincsenek konfigurálva:

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

Következtetés: a probléma nem a Gate1 eszközzel van.

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

A VPN-illesztőprogram kezeli az összes hálózati forgalmat, nem csak a titkosítandó forgalmat. A következő üzenetek láthatók a klogview-ban, ha a VPN-illesztőprogram feldolgozta a hálózati forgalmat és titkosítatlanul továbbította:

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

Úgy látom, hogy az ICMP forgalom (proto 1) 172.16.0.1->172.17.0.1 nem szerepelt (nincs egyezés) a CMAP kriptokártya titkosítási szabályai között. A csomagot tiszta szöveggel irányították (kiadták).

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

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

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

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

4. lépés: Mit csinál a Gate2 az ESP-csomagokkal?

Elindítom a klogview segédprogramot a Gate2-n:

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

Úgy látom, hogy az ESP-csomagokat (proto 50) eldobta (DROP) a tűzfalszabály (L3VPN). Győződjön meg róla, hogy a Gi0/0-hoz valóban van egy L3VPN hozzáférési lista:

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

Felfedeztem a problémát.

5. lépés: Mi a baj a hozzáférési listával?

Megnézem, mi az L3VPN hozzáférési listája:

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

Úgy látom, hogy az ISAKMP csomagok engedélyezettek, tehát IPsec alagút jön létre. Az ESP-hez azonban nincs engedélyező szabály. Nyilvánvalóan a diák összekeverte az icmp-t és az esp-t.

A hozzáférési lista szerkesztése:

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

6. lépés Működés ellenőrzése

Először is megbizonyosodok arról, hogy az L3VPN hozzáférési listája 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 elindítom a célforgalmat az R1 eszközről:

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

Győzelem. A GRE alagutat létrehozták. Az IPsec statisztikákban a bejövő forgalom számlálója nem nulla:

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

A Gate2 átjárón a klogview kimenetben olyan üzenetek jelentek meg, hogy a 172.16.0.1->172.17.0.1 célforgalom sikeresen visszafejtve (PASS) a LIST szabály által a CMAP titkosítási térképen:

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

Eredményei

Egy diák elrontotta a szabadnapját.
Legyen óvatos az ME szabályokkal.

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

Forrás: will.com

Hozzászólás