Come leggere il primo scambio IKEv2 in una cattura di pacchetti

Le catture prese a metà sessione sono il motivo abituale per cui una traccia IKEv2 sembra rumore, perché le parti stanno già rinnovando le chiavi o scambiando carichi cifrati quando inizia la registrazione. Parti invece da un nuovo tentativo di connessione, così che il primo messaggio del file sia quello che apre la negoziazione. L'ordine di lettura che segue lo presuppone e segna il punto in cui un pacchetto smette di dimostrare qualcosa sull'estremità remota. Saltare quel passaggio è il modo in cui un tunnel funzionante finisce diagnosticato come una porta bloccata.

Verifica di stare guardando lo scambio di apertura

Una negoziazione IKEv2 inizia con IKE_SA_INIT, tipo di scambio 34, identificatore di messaggio 0. L'iniziatore sceglie uno SPI diverso da zero, e lo SPI del risponditore è zero in quella prima richiesta e diverso da zero nella risposta. Questi tre fatti separano un nuovo tentativo da un rinnovo di chiavi o da un messaggio IKE_AUTH che si trova per caso in cima a una cattura.

I campi dell'intestazione sono leggibili, e così i carichi di proposta, scambio di chiavi e nonce. Leggibile non significa autenticato: nessuna delle parti ha dimostrato la propria identità a questo punto, e il valore privato di Diffie-Hellman non compare mai sul filo.

Stampa i campi come tabella invece di scorrere un pannello di decodifica, perché ritrasmissioni e SPI che non coincidono diventano evidenti in colonna.

tshark -r ike.pcapng -Y "isakmp" -T fields -e frame.number -e ip.src -e udp.srcport -e isakmp.exchangetype -e isakmp.messageid -e isakmp.initiator_spi -e isakmp.responder_spi

Leggi l'output a coppie. Una richiesta con identificatore di messaggio 0 seguita da una risposta che porta lo stesso identificatore e uno SPI del risponditore diverso da zero è un solo scambio, anche quando compare tre volte perché la richiesta è stata ritrasmessa. Tre richieste identiche non sono tre accessi, e trattarle come tali è il modo in cui si conclude che un client sta in loop mentre è solo paziente. Ordina per identificatore di messaggio, poi per marca temporale, e l'intera conversazione si riduce a un breve elenco di tentativi.

Leggi un rifiuto prima di leggere un successo

Una risposta non è automaticamente un progresso. Il risponditore può replicare con una notifica cookie e attendersi che l'iniziatore riprovi, oppure con INVALID_KE_PAYLOAD che nomina un gruppo che accetterebbe al posto di quello. Entrambe arrivano come messaggi IKE ben formati, ed entrambe sembrano uno scambio concluso a un filtro che conta solo i pacchetti.

Apri il carico di notifica e leggi il tipo prima di ogni altra cosa. Una sfida cookie significa che il risponditore si difende da indirizzi di origine falsificati, e il client deve reinviare con il cookie allegato. Un gruppo non valido significa che le due proposte non concordano, e nessuna quantità di tentativi lo cambierà finché non si muove la configurazione di un lato.

Solo IKE_AUTH, il secondo scambio, trasporta l'identità cifrata e i carichi di autenticazione. Un IKE_SA_INIT completato ti dice quindi che le parti concordano su algoritmi e chiavi derivate, e assolutamente nulla sul fatto che le credenziali verranno accettate. Aspettati anche lì due messaggi, e aspettati che entrambi siano opachi senza le chiavi di sessione.

La porta 4500 non è un solo protocollo

La UDP 500 di solito trasporta lo scambio di apertura. Una volta eseguito il rilevamento NAT, IKE passa alla 4500 e antepone a ogni messaggio un marcatore nullo di quattro byte che non è ESP. L'ESP incapsulato sulla stessa porta inizia invece con uno SPI ESP diverso da zero, e un keepalive NAT di un solo byte è una terza forma che compare quando non succede altro.

Un filtro che corrisponde solo alla porta mescola tutte e tre, ed è per questo che «c'è traffico sulla 4500» risolve così poco. Separa la vista per protocollo prima di concludere qualcosa sull'estremità remota.

tshark -r ike.pcapng -Y "udp.port == 4500 && isakmp" -T fields -e frame.number -e isakmp.exchangetype
tshark -r ike.pcapng -Y "udp.port == 4500 && !isakmp" -T fields -e frame.number -e esp.spi

Il silenzio descrive il punto di osservazione

Le richieste senza risposta stabiliscono esattamente una cosa: in quel punto di cattura non è comparsa alcuna risposta. Il filtraggio, una rotta che manda la risposta altrove, un risponditore irraggiungibile o un risponditore a cui non piace la proposta producono tutti lo stesso risultato vuoto, e una sonda UDP generica non li separerà.

Un ICMP irraggiungibile è una prova di altro tipo. Leggi il pacchetto citato al suo interno e individua quale dispositivo lo ha emesso, perché il rifiuto amministrativo di un router non è un errore autenticato dall'estremità remota.

tshark -r ike.pcapng -Y "icmp.type == 3" -T fields -e frame.number -e ip.src -e icmp.code

Correla lo stesso tentativo con i log lato server dove ti è consentito leggerli. La richiesta è arrivata, il servizio ha risposto e dove si è fermata la risposta? Quelle tre risposte ti mandano a un problema di percorso o a un problema di politica, e costano meno di un quarto cambio di credenziali.