ProHoster > Blog > Administrim > Si të bëni troubleshooting për një IPsec VPN vendor. Pjesa 1

Si të bëni troubleshooting për një IPsec VPN vendor. Pjesa 1

Si të bëni troubleshooting për një IPsec VPN vendor. Pjesa 1

Situata

I’m taking a break. Drinking coffee. The student set up a VPN connection between two points and has vanished. Checking: the tunnel is indeed there, but there’s no traffic in the tunnel. The student isn’t answering calls.

I’m boiling water and diving into troubleshooting the C-Terra Gateway. Sharing my experience and methodology.

Të dhënat burimore

Two geographically separated sites are connected by a GRE tunnel. GRE needs to be encrypted:

Si të bëni troubleshooting për një IPsec VPN vendor. Pjesa 1

I’m checking the GRE tunnel’s functionality. To do this, I run a ping from device R1 to the GRE interface of device R2. This is the target traffic for encryption. There’s no response:

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

I’m looking at the logs on Gate1 and Gate2. The log happily reports that the IPsec tunnel has been successfully established, no issues:

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

In the IPsec tunnel statistics on Gate1, I see that the tunnel indeed exists, but the Rcvd counter is reset:

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

I’m troubleshooting C-Terra this way: looking for where the target packets are getting lost on the path from R1 to R2. In the process (spoiler) I’ll find the error.

Diagnostikim

Step 1. What Gate1 receives from R1

I’m using the built-in packet sniffer – tcpdump. I run the sniffer on the internal (Gi0/1 in Cisco-like notation or 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

I see that Gate1 is receiving GRE packets from R1. Moving forward.

Step 2. What Gate1 does with GRE packets

Using the klogview utility, I check what happens to GRE packets inside VPN the C-Terra driver:

root@Gate1:~# klogview -f 0xffffffff

rezultati i filtrimit për paketën që del 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: zinxhiri 4 "IPsecPolicy:CMAP", filtrimi 8, id e ngjarjes IPsec:Protect:CMAP:1:LIST, statusi PASS
encapsulimi me SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
paketa doli 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: e encapsuluar

Shoh që trafiku gre i synuar (proto 47) 172.16.0.1 -> 172.17.0.1 kaloi (PASS) nën rregullin e enkriptimit LIST në hartën e kriptografisë CMAP dhe u enkriptoi (encapsulated). Më pas paketa u rrugëzua (passed out). Në daljen e klogview nuk ka trafik përgjigjës.

Po kontrolloj listat e aksesit nĂ« pajisjen Gate1. Shoh njĂ« listĂ« aksesit LIST, e cila pĂ«rcakton trafikun e synuar pĂ«r enkriptim, qĂ« do tĂ« thotĂ« qĂ« rregulli i MË nuk Ă«shtĂ« konfiguruar:

Gate1#show access-lists
List i zgjeruar IP të aksesit LIST
    10 lejo gre host 172.16.0.1 host 172.17.0.1

Dalja: problemi nuk është në pajisjen Gate1.

Më shumë rreth klogview

Drejtuesi VPN përpunon të gjithë trafikun në rrjet, jo vetëm atë që duhet të enkriptohet. Këto lloj mesazhesh duken në klogview, nëse drejtuesi VPN përpunoi trafikun e rrjetit dhe e kaloi atë në formën e paenkriptuar:

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

rezultati i filtrimit për paketën që del 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: zinxhiri 4 "IPsecPolicy:CMAP": pa ndeshje
paketa doli 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: e filtruar

Shoh që trafiku ICMP (proto 1) 172.16.0.1->172.17.0.1 nuk kaloi (no match) në rregullat e enkriptimit të hartës së kriptografisë CMAP. Paketa u rrugëzua (passed out) në formën e hapur.

Hapi 3. ÇfarĂ« merr Gate2 nga Gate1

Po nis një sniffer në ndërfaqen WAN (eth0) të Gate2:

root@Gate2:~# tcpdump -i eth0
tcpdump: dalja e përmbledhur është e mbështetur, përdorni -v ose -vv për dekodimin e plotë të protokollit
duke dëgjuar në eth0, lloji i lidhjes EN10MB (Ethernet), madhësia e kapjes 262144 bajt
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), gjatësi 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), gjatësi 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), gjatësi 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), gjatësi 140

Shoh që Gate2 po merr paketa ESP nga Gate1.

Hapi 4. ÇfarĂ« bĂ«n Gate2 me paketat ESP

Po nis utilitarin klogview në Gate2:

root@Gate2:~# klogview -f 0xffffffff
rezultati i filtrimit për paketën që vjen 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: zinxhiri 17 "FilterChain:L3VPN", filtrimi 21, statusi DROP
paketa e hequr 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: muri i zjarrit

Shoh që paketat ESP (proto 50) u hodhën (DROP) nga rregulli (L3VPN) i murit të zjarrit (firewall). Po verifikoj që në Gi0/0 është lidhur vërtet lista e aksesit L3VPN:

Gate2#show ip interface gi0/0
GigabitEthernet0/0 është në gjendje, protokolli i linjës është në gjendje
  Adresa e internetit është 10.10.10.252/24
  MTU është 1500 bajt
  Lista e aksesit për daljet nuk është e vendosur
  Lista e aksesit për hyrjen është L3VPN

Kam zbuluar problemin.

Hapi 5. ÇfarĂ« Ă«shtĂ« gabim me listĂ«n e aksesit

Po shoh se çfarë përbën lista e aksesit 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

Shikoj se janë të lejuara paketat ISAKMP, prandaj po vendoset tuneli IPsec. Ndërkohë, nuk ka rregull lehtësues për ESP. Duket se studenti confundoi icmp me esp.

Po rregulloj listën e aksesit:

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

Hapi 6. Po kontrolloj funksionalitetin

Së pari, sigurohem që lista e aksesit L3VPN është e saktë:

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

Tani nga dispositivi R1, po nis trafikun e synuar:

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

Fitorja. Tuneli GRE është vendosur. Numri i trafikut në hyrje në statistikat IPsec nuk është zero:

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

Në portën Gate2, në daljen e klogview janë shfaqur mesazhe se trafiku i synuar 172.16.0.1->172.17.0.1 është dekriptuar me sukses (PASS) nga rregulli LIST në kartën kriptografike 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

PĂ«rfundime

Studenti e prishi daljen.
Kujdes me rregullat e MË.

Inxhinier anonim
t.me/anonimous_engineer

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster