I due laboratori di questo modulo sono lo stesso esercizio visto da due lati: nel primo si legge una negoziazione IKE che non si completa, nel secondo si cerca l’errore di configurazione che l’ha resa impossibile. Tenerli separati distingue chi diagnostica da chi indovina.

Lab: diagnosticare i problemi IKE

Una negoziazione si legge dal principio, perché ogni fase fallisce in modo diverso. La Phase I autentica i peer — con certificato o con pre-shared secret — genera la chiave Diffie-Hellman condivisa e concorda i metodi per la fase successiva: il risultato è l’IKE SA. IKEv1 la conduce in Main Mode, sei pacchetti, predefinito e più resistente al denial of service, oppure in Aggressive Mode, tre pacchetti, tenuto per interoperabilità con soluzioni di terze parti. La Phase II, il Quick Mode, usa quella protezione per scambiare il materiale delle chiavi IPsec e produce l’IPsec SA, che governa il traffico vero.

IKEv2 è automatico per il traffico IPv6 e nelle comunità in modalità semplificata si sceglie fra “IKEv2 only”, “Prefer IKEv2, support IKEv1” e “IKEv1 only”. I lifetime predefiniti sono diversi fra le due fasi: la Phase I si rinegozia una volta al giorno, la Phase II ogni ora. È un dettaglio che vale una domanda: un tunnel che cade puntualmente dopo circa sessanta minuti punta alla Phase II, non alla Phase I.

La traccia dice dove si è rotto. In $FWDIR/log/iked0.ikev1trace e iked0.ikev2trace si vedono le proposte inviate e ricevute, una coppia di file per istanza del daemon; vpn debug mon cattura i pacchetti IKE in $FWDIR/log/ikemonitor.snoop, leggibile con Wireshark. Prima di leggere riga per riga, però, si mettono fianco a fianco le due proposte: cifratura, hash, gruppo Diffie-Hellman, lifetime, Perfect Forward Secrecy. Se la Phase I si completa e la Phase II no, la differenza è quasi sempre lì o nei Traffic Selector. Il risultato si verifica con vpn tu tlist, che per ogni peer mostra metodo di cifratura, Traffic Selector, stato e contatori.

Lab: esaminare i problemi di configurazione

Il secondo laboratorio cerca la causa nella configurazione, e i punti da ispezionare sono pochi e ricorrenti. Le proposte si scrivono in SmartConsole, in Object Explorer > VPN Communities, aprendo la comunità e usando la scheda Encryption: si sceglie una suite predefinita — VPN-A, VPN-B, Suite-B GCM — oppure Custom Encryption Suite, dove si fissano gli algoritmi di Phase I e Phase II, i gruppi Diffie-Hellman e il Perfect Forward Secrecy. Una suite predefinita scelta su un lato e una custom sull’altro sono il modo più rapido per produrre una Phase II che non chiude mai.

Il VPN domain definisce la rete protetta da ciascun gateway e si configura nella topologia dell’oggetto. Se non combacia con quello che il peer si aspetta, la negoziazione può riuscire mentre il traffico di una subnet resta fuori dal tunnel. Nelle comunità Star si aggiunge il VPN routing, dalla pagina VPN Routing o, per un controllo più fine, dal file vpn_route.conf.

Il Link Selection decide con quale indirizzo il gateway si presenta: interfaccia esterna, next hop, indirizzo dopo NAT statico, modalità di ridondanza Active o Backup. È il primo sospetto quando il peer riceve la negoziazione da un IP che non riconosce. Se in mezzo c’è un NAT serve il NAT traversal: Support NAT traversal è attivo di default quando un NAT viene rilevato, e devono passare IKE su UDP 500, NAT-T su UDP 4500, ESP come protocollo IP 50 e AH come 51.

Restano due impostazioni che cambiano il numero di tunnel e la loro visibilità. Il VPN Tunnel Sharing crea un tunnel per coppia di host, di subnet o di gateway, e fra impostazioni in conflitto prevale la più restrittiva: due lati configurati diversamente generano Traffic Selector che non combaciano. I Permanent Tunnels tengono i tunnel sempre attivi e li sorvegliano con il tunnel testing, protocollo proprietario Check Point su UDP 18234 che richiede gateway Check Point a entrambi i capi: con un peer di terze parti uno stato «down» non prova che il tunnel sia guasto.

Chiudere il lab con una rinegoziazione pulita

Corretta la configurazione, non si aspetta la scadenza del lifetime: si cancella la SA con vpn tu del e si guarda nascere la nuova negoziazione nel debug già acceso. Poi si rilegge vpn tu tlist e il log in Logs & Monitor, e si spengono i debug.

Trappole tipiche d’esame

Fermarsi alla fase 1 quando il problema è nella fase 2. Un IKE SA presente in vpn tu list ike fa credere che tutto sia riuscito, ma il traffico viaggia sotto l’IPsec SA: se vpn tu list ipsec è vuoto, il guasto sta nel Quick Mode e va cercato nelle proposte di Phase II, nel Perfect Forward Secrecy o nei Traffic Selector.

Non confrontare le proposte dei due peer prima di debuggare. Il confronto costa un minuto e chiude una parte consistente dei casi. Nelle domande a scenario, la risposta che accende subito un debug prima di aver guardato le due configurazioni è il distrattore preferito.

Confondere un problema di VPN domain con uno di negoziazione IKE. Se le SA si stabiliscono e solo una subnet non passa, IKE ha funzionato: il difetto è nel VPN domain, nel tunnel sharing o nella topologia, e nessun livello di debug su iked lo mostrerà.