ProHoster > Blog > Uprava > Kako odpraviti težave z domačim IPsec VPN. 1. del

Kako odpraviti težave z domačim IPsec VPN. 1. del

Kako odpraviti težave z domačim IPsec VPN. 1. del

Razmere

Prosti dan. pijem kavo. Študent je vzpostavil povezavo VPN med dvema točkama in izginil. Preverim: res je predor, a v predoru ni prometa. Študent ne odgovarja na klice.

Pristavim kotliček in se poglobim v odpravljanje težav s prehodom S-Terra. Delim svoje izkušnje in metodologijo.

Surovi podatki

Dve geografsko ločeni lokaciji sta povezani s predorom GRE. GRE mora biti šifriran:

Kako odpraviti težave z domačim IPsec VPN. 1. del

Preverjam delovanje tunela GRE. Da bi to naredil, zaženem ping z naprave R1 na vmesnik GRE naprave R2. To je ciljni promet za šifriranje. Ni odgovora:

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

Pogledam dnevnike na Gate1 in Gate2. Dnevnik veselo poroča, da je bil tunel IPsec uspešno zagnan, brez težav:

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

V statistiki tunela IPsec na Gate1 vidim, da res obstaja tunel, vendar je števec Rsvd ponastavljen na nič:

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

S-Terro povzročam takole: iščem, kje so izgubljeni ciljni paketi na poti od R1 do R2. V procesu (spoiler) bom našel napako.

Odpravljanje težav

Korak 1. Kaj vrata1 prejme od R1

Uporabljam vgrajeno vohanje za pakete - tcpdump. Sniffer zaženem na notranjem vmesniku (Gi0/1 v zapisu, podobnem Ciscu, ali eth1 v zapisu OS Debian):

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

Vidim, da Gate1 prejema pakete GRE od R1. Grem naprej.

2. korak. Kaj počne Gate1 s paketi GRE

S pomočjo pripomočka klogview lahko vidim, kaj se dogaja s paketi GRE znotraj gonilnika S-Terra VPN:

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

Vidim, da je bil ciljni promet GRE (proto 47) 172.16.0.1 -> 172.17.0.1 pod pravilom šifriranja LIST v kripto zemljevidu CMAP in je bil enkapsuliran. Nato je bil paket preusmerjen (odstranjen). V izhodu klogview ni odzivnega prometa.

Preverjam dostopne sezname na napravi Gate1. Vidim en dostopni seznam LIST, ki določa ciljni promet za šifriranje, kar pomeni, da pravila požarnega zidu niso konfigurirana:

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

Zaključek: težava ni v napravi Gate1.

Več o klogview

Gonilnik VPN obravnava ves omrežni promet, ne le promet, ki ga je treba šifrirati. To so sporočila, vidna v klogviewu, če je gonilnik VPN obdelal omrežni promet in ga posredoval nešifriranega:

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

Vidim, da promet ICMP (proto 1) 172.16.0.1->172.17.0.1 ni bil vključen (brez ujemanja) v pravila šifriranja kripto kartice CMAP. Paket je bil preusmerjen (poslan) v čistem besedilu.

Korak 3. Kaj Gate2 prejme od Gate1

Vohanje zaženem na vmesniku WAN (eth0) 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

Vidim, da Gate2 prejema pakete ESP od Gate1.

Korak 4. Kaj Gate2 počne s paketi ESP

Zaženem pripomoček klogview na 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

Vidim, da so bili paketi ESP (proto 50) izpuščeni (DROP) s pravilom požarnega zidu (L3VPN). Prepričam se, da ima Gi0/0 dejansko pripet seznam dostopov L3VPN:

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

Odkril sem težavo.

Korak 5. Kaj je narobe s seznamom dostopov

Pogledam, kakšen je dostopni seznam 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

Vidim, da so paketi ISAKMP dovoljeni, zato je vzpostavljen tunel IPsec. Toda za ESP ni pravila za omogočanje. Očitno je študent zamešal icmp in esp.

Urejanje dostopnega seznama:

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

Korak 6. Preverjanje funkcionalnosti

Najprej se prepričam, da je dostopni seznam L3VPN pravilen:

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

Zdaj zaženem ciljni promet iz naprave 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 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

Zmaga. Vzpostavljen je predor GRE. Števec dohodnega prometa v statistiki IPsec ni enak nič:

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 prehodu Gate2 so se v izhodu klogview pojavila sporočila, da je bil ciljni promet 172.16.0.1->172.17.0.1 uspešno dešifriran (PASS) s pravilom LIST v kripto zemljevidu 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

Rezultati

Študent mu je pokvaril prost dan.
Bodite previdni pri pravilih ME.

Anonimni inženir
t.me/anonymous_engineer

Vir: www.habr.com

Dodaj komentar