Diagnosticare una VPN IPsec significa rispondere a una domanda sola, nell’ordine giusto: dove si ferma? La phase 1 non si stabilisce, la phase 2 non trova selettori compatibili, oppure il tunnel è su e il traffico non passa lo stesso? Sono tre problemi diversi, con comandi diversi, e partire dallo strumento sbagliato costa venti minuti. Negli scenari d’esame gli estratti di diagnose sono materiale da leggere: serve saper dire cosa significa una riga.

Cosa dicono i log, e cosa non dicono

Gli eventi di tunnel su e giù finiscono nei log di sistema, sotto System Events; nella CLI la categoria è event. Il filtro si costruisce a pezzi e poi si visualizza:

execute log filter device disk
execute log filter category event
execute log filter field <campo> <valore>
execute log display

Se il FortiGate spedisce i log a FortiAnalyzer, diagnose test application fgtlogd 1 dice se la connessione è viva prima che tu ti chieda perché mancano gli eventi.

Il limite da tenere presente: il log di evento ti dice che il tunnel è salito, non che il traffico ci passa. Un tunnel che negozia benissimo e poi non trasporta un pacchetto non genera nessun evento. In quel caso i log utili sono quelli di traffico e la session table, non gli eventi VPN.

Lo stato in tre comandi

diagnose vpn ike status
diagnose vpn ike gateway list name toB-isp1
diagnose vpn tunnel list name toB-isp1

Il primo è il riepilogo del daemon IKE: quante SA IKE e IPsec sono state create e quante si sono stabilite. Un rapporto come created 2/51 established 2/9 racconta da solo negoziazioni che falliscono in continuazione.

Il secondo è la phase 1. Guarda status: established e da quanto; direction, che vale initiator o responder ed è normale sia opposto sui due lati; proposal, che dice cosa è stato realmente negoziato e non cosa avevi configurato; DPD sent/recv, perché mandare DPD senza riceverne indietro significa peer muto; e la riga addr, dove la porta 500 diventa 4500 quando NAT-T è attivo.

Il terzo è la phase 2 e la parte che trasporta i dati. I campi che decidono la diagnosi:

  • proxyid_num=0 significa nessuna phase 2 stabilita: la phase 1 è su e il tunnel non serve a niente.
  • src: e dst: sono i selettori negoziati. Confrontali con quelli dell’altro lato prima di toccare qualsiasi altra cosa.
  • stat: rxp= txp= rxb= txb= sono i contatori. txp che cresce con rxp fermo a zero è la firma di «io cifro e spedisco, dall’altra parte non torna niente»: ESP filtrato lungo il percorso, rotta di ritorno assente o policy mancante di là. txp fermo a zero è l’opposto — il traffico non arriva nemmeno al tunnel, quindi il problema è rotta o policy locale, non VPN.
  • dpd: mode= e natt: mode= confermano cosa è davvero attivo.

Il debug IKE, filtrato

diagnose debug application ike -1 su un FortiGate con cento tunnel produce output illeggibile. Filtra sempre per peer prima di accendere:

diagnose vpn ike log filter rem-addr4 203.0.113.10
diagnose debug application ike -1
diagnose debug enable

e chiudi con diagnose debug disable seguito da diagnose debug reset.

Nell’output cerca questi punti di svolta. negotiation result, con le righe type=OAKLEY_ENCRYPT_ALG, OAKLEY_HASH_ALG e OAKLEY_GROUP: se la negoziazione non ci arriva mai, i proposal di phase 1 non combaciano — cifratura, hash o gruppo Diffie-Hellman. PSK authentication succeeded e authentication OK: se mancano, la chiave pre-condivisa è sbagliata oppure l’identità non corrisponde. peer identifier IPV4_ADDR: il local ID di un lato deve corrispondere al peer ID atteso dall’altro. selected NAT-T version e NAT not detected dicono se c’è NAT sul percorso. initiator selectors e responder selectors: se la phase 1 è su e qui i due elenchi divergono, hai trovato il problema di phase 2. Infine add IPsec SA: SPIs=, il punto in cui la VPN è formalmente operativa.

Se il debug non stampa niente mentre provi a far salire il tunnel, i pacchetti IKE non stanno arrivando: sniffa UDP 500 e 4500 sulla WAN invece di continuare a fissare il debug.

Tunnel su, traffico no

Quando phase 1 e phase 2 sono entrambe stabilite e il traffico non passa, il colpevole è quasi sempre fuori dalla VPN.

diagnose sniffer packet any 'host 10.2.0.7' 4 0 l
diagnose debug flow filter addr 10.2.0.7
diagnose debug flow show function-name enable
diagnose debug flow trace start 100
diagnose debug enable

Il livello di verbosità 4 dello sniffer stampa l’intestazione con il nome dell’interfaccia: vedi se il pacchetto entra dalla LAN, se esce dall’interfaccia tunnel e se torna indietro. Il debug flow completa il quadro con le tre righe che risolvono il caso: find a route: per il routing, Allowed by Policy-N o il deny corrispondente per le policy, e gli eventuali scarti per reverse path forwarding. Attenzione: il flow non vede il traffico offloaded sui processori NP, quindi prova con ICMP, che non viene offloaded.

Le cause ricorrenti, in ordine di frequenza: manca la policy per una delle due direzioni; il NAT è rimasto abilitato sulla policy VPN e va disabilitato; la rotta verso la subnet remota non c’è, o è la blackhole del wizard a distance 254 che sta facendo il suo mestiere; i selettori di phase 2 sono più stretti del traffico reale.