Pacchetti IKE duplicati: trovate la transizione mancante

Il registro mostra due volte la stessa richiesta IKE, qualcuno indica il collegamento mobile e il ticket si chiude con una supposizione. Quella supposizione è il mito: un pacchetto ripetuto è un'osservazione su un singolo scambio, non una diagnosi di un collegamento. La ritrasmissione è un comportamento normale con le sue regole, e compare su percorsi sani ogni volta che una risposta è lenta. Seguite la risposta prima di accusare un'interfaccia.

Il mito: una richiesta ripetuta dimostra una perdita su un collegamento

Due cose diverse producono un duplicato e nessuna delle due indica un colpevole. Il richiedente può ripetere una richiesta perché non ha ricevuto risposta, oppure il punto di cattura può mostrare lo stesso pacchetto due volte per il punto in cui è agganciato allo stack. Una sonda che vede ingresso e uscita sullo stesso host registrerà volentieri un pacchetto come due, e l'operatore che legge quel registro non ha modo di distinguerli senza gli identificatori dello scambio. Trattate il duplicato come un evento del timer finché non potete dire quale dei due avete in mano.

Due collegamenti mobili peggiorano la confusione invece di ridurla. Una sola riga di registro indica un'interfaccia, mentre la risposta può essere uscita dall'altra, quindi l'interfaccia nel messaggio descrive dove è stato visto un pacchetto e non la forma della conversazione. È anche per questo che la prima domanda è quale scambio state guardando, non quale collegamento è guasto.

Che cosa vi dice davvero la ritrasmissione

In IKEv2, la ritrasmissione funziona così: il richiedente ripete una richiesta quando non è arrivata alcuna risposta, e il risponditore può reinviare la risposta memorizzata invece di calcolarne una nuova. Gli identificatori di messaggio appartengono a quello scambio, ed è ciò che rende una richiesta ripetuta con lo stesso identificatore riconoscibile come il protocollo che lavora e non come un nuovo tentativo. Un tentativo iniziale spesso richiede più di un indirizzo sorgente o di uno SPI dell'iniziatore per essere correlato, quindi il registro di scambio della piattaforma batte un elenco di pacchetti. IKEv1 segue regole diverse con identificatori diversi, e un avviso del fornitore su un primo pacchetto duplicato non significa la stessa cosa tra versioni.

Quindi un timestamp di ritrasmissione vi dice che un timer è scaduto. Non vi dice quale salto era lento, e certamente non vi dice che l'operatore è in colpa. Sono affermazioni separate, e solo la seconda è utile in un ticket.

La conseguenza pratica è registrare lo scambio prima di trarre una conclusione. Annotate l'indirizzo locale di ricezione, il percorso di risposta scelto dalla politica, la tupla del peer e gli identificatori dello scambio in un solo posto, perché ognuno risponde a una domanda diversa quando il registro viene riletto più tardi.

Quattro punti di osservazione come un'unica catena

Pensate allo scambio come a quattro anelli di una catena e non come a quattro luoghi separati da guardare. Un anello contiene prove oppure resta sconosciuto, e la catena è informativa solo quanto il suo anello registrato più debole. La tabella sotto è l'inventario: che cosa può stabilire ogni posizione e che cosa lascia intatto.

Riempite la catena solo dove avete accesso, e segnate il resto come sconosciuto invece di dedurlo. Un hook che registra pacchetti su una macchina non dice nulla su ciò che ha ricevuto la macchina remota, e una riga di registro che annota che una richiesta è stata vista non è prova che una risposta sia mai partita. Le lacune oneste sono più utili di un registro che sembra completo ed è costruito su supposizioni.

Trovate la prima transizione mancante

Percorrete la catena dall'iniziatore verso l'esterno e fermatevi al primo anello senza prove. Se il gateway non registra mai la richiesta, il guasto si trova sul percorso precedente. Quando il gateway registra ripetutamente la stessa richiesta mentre il client non registra mai una risposta, la direzione di ritorno è sospetta: indirizzo sorgente, traduzione e filtraggio a ogni confine che controllate. Se la risposta arriva e il client non progredisce comunque, la domanda ha lasciato il trasporto ed è diventata politica o stato.

Mantenete fissi il peer e il protocollo mentre confrontate, e ricordate che ritardo, perdita, politica e stato producono ciascuno una linea temporale diversa. Una rete mobile non è automaticamente la causa, e una linea fissa non è automaticamente abbastanza affidabile per ogni requisito. Catturate entrambe le direzioni mentre lo scambio è attivo:

tcpdump -ni any -vv 'udp port 500 or udp port 4500'

Quando l'accesso si ferma prima dell'estremità remota, il registro aiuta ancora se dice dove si ferma. Una cattura solo sull'iniziatore può mostrare una richiesta che esce e nessuna risposta che arriva, il che restringe il guasto a tutto ciò che segue quell'hook senza pretendere di sapere quale salto l'ha lasciata cadere. Segnate gli anelli remoti come sconosciuti e lasciate che la persona successiva con accesso li riempia. Scritto così, il registro resta onesto e comunque breve.

Confrontate prima di cambiare qualcosa. Ripetere la stessa richiesta verso lo stesso peer con lo stesso protocollo mantiene le variabili contabili, mentre un riavvio, un rinnovo di chiave o una modifica di politica tra due catture distrugge il confronto. Se un cambiamento è inevitabile, catturate di nuovo subito dopo, così che il prima e il dopo descrivano ancora lo stesso scambio.

Che cosa dice un rapporto utile

Un rapporto che merita un'azione accoppia una richiesta con la sua risposta e nomina il primo passo dietro il quale non c'è alcuna prova. Quella frase sopravvive alla lettura una settimana dopo da parte di un ingegnere che non era presente, e dà alla persona successiva un punto di partenza invece di un sospetto.

Non indebolite mai i controlli di identità e non ampliate l'insieme di protocolli consentito solo per verificare una teoria di ritrasmissione. Salvate i pacchetti e i registri degli eventi originali prima di qualsiasi riavvio, perché un riavvio distrugge esattamente il materiale che stavate per raccogliere e cancella la tempistica che mostrava dove lo scambio si era bloccato.

Il mito è che un duplicato dimostri che l'operatore è in colpa. La realtà è che un duplicato dimostra che un timer è scaduto, e la risposta vive sul percorso di risposta.