ProHoster > Blog > Beheer > Hoe een binnenlandse IPsec VPN te troubleshooten. Deel 1

Hoe een binnenlandse IPsec VPN te troubleshooten. Deel 1

Hoe een binnenlandse IPsec VPN te troubleshooten. Deel 1

Situatie

Weekend. Ik drink koffie. De student heeft een VPN-verbinding tussen twee punten opgezet en is verdwenen. Ik controleer: de tunnel is er daadwerkelijk, maar er is geen verkeer in de tunnel. De student reageert niet op telefoontjes.

Ik zet de waterkoker aan en duik in de troubleshooting van de C-Terra Gateway. Ik deel mijn ervaringen en methodologie.

Brongegevens

Twee geografisch gescheiden locaties zijn verbonden via een GRE-tunnel. GRE moet versleuteld worden:

Hoe een binnenlandse IPsec VPN te troubleshooten. Deel 1

Ik controleer de werking van de GRE-tunnel. Hiervoor stuur ik een ping vanaf apparaat R1 naar de GRE-interface van apparaat R2. Dit is het doelverkeer voor versleuteling. Er is geen antwoord:

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

--- 1.1.1.2 pingstatistieken ---
4 pakketten verzonden, 0 ontvangen, 100% pakketverlies, tijd 3057ms

Ik bekijk de logs op Gate1 en Gate2. De log meldt vrolijk dat de IPsec-tunnel succesvol is opgezet, geen problemen:

root@Gate1:~# cat /var/log/cspvpngate.log
Aug 5 16:14:23 localhost vpnsvc: 00100119  IPSec-verbinding 5 gemaakt, verkeersselector 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 de statistieken van de IPsec-tunnel op Gate1 zie ik dat de tunnel er inderdaad is, maar de Rcvd-teller is gereset:

root@Gate1:~# sa_mgr show
ISAKMP-sessies: 0 geĆÆnitieerd, 0 gereageerd

ISAKMP-verbindingen:
Num Conn-id (Lokale Addr,Port)-(Afstands Addr,Port) Staat Verzonden Ontvangen
1 3 (10.10.10.251,500)-(10.10.10.252,500) actief 1070 1014

IPsec-verbindingen:
Num Conn-id (Lokale Addr,Port)-(Afstands Addr,Port) Protocol Actie Type Verzonden Ontvangen
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0

Ik ben bezig met troubleshooting van de C-Terra: ik zoek waar de doelpakketten verloren gaan op de route van R1 naar R2. In het proces (spoiler) zal ik de fout vinden.

Probleemoplossing

Stap 1. Wat ontvangt Gate1 van R1

Ik gebruik de ingebouwde pakket-sniffer ā€“ tcpdump. Ik start de sniffer op de interne (Gi0/1 in Cisco-achtige notatie of eth1 in Debian OS-notatie) interface:

root@Gate1:~# tcpdump -i eth1

tcpdump: gedetailleerde output onderdrukt, gebruik -v of -vv voor volledige protocoldcode
luisterend op eth1, link-type EN10MB (Ethernet), capture-grootte 262144 bytes
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lengte 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 1, lengte 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lengte 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 2, lengte 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lengte 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 3, lengte 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lengte 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 4, lengte 64

Ik zie dat Gate1 GRE-pakketten ontvangt van R1. Ik ga verder.

Stap 2. Wat doet Gate1 met de GRE-pakketten

Met de klogview-tool bekijk ik wat er gebeurt met de GRE-pakketten binnen VPN de C-Terra-driver:

root@Gate1:~# klogview -f 0xffffffff

filtratie resultaat voor uit pakket 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: keten 4 "IPsecPolicy:CMAP", filter 8, gebeurtenis id IPsec:Protect:CMAP:1:LIST, status PASS
in kapselen met SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
verzonden uit pakket 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: ingekapseld

Ik zie dat het doel-GRE verkeer (proto 47) 172.16.0.1 -> 172.17.0.1 is onderworpen (PASS) aan de encryptieregel LIST in het cryptografische kaart CMAP en is gecodeerd (ingekapseld). Vervolgens is het pakket gerouteerd (verzonden). Er is geen terugverkeer te zien in de uitvoer van klogview.

Ik controleer de toegangslijsten op het apparaat Gate1. Ik zie Ć©Ć©n toegangslijst LIST die het doelverkeer voor encryptie bepaalt, dus er zijn geen MŠ­-regels ingesteld:

Gate1#show access-lists
Uitgebreide IP-toegangslijst LIST
    10 staat gre toe host 172.16.0.1 host 172.17.0.1

