🥇Cum să depanezi un VPN IPsec autohton. Partea 1

Situația

Ieșire. Beau cafea. Studentul a configurat o conexiune VPN între două puncte și a dispărut. Verific: tunelul există cu adevărat, dar nu există trafic în tunel. Nu răspunde la apeluri.

Pun ceainicul la fiert și mă dedic depanării S-Terra Gateway. Îmi împărtășesc experiența și metodologia.

Datele originale

Două locații separate geografic sunt conectate printr-un tunel GRE. GRE trebuie criptat:

Verific funcționalitatea tunelului GRE. Pentru aceasta începe să faci ping de pe dispozitivul R1 către interfața GRE a dispozitivului R2. Acesta este traficul țintă pentru criptare. Nu există răspuns:

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

Privesc jurnalele de pe Gate1 și Gate2. Logul anunță cu bucurie că tunelul IPsec a fost stabilit cu succes, fără probleme:

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

În statisticile tunelului IPsec de pe Gate1 văd că tunelul există cu adevărat, dar contorul Rcvd este resetat:

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

Depanez S-Terra astfel: caut unde se pierd pachetele țintă pe ruta de la R1 la R2. În proces (spoiler) voi găsi o eroare.

Troubleshooting

Pasul 1. Ce primește Gate1 de la R1

Folosesc snifferul de pachete integrat – tcpdump. Încep snifferul pe interfața internă (Gi0/1 în notația Cisco-like sau eth1 în notația sistemului de operare 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

Văd că Gate1 primește de la R1 pachete GRE. Merg mai departe.

Pasul 2. Ce face Gate1 cu pachetele GRE

Folosind utilitarul klogview privesc ce se întâmplă cu pachetele GRE în interior VPN driver-ului S-Terra:

root@Gate1:~# klogview -f 0xffffffff

rezultatul filtrării pentru pachetul de ieșire 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
încapsulând cu SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
pachet ieșit 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: encapsulated

Văd că traficul GRE țintă (proto 47) 172.16.0.1 -> 172.17.0.1 a trecut (PASS) sub regula de criptare LIST în planul de criptare CMAP și a fost criptat (encapsulated). Mai departe, pachetul a fost rutat (passed out). Nu există trafic de răspuns în ieșirea klogview.

Verific listele de acces pe dispozitivul Gate1. Văd o listă de acces LIST, care definește traficul țintă pentru criptare, ceea ce înseamnă că regulile MEP nu sunt configurate:

Gate1#show access-lists
Lista de acces IP extinsă LIST
    10 permit gre host 172.16.0.1 host 172.17.0.1

Concluzie: problema nu este pe dispozitivul Gate1.

Informații suplimentare despre klogview

Driverul VPN procesează tot traficul de rețea, nu doar cel care trebuie criptat. Mesaje de acest gen sunt vizibile în klogview, dacă driverul VPN a procesat traficul de rețea și l-a transmis în formă necriptată:

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

rezultatul filtrării pentru pachetul de ieșire 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: chain 4 "IPsecPolicy:CMAP": no match
pachet ieșit 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filtered

Văd că traficul ICMP (proto 1) 172.16.0.1->172.17.0.1 nu a trecut (no match) prin regulile de criptare ale planului CMAP. Pachetul a fost rutat (passed out) în formă deschisă.

Pasul 3. Ce primește Gate2 de la Gate1

Lansez un sniffing pe interfața WAN (eth0) a Gate2:

root@Gate2:~# tcpdump -i eth0
tcpdump: output detaliat restricționat, folosiți -v sau -vv pentru decodificarea completă a protocolului
ascultând pe eth0, tip legătură EN10MB (Ethernet), dimensiunea capturii 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

Văd că Gate2 primește pachete ESP de la Gate1.

Pasul 4. Ce face Gate2 cu pachetele ESP

Lansez utilitarul klogview pe Gate2:

root@Gate2:~# klogview -f 0xffffffff
rezultatul filtrării pentru pachetul de intrare 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: chain 17 "FilterChain:L3VPN", filter 21, status DROP
pachetul de intrare 10.10.10.251->10.10.10.252 a fost respins (DROP), proto 50, len 160, if eth0: firewall

Văd că pachetele ESP (proto 50) au fost respinse (DROP) de regula (L3VPN) a firewall-ului. Verific că lista de acces L3VPN este într-adevăr asociată cu Gi0/0:

Gate2#show ip interface gi0/0
GigabitEthernet0/0 este activ, protocolul de linie este activ
  Adresa Internet este 10.10.10.252/24
  MTU este 1500 bytes
  Lista de acces pentru ieșire nu este setată
  Lista de acces pentru intrare este L3VPN

Am identificat problema.

Pasul 5. Ce nu este în regulă cu lista de acces

Verific ce reprezintă lista de acces 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

Observ că pachetele ISAKMP sunt permise, așadar se stabilește un tunel IPsec. Totuși, nu există nicio regulă de permisiune pentru ESP. Se pare că studentul a confundat icmp cu esp.

Corectez lista de acces:

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

Pasul 6. Verific funcționalitatea

În primul rând, mă asigur că lista de acces L3VPN este corectă:

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

Acum, de pe dispozitivul R1, inițiez traficul țintă:

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

Victorie. Tunelul GRE s-a stabilit. Contorul traficului de intrare din statistica IPsec nu este 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

Pe gateway-ul Gate2, în ieșirea klogview au apărut mesaje că traficul țintă 172.16.0.1->172.17.0.1 a fost decriptat cu succes (PASS) de regula LIST în harta criptografică 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

Concluzii

Studentul a stricat ieșirea.
Fii mai atent cu regulile ME.

Inginer anonim
t.me/anonimous_engineer

Sursa: habr.com