Ritrasmissioni TCP contro scarti di replay IPsec: leggete ogni livello

Tre strumenti diversi segnalano tre duplicati diversi, e solo uno di essi è un evento di rete su cui potete agire. Una ritrasmissione TCP è un mittente che invia di nuovo un intervallo, un ACK duplicato è un ricevente che ripete una conferma, e uno scarto di replay ESP è un’associazione di sicurezza che rifiuta un numero di sequenza che ha già accettato. Nessuno dei tre implica gli altri. Leggete ogni contatore al livello che lo produce prima di collegarli in una storia.

Tre contatori che non misurano mai lo stesso evento

L’annotazione di ritrasmissione TCP significa che il mittente ha di nuovo messo un intervallo di sequenza sul filo. La perdita è una delle ragioni, e la cattura che avete potrebbe semplicemente mancare del pacchetto originale o della conferma che spiegherebbe la tempistica. Un ACK duplicato è il ricevente che ripete una conferma cumulativa secondo le regole di recupero TCP, il che non è né una scrittura applicativa duplicata né una seconda copia dei dati.

ESP lavora nel proprio spazio di sequenza. Ogni associazione di sicurezza numera i pacchetti che invia, e il ricevente mantiene una finestra di numeri che ha già accettato, quindi un pacchetto ESP che arriva due volte viene scartato solo su quella base. Un segmento TCP ritrasmesso viaggia quindi in un pacchetto ESP nuovo con un numero di sequenza nuovo, che è il comportamento corretto a entrambi i livelli. Gli stessi byte possono sembrare nuovi in un contatore e vecchi in un altro, e nessuno dei due livelli mente.

Cosa può vedere l’analizzatore e cosa no

Cominciate dal vocabolario dell’analizzatore, perché i nomi dei filtri descrivono osservazioni e non l’interno degli endpoint. Contare con gli stessi nomi che usa lo strumento vi tiene onesti su ciò che è stato realmente misurato. Un conteggio da una cattura incompleta è un conteggio di ciò che è sopravvissuto, non di ciò che è accaduto sul filo.

tshark -r trace.pcap -Y "tcp.analysis.retransmission" | wc -l
tshark -r trace.pcap -Y "tcp.analysis.duplicate_ack" | wc -l

Leggete le informazioni esperte accanto a quei numeri, perché gli avvisi di checksum e ordinamento cambiano quanto peso meritano. Una traccia unita da due sensori può mostrare un frame due volte, e contare entrambe le copie inventa un evento di recupero che non è mai avvenuto.

I contatori ESP vivono nello stato del kernel

I numeri di sequenza ESP appartengono all’associazione di sicurezza, non al flusso TCP, quindi il gateway è il posto dove chiedere. L’elenco di stato riporta contatori di pacchetti ed errori per associazione che nessuna cattura può ricostruire.

ip -s xfrm state
tshark -r trace.pcap -Y "esp" -T fields -e esp.seq | head

RFC 4303 definisce il numero di sequenza e la finestra anti-replay che lo consuma, ed è per questo che il contatore sale anche quando nulla è sbagliato. Numeri di sequenza esterni monotoni senza un’anomalia TCP corrispondente indicano un altro mittente o un percorso duplicato più che una tempesta di ritrasmissioni. Una cattura esterna di un tunnel cifrato di solito nasconde i numeri di sequenza TCP interni, quindi non può dimostrare cosa ha fatto lo stack interno. Catturate dentro il tunnel solo dove la policy lo consente, e non disattivate mai l’anti-replay per zittire un avviso non correlato.

Dove il punto di osservazione cambia la risposta

Prima di escalare, annotate come è stata presa la cattura: l’interfaccia, se il processo di cattura ha segnalato perdite e se i timestamp sono confrontabili tra sensori. Un solo punto di osservazione non può vedere entrambe le estremità di un percorso, quindi ogni affermazione sul comportamento del ricevente è un’inferenza e non una misura. Una traccia presa sul gateway e una traccia presa sull’host non saranno d’accordo sull’ordinamento sotto carico, e quel disaccordo di solito appartiene alla cattura e non al tunnel. Correlare due viste è ciò che trasforma un conteggio in prova.

Usate un flusso applicativo consentito e annotate i contatori degli endpoint accanto ai conteggi della cattura nello stesso momento. Se i numeri non concordano, fidatevi del livello che possiede l’evento e trattate l’altro come artefatto di osservazione finché non si dimostri il contrario. Quella regola risolve la maggior parte di questi casi senza toccare la configurazione del tunnel.

Leggere i numeri nell’ordine corretto

Cominciate dal livello in cui è stata posta la domanda: un avviso TCP si risponde da una cattura TCP, e uno scarto ESP si risponde dai contatori dell’associazione di sicurezza sul gateway. Solo allora chiedete se le due viste descrivono lo stesso pacchetto. Una conclusione che richiede entrambi i livelli dovrebbe nominarli entrambi, perché un’affermazione sul tunnel basata solo su un’annotazione TCP è una congettura.

Annotate il livello, il contatore e il punto di osservazione per ogni riscontro, e il lettore successivo non fonderà tre eventi in un guasto immaginario. Escalate con quei tre campi e la correzione di solito segue dal primo.