🥇Come risolvere i problemi dell'IPsec VPN domestico. Parte 1

Situazione

Uscita. Bevo caffè. Lo studente ha configurato una connessione VPN tra due punti e poi è scomparso. Controllo: il tunnel c'è davvero, ma non c'è traffico nel tunnel. Lo studente non risponde alle chiamate.

Metto il bollitore e mi immergo nel troubleshooting di C-Terra Gateway. Condivido la mia esperienza e metodologia.

Dati di origine

Due siti fisicamente separati sono collegati tramite un tunnel GRE. Il GRE deve essere crittografato:

Controllo il funzionamento del tunnel GRE. Per farlo, avvio un ping dal dispositivo R1 all'interfaccia GRE del dispositivo R2. Questo è il traffico di destinazione da crittografare. Non ricevo risposta:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) byte di dati.

--- 1.1.1.2 statistiche ping ---
4 pacchetti trasmessi, 0 ricevuti, 100% perdita di pacchetti, tempo 3057ms

Controllo i log su Gate1 e Gate2. Il log comunica con entusiasmo che il tunnel IPsec è stato attivato con successo, nessun problema:

root@Gate1:~# cat /var/log/cspvpngate.log
5 Aug  16:14:23 localhost  vpnsvc: 00100119  connessione IPSec 5 stabilita, selettore di traffico 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id "10.10.10.251", Filtro 
IPsec:Proteggere:CMAP:1:LIST, Azione IPsec Azione:CMAP:1, Regola IKERule:CMAP:1

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

root@Gate1:~# sa_mgr show
Sessioni ISAKMP: 0 iniziate, 0 risposte

Connessioni ISAKMP:
Num Conn-id (Indirizzo Locale,Porta)-(Indirizzo Remoto,Porta) Stato Inviato Ricevuto
1 3 (10.10.10.251,500)-(10.10.10.252,500) attivo 1070 1014

Connessioni IPsec:
Num Conn-id (Indirizzo Locale,Porta)-(Indirizzo Remoto,Porta) Protocollo Tipo Azione Inviato Ricevuto
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0

Faccio troubleshooting su C-Terra in questo modo: cerco dove si perdono i pacchetti di destinazione sul percorso da R1 a R2. Nel processo (spoiler) troverò un errore.

Risolvere i problemi

Passo 1. Cosa riceve Gate1 da R1

Uso il pacchetto sniffer integrato – tcpdump. Avvio lo sniffer sull'interfaccia interna (Gi0/1 nella notazione simile a Cisco o eth1 nella notazione del sistema operativo Debian):

root@Gate1:~# tcpdump -i eth1

tcpdump: output dettagliato nascosto, usa -v o -vv per una decodifica protocollo completa
in ascolto su eth1, tipo link EN10MB (Ethernet), dimensione cattura 262144 byte
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta di echo ICMP, id 2083, seq 1, lunghezza 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta di echo ICMP, id 2083, seq 2, lunghezza 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta di echo ICMP, id 2083, seq 3, lunghezza 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, lunghezza 92: IP 1.1.1.1 > 1.1.1.2: richiesta di echo ICMP, id 2083, seq 4, lunghezza 64

Vedo che Gate1 riceve pacchetti GRE da R1. Procedo oltre.

Passo 2. Cosa fa Gate1 con i pacchetti GRE

Con l'utility klogview controllo cosa succede con i pacchetti GRE all'interno VPN del driver di C-Terra:

root@Gate1:~# klogview -f 0xffffffff

risultato della filtrazione per pacchetto uscente 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: catena 4 "IPsecPolicy:CMAP", filtro 8, id evento IPsec:Protect:CMAP:1:LIST, stato PASS
incapsulando con SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
pacchetto uscente passato 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: incapsulato

Vedo che il traffico GRE target (proto 47) 172.16.0.1 -> 172.17.0.1 è passato (PASS) sotto la regola di crittografia LIST nella mappa crittografica CMAP ed è stato crittografato (incapsulato). Successivamente, il pacchetto è stato instradato (pacchetto passato). Non ci sono traffico di risposta nell'output di klogview.

Controllo le liste di accesso sul dispositivo Gate1. Vedo una lista di accesso LIST, che definisce il traffico target per la crittografia, il che significa che le regole MЭ non sono impostate:

Gate1#show access-lists
Lista di accesso IP estesa LIST
    10 consenti gre host 172.16.0.1 host 172.17.0.1

Output: problema non sul dispositivo Gate1.

Informazioni supplementari su klogview

Il driver VPN gestisce tutto il traffico di rete, non solo quello che deve essere crittografato. Ecco quali messaggi sono visibili in klogview, se il driver VPN ha elaborato il traffico di rete e lo ha trasmesso in forma non crittografata:

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

risultato della filtrazione per pacchetto uscente 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: catena 4 "IPsecPolicy:CMAP": nessuna corrispondenza
pacchetto uscente passato 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filtrato

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

Passo 3. Cosa riceve Gate2 da Gate1

Avvio uno sniffer sull'interfaccia WAN (eth0) di Gate2:

root@Gate2:~# tcpdump -i eth0
tcpdump: output dettagliato soppresso, usare -v o -vv per decodifica completa del protocollo
in ascolto su eth0, tipo di collegamento EN10MB (Ethernet), dimensione di cattura 262144 byte
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), lunghezza 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), lunghezza 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), lunghezza 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), lunghezza 140

Vedo che Gate2 riceve pacchetti ESP da Gate1.

Passo 4. Cosa fa Gate2 con i pacchetti ESP

Avvio l'utilità klogview su Gate2:

root@Gate2:~# klogview -f 0xffffffff
risultato della filtrazione per pacchetto in entrata 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: catena 17 "FilterChain:L3VPN", filtro 21, stato DROP
pacchetto in entrata droppato 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall

Vedo che i pacchetti ESP (proto 50) sono stati bloccati (DROP) dalla regola (L3VPN) del firewall. Mi assicuro che la Gi0/0 sia effettivamente associata alla lista di accesso L3VPN:

Gate2#show ip interface gi0/0
GigabitEthernet0/0 è attivo, il protocollo di linea è attivo
  Indirizzo Internet è 10.10.10.252/24
  MTU è 1500 byte
  La lista di accesso in uscita non è impostata
  La lista di accesso in entrata è L3VPN

Problema individuato.

Passo 5. Cosa c'è di sbagliato nella lista di accesso

Guardo cosa rappresenta la lista di accesso L3VPN:

Gate2#show access-list L3VPN
Elenco di accesso IP esteso L3VPN
    10 consenti udp host 10.10.10.251 any eq isakmp
    20 consenti udp host 10.10.10.251 any eq non500-isakmp
    30 consenti icmp host 10.10.10.251 any

Vedo che i pacchetti ISAKMP sono consentiti, quindi viene stabilito un tunnel IPsec. Tuttavia, non c'è una regola di autorizzazione per ESP. Evidentemente, lo studente ha confuso icmp ed esp.

Correggo l'elenco di accesso:

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

Passo 6. Controllo il funzionamento

Per prima cosa mi assicuro che l'elenco di accesso L3VPN sia corretto:

Gate2#show access-list L3VPN
Elenco di accesso IP esteso L3VPN
    10 consenti udp host 10.10.10.251 any eq isakmp
    20 consenti udp host 10.10.10.251 any eq non500-isakmp
    30 consenti esp host 10.10.10.251 any

Ora Avvio il traffico di destinazione dal dispositivo R1:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes di dati.
64 bytes da 1.1.1.2: icmp_seq=1 ttl=64 time=35.3 ms
64 bytes da 1.1.1.2: icmp_seq=2 ttl=64 time=3.01 ms
64 bytes da 1.1.1.2: icmp_seq=3 ttl=64 time=2.65 ms
64 bytes da 1.1.1.2: icmp_seq=4 ttl=64 time=2.87 ms

--- statistiche ping 1.1.1.2 ---
4 pacchetti trasmessi, 4 ricevuti, 0% perdita di pacchetti, tempo 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 ms

Vittoria. Il tunnel GRE è stato stabilito. Il contatore del traffico in entrata nella statistica IPsec non è zero:

root@Gate1:~# sa_mgr show
Sessioni ISAKMP: 0 iniziate, 0 risposte

Connessioni ISAKMP:
Num Conn-id (Indirizzo locale, Porta)-(Indirizzo remoto, Porta) Stato Inviati Ricevuti
1 3 (10.10.10.251,500)-(10.10.10.252,500) attivo 1474 1350

Connessioni IPsec:
Num Conn-id (Indirizzo locale, Porta)-(Indirizzo remoto, Porta) Protocollo Azione Tipo Inviati Ricevuti
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480

Sul gateway Gate2, nel output di klogview sono apparse le segnalazioni che il traffico di destinazione 172.16.0.1->172.17.0.1 è stato decrittato (decapsulato) con successo dalla regola LIST nella mappa crittografica CMAP:

root@Gate2:~# klogview -f 0xffffffff
risultato della filtrazione per il pacchetto in entrata 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, stato PASS
passato nel pacchetto 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulato

Conclusioni

Lo studente ha danneggiato l'uscita.
Fai attenzione con le regole del ME.

Ingegnere anonimo
t.me/anonimous_engineer

Fonte: habr.com