Conclusie: het probleem ligt niet op het apparaat Gate1.

Meer over klogview

De VPN-driver verwerkt al het netwerkverkeer, niet alleen het verkeer dat gecodeerd moet worden. Dit soort berichten zijn zichtbaar in klogview als de VPN-driver netwerkverkeer heeft verwerkt en ongecodeerd heeft verzonden:

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

filtratie resultaat voor uit pakket 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: keten 4 "IPsecPolicy:CMAP": geen overeenkomst
verzonden uit pakket 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: gefilterd

Ik zie dat het ICMP verkeer (proto 1) 172.16.0.1->172.17.0.1 niet overeenkomt (geen overeenkomst) met de encryptieregels van het cryptografische kaart CMAP. Het pakket is gerouteerd (verzonden) in ongecodeerde vorm.

Stap 3. Wat ontvangt Gate2 van Gate1

Ik start een sniffer op de WAN (eth0) interface van Gate2:

root@Gate2:~# tcpdump -i eth0
tcpdump: gedetailleerde uitvoer onderdrukt, gebruik -v of -vv voor volledige protocol-decoding
luistert op eth0, link-type EN10MB (Ethernet), vastleggrootte 262144 bytes
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), lengte 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), lengte 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), lengte 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), lengte 140

Ik zie dat Gate2 ESP-pakketten ontvangt van Gate1.

Stap 4. Wat doet Gate2 met de ESP-pakketten

Ik start de tool klogview op Gate2:

root@Gate2:~# klogview -f 0xffffffff
filtratie resultaat voor in pakket 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: keten 17 "FilterChain:L3VPN", filter 21, status DROP
gedropt in pakket 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall

Ik zie dat de ESP-pakketten (proto 50) zijn gedropt (DROP) door de regel (L3VPN) van de firewall. Ik bevestig dat de toegangslijst L3VPN daadwerkelijk aan Gi0/0 is gekoppeld:

Gate2#show ip interface gi0/0
GigabitEthernet0/0 is up, lijnprotocol is up
  Internetadres is 10.10.10.252/24
  MTU is 1500 bytes
  Uitgaande toegangslijst is niet ingesteld
  Inkomende toegangslijst is L3VPN

Het probleem is ontdekt.

Stap 5. Wat is er mis met de toegangslijst

Ik kijk naar wat de toegangslijst L3VPN inhoudt:

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

Ik zie dat ISAKMP-pakketten zijn toegestaan, dus de IPsec-tunnel wordt ingesteld. Maar er is geen regel die ESP toestaat. Waarschijnlijk heeft de student icmp en esp verwisseld.

Ik pas de toegangs lijst aan:

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

Stap 6. Ik controleer de werking

Als eerste zorg ik ervoor dat de toegangs lijst L3VPN correct is:

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 start ik doelverkeer vanaf apparaat 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 tijd=35.3 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 tijd=3.01 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 tijd=2.65 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 tijd=2.87 ms

--- 1.1.1.2 ping statistieken ---
4 pakketten verzonden, 4 ontvangen, 0% pakketverlies, tijd 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 ms

Overwinning. De GRE-tunnel is opgezet. De teller voor inkomend verkeer in de IPsec-statistieken is niet nul:

root@Gate1:~# sa_mgr show
ISAKMP-sessies: 0 geĆÆnitieerd, 0 gereageerd

ISAKMP-verbindingen:
Num Conn-id (Lokale Addr,Port)-(Externe Addr,Port) Staat Verzonden On ontvangen
1 3 (10.10.10.251,500)-(10.10.10.252,500) actief 1474 1350

IPsec-verbindingen:
Num Conn-id (Lokale Addr,Port)-(Externe Addr,Port) Protocol Actie Type Verzonden Ontvangen
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480

Op de gateway Gate2 zijn in de uitvoer van klogview berichten verschenen dat het doelverkeer 172.16.0.1->172.17.0.1 succesvol (PASS) is ontsleuteld (decapsulated) door regel LIST in het cryptokaart CMAP:

root@Gate2:~# klogview -f 0xffffffff
filtratie resultaat voor inkomend pakket 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: keten 18 "IPsecPolicy:CMAP", filter 25, gebeurtenis id IPsec:Protect:CMAP:1:LIST, status PASS
ingevoerd pakket 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulated

Conclusies

De student heeft de uitvoer verknald.
Voorzichtig zijn met de ME-regels.

Anonieme ingenieur
t.me/anonimous_engineer

Bron: habr.com

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster