🥇Come risolvere i problemi con IPsec VPN nazionali. Parte 1

Situazione

È il weekend. Sto bevendo un caffè. Lo studente ha configurato una connessione VPN tra due punti ed è 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 del Gateway S-Terra. Condivido la mia esperienza e metodologia.

Dati di origine

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

Controllo la funzionalità del tunnel GRE. A tal fine, eseguo un ping dall'apparecchiatura R1 all'interfaccia GRE dell'apparecchiatura R2. Questo è il traffico target per la crittografia. Non ci sono risposte:

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

Controllo i log su Gate1 e Gate2. Il log riporta con gioia che il tunnel IPsec è stato stabilito con successo, senza problemi:

root@Gate1:~# cat /var/log/cspvpngate.log
Aug  5 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:Protect:CMAP:1:LIST, AzioneIPsec AzioneIPsec:CMAP:1, RegolaIKE RegolaIKE: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 initiati, 0 risposto

Collegamenti 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 1070 1014

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

Sto eseguendo il troubleshooting su C-Terra: cerco dove si perdono i pacchetti di destinazione lungo il percorso da R1 a R2. Nel processo (spoiler) troverò un errore.

Troubleshooting

Passo 1. Cosa riceve Gate1 da R1

Uso il pacchetto sniffer integrato – tcpdump. Avvio lo sniffer sull'interfaccia interna (Gi0/1 in notazione Cisco-like o eth1 in notazione Debian):

root@Gate1:~# tcpdump -i eth1

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

Vedo che Gate1 riceve pacchetti GRE da R1. Proseguo.

Passo 2. Cosa fa Gate1 con i pacchetti GRE

Utilizzo di klogview per osservare cosa succede con i pacchetti GRE all'interno VPN del driver C-Terra:

root@Gate1:~# klogview -f 0xffffffff

risultato della filtra per pacchetto in uscita 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 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 in uscita 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: incapsulato

Osservo che il traffico GRE di destinazione (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 (passato fuori). Non ci sono traffico di risposta nell'output di klogview.

Controllo le liste di accesso sul dispositivo Gate1. Vedo un elenco di accesso LIST, che definisce il traffico di destinazione per la crittografia, quindi le regole MЭ non sono configurate:

Gate1#show access-lists
Elenco IP di accesso esteso LIST
    10 permit gre host 172.16.0.1 host 172.17.0.1

Conclusione: il problema non si trova sul dispositivo Gate1.

Ulteriori informazioni su klogview

Il driver VPN gestisce tutto il traffico di rete, non solo quello che deve essere crittografato. Questi messaggi possono essere visti 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 filtra per pacchetto in uscita 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: chain 4 "IPsecPolicy:CMAP": nessuna corrispondenza
pacchetto in uscita 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 è stato incluso (no match) nelle regole di crittografia della mappa CMAP. Il pacchetto è stato instradato (passed out) in chiaro.

Passo 3. Cosa riceve Gate2 da Gate1

Avvio il sniffing sull'interfaccia WAN (eth0) di Gate2:

root@Gate2:~# tcpdump -i eth0
tcpdump: output dettagliato nascosto, usa -v o -vv per una decodifica completa del protocollo
in ascolto su eth0, tipo link 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 filtra per pacchetto in entrata 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: chain 17 "FilterChain:L3VPN", filtro 21, stato DROP
pacchetto in entrata bloccato 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. Verifico che la lista di accesso L3VPN sia effettivamente collegata a Gi0/0:

Gate2#show ip interface gi0/0
GigabitEthernet0/0 è attivo, il protocollo di linea è attivo
  L'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

Ho trovato il problema.

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

Guardo cosa rappresenta l'elenco degli accessi 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 autorizzati, quindi viene stabilito un tunnel IPsec. Tuttavia, non c'è una regola di autorizzazione per ESP. Evidentemente, lo studente ha confuso icmp e esp.

Correggo l'elenco degli accessi:

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

Passaggio 6. Controllo il funzionamento

Per prima cosa mi assicuro che l'elenco degli accessi L3VPN sia corretto:

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 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 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 statistiche ping ---
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 nelle statistiche IPsec non è a zero:

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

ISAKMP connections:
Num Conn-id (Indirizzo Locale,Porto)-(Indirizzo Remoto,Porto) 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,Porto)-(Indirizzo Remoto,Porto) Protocollo Tipo Azione Inviati Ricevuti
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480

Sul gateway Gate2 è comparso nel output di klogview un messaggio che il traffico destinato 172.16.0.1->172.17.0.1 è stato decrittografato (decapsulato) con successo (PASS) dalla regola LIST nella mappa crittografica CMAP:

root@Gate2:~# klogview -f 0xffffffff
risultato della filtra per pacchetto in entrata 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 18 "IPsecPolicy:CMAP", filtro 25, id evento IPsec:Protect:CMAP:1:LIST, stato PASS
pacchetto in entrata 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulato

Risultati

Lo studente ha rovinato l'uscita.
Fai attenzione con le regole MЭ.

Ingegnere anonimo
t.me/anonimous_engineer

Fonte: habr.com