ProHoster > Blog > Administration > Sådan fejlfinder du indenlandsk IPsec VPN. Del 1

Sådan fejlfinder du indenlandsk IPsec VPN. Del 1

Sådan fejlfinder du indenlandsk IPsec VPN. Del 1

Situation

Ude. Jeg drikker kaffe. Studenten har opsat en VPN-forbindelse mellem to punkter og er forsvundet. Jeg tjekker: tunnelen er der faktisk, men der er ingen trafik i tunnelen. Studenten svarer ikke på opkaldene.

Jeg sætter kedlen over og dykker ned i fejlfinding af C-Terra Gateway. Jeg deler min erfaring og metode.

Kildedata

To geografisk adskilte steder er forbundet med en GRE-tunnel. GRE skal krypteres:

Sådan fejlfinder du indenlandsk IPsec VPN. Del 1

Jeg tjekker funktionaliteten af GRE-tunnelen. For at gøre dette pinger jeg fra enhed R1 til GRE-interfacet på enhed R2. Dette er den målrettede trafik, der skal krypteres. Der er ingen svar:

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

--- 1.1.1.2 ping-statistik ---
4 pakker sendt, 0 modtaget, 100% pakke-tab, tid 3057ms

Jeg ser på loggene på Gate1 og Gate2. Loggen rapporterer gladeligt, at IPsec-tunnelen er blevet oprettet, ingen problemer:

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

I statistikken for IPsec-tunnelen på Gate1 kan jeg se, at tunnelen faktisk er der, men Rсvd-tælleren er nulstillet:

root@Gate1:~# sa_mgr show
ISAKMP sessioner: 0 initieret, 0 besvaret

ISAKMP forbindelser:
Num Conn-id (Lokal Addr,Port)-(Fjern Addr,Port) Status Sendt Modtaget
1 3 (10.10.10.251,500)-(10.10.10.252,500) aktiv 1070 1014

IPsec forbindelser:
Num Conn-id (Lokal Addr,Port)-(Fjern Addr,Port) Protokol Handling Type Sendt Modtaget
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0

Jeg fejlfinder C-Terra således: jeg søger efter, hvor de målrettede pakker går tabt på vejen fra R1 til R2. Undervejs (spoiler) finder jeg en fejl.

Fejlfinding

Trin 1. Hvad modtager Gate1 fra R1

Jeg bruger den indbyggede pakkesniffer – tcpdump. Jeg starter snifferen på det interne (Gi0/1 i Cisco-lignende notation eller eth1 i Debian OS notation) interface:

root@Gate1:~# tcpdump -i eth1

tcpdump: detaljeret output undertrykt, brug -v eller -vv for fuld protokol dekodning
lytter på eth1, link-type EN10MB (Ethernet), optagelsesstørrelse 262144 bytes
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, længde 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo-anmodning, id 2083, sekvens 1, længde 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, længde 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo-anmodning, id 2083, sekvens 2, længde 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, længde 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo-anmodning, id 2083, sekvens 3, længde 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, længde 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo-anmodning, id 2083, sekvens 4, længde 64

Jeg ser, at Gate1 modtager GRE-pakker fra R1. Jeg går videre.

Trin 2. Hvad gør Gate1 med GRE-pakkerne

Med værktøjet klogview ser jeg, hvad der sker med GRE-pakkerne indeni VPN driveren C-Terra:

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

Jeg ser, at den målrettede GRE-trafik (proto 47) 172.16.0.1 -> 172.17.0.1 kom (PASS) under krypteringsreglen LIST i krypteringskortet CMAP og blev krypteret (encapsulated). Derefter blev pakken routet (passed out). Der er ingen svartrafik i klogview-outputtet.

Jeg tjekker adgangslisten på enheden Gate1. Jeg ser én adgangsliste LIST, der definerer målrettet trafik til kryptering, hvilket betyder, at der ikke er konfigureret IPsec-regler:

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

Konklusion: Problemet ligger ikke på enheden Gate1.

Yderligere om klogview

VPN-driveren håndterer al netværkstrafik, ikke kun den, der skal krypteres. Sådanne meddelelser ses i klogview, hvis VPN-driveren har behandlet netværkstrafikken og sendt den i ukrypteret form:

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

Jeg ser, at ICMP-trafik (proto 1) 172.16.0.1->172.17.0.1 ikke kom (no match) ind under krypteringsreglerne i krypteringskortet CMAP. Pakken blev routet (passed out) i åben form.

Trin 3. Hvad modtager Gate2 fra Gate1

Jeg starter en sniffer på WAN (eth0) interfacet på 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

Jeg ser, at Gate2 modtager ESP-pakker fra Gate1.

Trin 4. Hvad gør Gate2 med ESP-pakkerne

Jeg starter klogview-værktøjet på 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

Jeg ser, at ESP-pakkerne (proto 50) blev droppet (DROP) af reglen (L3VPN) i firewall'en. Jeg sikrer mig, at adgangslisten L3VPN virkelig er tilknyttet Gi0/0:

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

Problemet er identificeret.

Trin 5. Hvad er galt med adgangslisten

Jeg ser, hvad adgangslisten L3VPN indeholder:

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

Jeg kan se, at ISAKMP-pakker er tilladt, så IPsec-tunnelen oprettes. Der er derimod ikke noget tilladelsesregel for ESP. Det ser ud til, at eleven forvekslede icmp med esp.

Jeg redigerer adgangslisten:

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

Trin 6. Jeg kontrollerer funktionaliteten

Først sikrer jeg mig, at adgangslisten L3VPN er korrekt:

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

Nu starter jeg den målrettede trafik fra enheden 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

Sejr. GRE-tunnelen er blevet oprettet. Tælleren for indgående trafik i IPsec-statistikken er ikke nul:

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

På gatewayen Gate2 er der kommet beskeder i klogview om, at den målrettede trafik 172.16.0.1->172.17.0.1 er blevet succesfuldt (PASS) dekrypteret (decapsulated) af reglen LIST i kryptokortet 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

Resumé

Eleven har ødelagt output.
Vær forsigtig med MЭ-reglerne.

Anonym ingeniør
t.me/anonimous_engineer

Kilde: habr.com

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster