ProHoster > blog > amministrazione > Come risolvere i problemi relativi alla VPN IPsec domestica. Parte 1

Come risolvere i problemi relativi alla VPN IPsec domestica. Parte 1

Come risolvere i problemi relativi alla VPN IPsec domestica. Parte 1

La situazione

Giorno libero. Bevo caffè. Lo studente ha stabilito una connessione VPN tra due punti ed è scomparso. Controllo: il tunnel c'è davvero, ma nel tunnel non c'è traffico. Lo studente non risponde alle chiamate.

Accendo il bollitore e mi immergo nella risoluzione dei problemi di S-Terra Gateway. Condivido la mia esperienza e metodologia.

Dati iniziali

I due siti geograficamente separati sono collegati da un tunnel GRE. GRE deve essere crittografato:

Come risolvere i problemi relativi alla VPN IPsec domestica. Parte 1

Sto verificando la funzionalità del tunnel GRE. Per fare ciò, eseguo il ping dal dispositivo R1 all'interfaccia GRE del dispositivo R2. Questo è il traffico di destinazione per la crittografia. Nessuna risposta:

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

Guardo i log su Gate1 e Gate2. Il registro riporta felicemente che il tunnel IPsec è stato avviato con successo, senza problemi:

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

Nelle statistiche del tunnel IPsec su Gate1 vedo che il tunnel esiste davvero, ma il contatore Rсvd è azzerato:

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

Disturbo S-Terra in questo modo: cerco dove i pacchetti target vengono persi nel percorso da R1 a R2. Nel procedimento (spoiler) troverò un errore.

Risoluzione dei problemi

Passaggio 1. Cosa riceve Gate1 da R1

Utilizzo lo sniffer di pacchetti integrato: tcpdump. Lancio lo sniffer sull'interfaccia interna (Gi0/1 in notazione simile a Cisco o eth1 in notazione del sistema operativo 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

Vedo che Gate1 riceve pacchetti GRE da R1. Sto andando avanti.

Passaggio 2. Cosa fa Gate1 con i pacchetti GRE

Utilizzando l'utilità klogview posso vedere cosa sta succedendo con i pacchetti GRE all'interno del driver VPN S-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

Vedo che il traffico GRE di destinazione (proto 47) 172.16.0.1 -> 172.17.0.1 rientrava nella regola di crittografia LIST nella mappa crittografica CMAP ed era incapsulato. Successivamente, il pacchetto è stato instradato (svenuto). Non c'è traffico di risposta nell'output di klogview.

Sto controllando gli elenchi di accesso sul dispositivo Gate1. Vedo un elenco di accesso LIST, che definisce il traffico di destinazione per la crittografia, il che significa che le regole del firewall non sono configurate:

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

Conclusione: il problema non riguarda il dispositivo Gate1.

Maggiori informazioni su klogview

Il driver VPN gestisce tutto il traffico di rete, non solo il traffico che deve essere crittografato. Questi sono i messaggi visibili in klogview se il driver VPN ha elaborato il traffico di rete e lo ha trasmesso in chiaro:

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

Vedo che il traffico ICMP (proto 1) 172.16.0.1->172.17.0.1 non è stato incluso (nessuna corrispondenza) nelle regole di crittografia della scheda crittografica CMAP. Il pacchetto è stato instradato (svenuto) in chiaro.

Passaggio 3. Ciò che Gate2 riceve da Gate1

Lancio lo sniffer sull'interfaccia 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

Vedo che Gate2 riceve pacchetti ESP da Gate1.

Passaggio 4. Cosa fa Gate2 con i pacchetti ESP

Lancio l'utilità klogview su 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

Vedo che i pacchetti ESP (proto 50) sono stati eliminati (DROP) dalla regola del firewall (L3VPN). Mi assicuro che Gi0/0 abbia effettivamente un elenco di accesso L3VPN allegato:

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

Ho scoperto il problema.

Passaggio 5. Cosa c'è che non va nell'elenco di accesso

Guardo qual è la lista di accesso 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

Vedo che i pacchetti ISAKMP sono consentiti, quindi viene stabilito un tunnel IPsec. Ma non esiste una regola di abilitazione per l'ESP. A quanto pare, lo studente ha confuso icmp ed esp.

Modifica dell'elenco di accesso:

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

Passaggio 6. Verifica della funzionalità

Innanzitutto mi assicuro che la lista di accesso L3VPN sia corretta:

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

Ora lancio il traffico target dal dispositivo 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

Vittoria. Il tunnel GRE è stato realizzato. Il contatore del traffico in entrata nelle statistiche IPsec non è 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

Sul gateway Gate2, nell'output di klogview, sono apparsi messaggi che indicavano che il traffico di destinazione 172.16.0.1->172.17.0.1 è stato decrittografato con successo (PASS) dalla regola LIST nella mappa crittografica 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

Risultati di

Uno studente gli ha rovinato la giornata libera.
Fai attenzione alle regole ME.

Ingegnere anonimo
t.me/anonymous_engineer

Fonte: habr.com

Aggiungi un commento