I pacchetti grandi svaniscono su IPsec mentre i ping piccoli continuano a funzionare

Le shell remote restano reattive, le sonde piccole rispondono, poi una copia di file striscia e si blocca senza alcun errore che qualcuno possa indicare. Un ping con un carico maggiore lo riproduce subito, e lo stesso trasferimento funziona dalla rete locale. Nulla della cifratura è lento; certi pacchetti non arrivano mai. Due divisioni diverse possono produrre quella firma, e lasciano prove diverse.

Due punti in cui un pacchetto può essere diviso

Prima della cifratura, il router può dividere un pacchetto interno troppo grande e proteggere ogni pezzo separatamente. Dopo la cifratura, ciò che viene diviso è il pacchetto esterno finito, e l'estremità remota deve riassemblarlo prima di poter decifrare qualcosa. Stesso sintomo, lavoro diverso per il ricevente e manopole diverse per voi.

La distinzione conta perché una correzione rivolta al lato sbagliato cambia un numero senza spostare il guasto. Un pacchetto rifiutato sull'interfaccia non diventa mai un pacchetto esterno, quindi nessuna impostazione del lato esterno può salvarlo.

Dove viene davvero presa la decisione di dimensione

Un'interfaccia di tunnel porta un IP MTU, e quel valore può rifiutare un pacchetto interno troppo grande molto prima che lo veda lo stadio IPsec. Impostare un bit sull'intestazione esterna non riesamina quella decisione precedente, perché il pacchetto era già stato rifiutato. Per questo alzare l'MTU interna a volte peggiora le cose invece di migliorarle. Leggete il valore dell'interfaccia e il comportamento esterno prima di cambiare l'uno o l'altro, perché la modifica più economica è di solito quella che spiega il sintomo.

Controllate prima il valore dell'interfaccia, poi il comportamento esterno. Due numeri, due stadi, e di solito solo uno dei due è responsabile.

Il budget esterno non è il budget interno

Ogni incapsulamento spende byte in intestazioni, e la quantità dipende dal trasporto, dalla famiglia di indirizzi e dalla presenza o meno del NAT traversal. Un pacchetto interno che entra nel collegamento locale può comunque produrre un pacchetto esterno che non entra nel percorso oltre. Misurate l'overhead invece di presumerlo, perché ogni intestazione opzionale si aggiunge al conto. Un tunnel con NAT traversal paga più di uno nudo, e la differenza basta a rompere un trasferimento che ieri funzionava.

Quando il pacchetto esterno porta il bit di non frammentazione, un salto che non riesce a inoltrarlo lo scarta e dovrebbe restituire un messaggio ICMP. Se quel messaggio viene filtrato da qualche parte, il mittente continua a riprovare e l'utente vede uno stallo senza spiegazione. Quello scarto silenzioso è la ragione abituale per cui un problema di dimensione viene segnalato come problema di velocità.

IPv6 elimina una delle opzioni

I router IPv6 non frammentano in transito, quindi il pacchetto esterno o entra o sparisce con un messaggio Packet Too Big. Quel messaggio diventa l'unico canale di riscontro, e bloccarlo rompe la scoperta del percorso per ogni trasferimento grande che segue. I router IPv4 possono frammentare un pacchetto grande quando il bit è chiaro, il che nasconde il guasto finché qualcos'altro non imposta quel bit.

Su uno stack misto, lo stesso tunnel può comportarsi diversamente per le due famiglie, perciò un test su IPv4 non risolve un reclamo su IPv6. Una verifica che esercita una sola famiglia lascia metà della risposta non misurata.

La politica dei segmenti TCP non è una risposta generale

Limitare la dimensione massima del segmento aiuta i flussi TCP, ed è un controllo legittimo quando il problema si limita a quelli. Non ha alcun effetto su UDP, che trasporta DNS, alcuni protocolli vocali e una parte crescente del traffico web.

Applicatela, poi provate il carico di lavoro che ha fallito. Se il caso UDP fallisce ancora, la politica dei segmenti non è mai stata la risposta e il budget dell'interfaccia ha ancora bisogno di attenzione. Identificate prima il protocollo del carico che fallisce, poi scegliete il controllo che gli appartiene.

L'ordine di lavoro

Annotate il carico più grande che sopravvive, poi l'MTU dell'interfaccia, poi se il pacchetto esterno porta il bit di non frammentazione e infine se il riscontro ICMP raggiunge il mittente. Quella sequenza restringe il guasto senza indovinare. Conservate ogni osservazione con un'ora e un'estremità, perché tutti e quattro i numeri si spostano quando cambia il percorso.

Cambiate un valore, riprovate il trasferimento originale e conservate il risultato. Un tunnel che supera una sonda grande ma si blocca ancora sull'applicazione è passato a un altro problema, e questo è un progresso che vale la pena annotare. La prossima persona preferirà i numeri alla conclusione.