OpenVPN su PPPoE: abbassare link-mtu, tun-mtu o mssfix?

I ping rispondono, il DNS risolve e ogni pagina che richiede un segmento a dimensione piena si blocca. Su un uplink che aggiunge il proprio incapsulamento, il percorso perde silenziosamente qualche decina di byte di budget, e un profilo scritto per Ethernet pulito continua a chiedere pacchetti che la linea non può trasportare. La connessione non è lenta; sta scartando esattamente i pacchetti che contano.

Tre opzioni possono risolvere il problema, e agiscono a livelli diversi. Scegliere quella sbagliata o non fa nulla o rende il tunnel fragile in un modo nuovo, quindi la scelta parte da ciò che il percorso supporta davvero.

Tre manopole, tre livelli diversi

link-mtu è il budget esterno: il carico cifrato più l’intestazione OpenVPN, l’intestazione UDP e l’intestazione IP esterna. Descrive ciò che esce dalla macchina, ed è per questo che è il numero che il percorso fisico vincola.

tun-mtu è il budget interno: l’interfaccia che vede il vostro traffico. È più grande di ciò che il percorso può trasportare esattamente dell’overhead del tunnel, e OpenVPN di solito lo deriva invece di obbligarvi a impostarlo.

mssfix è un meccanismo del tutto diverso. Riscrive la dimensione massima del segmento annunciata durante le strette di mano TCP, così i peer TCP scelgono segmenti che stanno dopo l’incapsulamento. Non cambia la MTU dell’interfaccia e non ha alcun effetto su UDP.

Se impostate link-mtu esplicitamente, OpenVPN sottrae il proprio overhead per derivare la MTU interna. Quell’overhead non è una costante fissa; dipende dal cifrario e dall’autenticazione, ed è per questo che un valore copiato da un forum può essere errato su un altro profilo. Impostare sia link-mtu sia tun-mtu consegna al client due istruzioni contraddittorie.

Misurate il percorso prima di scegliere qualsiasi numero

Misurate dall’interfaccia fisica, non dall’interno del tunnel, e ricordate che ping riporta il carico utile, non la dimensione del pacchetto. Aggiungete 28 byte per le intestazioni IPv4 e ICMP prima di confrontare il carico con un frame da 1500 byte, e tenete presente quella correzione quando un peer riporta un numero diverso.

Su un client Linux, ping -M do -s 1472 vieta la frammentazione e fallisce se il pacchetto è troppo grande. Riducete il carico utile finché non passa, poi aggiungete 28 per ottenere la MTU del percorso. PPPoE costa 8 byte, quindi 1492 è normale su DSL. DS-Lite e alcuni percorsi mobili costano 40 o più, e la risposta è di solito inferiore a quanto suggerisce la velocità nominale del collegamento.

Se ogni dimensione di ping riesce ma i trasferimenti grandi si bloccano ancora, sospettate un buco nero invece di un semplice limite di dimensione. Un messaggio ICMP di frammentazione necessaria viene filtrato da qualche parte lungo il percorso, quindi il mittente non impara mai a ridurre, e solo i flussi che richiedono un segmento grande se ne accorgono.

Limitate prima TCP, restringete poi il tunnel

Le strette di mano TCP sono l’unica cosa che mssfix tocca, il che di solito lo rende il controllo meno invasivo da provare per primo. Impostatelo poco sotto il budget reale del percorso, spingete lo stesso valore dal server perché entrambe le estremità siano d’accordo, e riprovate un download grande. Se il blocco sparisce, il problema era la dimensione del segmento TCP, e nient’altro deve cambiare.

Abbassate la MTU interna quando il traffico interessato non è TCP. Un servizio UDP, un tunnel dentro il tunnel o un’applicazione che invia datagrammi a dimensione piena continuerà a fallire dopo un limite MSS perché nulla riscrive la dimensione dei suoi pacchetti. Riducete tun-mtu per quel caso, oppure impostate link-mtu e lasciate che il client derivi il valore interno, ma mai entrambi.

Non ricorrete alla vecchia opzione di frammentazione. Divideva i pacchetti dentro il tunnel, aggiungeva overhead ed è stata deprecata per buone ragioni; l’OpenVPN moderno si aspetta una descrizione accurata del percorso.

Perché le sonde piccole continuano a funzionare

Le query DNS, gli echi ICMP e le strette di mano TCP sono tutti molto al di sotto della dimensione che fallisce. Il tunnel sembra quindi sano in ogni test rapido mentre le strette di mano TLS e le risposte HTTP falliscono silenziosamente. Proprio quella combinazione, un traceroute funzionante e un browser che si blocca alla prima risposta grande, è la firma da cercare. Ricorrete a una sonda a dimensione piena prima di ricorrere a un nuovo profilo.

Verificate con il traffico che ha fallito. Caricate una pagina grande, inviate un datagramma UDP a dimensione piena se quello è il servizio interessato, e ripetete da un secondo client su un altro uplink. Annotate la MTU di percorso misurata e il valore scelto, perché la persona successiva che toccherà il profilo considererà altrimenti il numero arbitrario.

Non portate mai la MTU interna sotto 1280 quando IPv6 passa sul tunnel, perché è il minimo che ogni collegamento IPv6 deve trasportare. Una MTU più piccola è un fatto sul percorso, non un’impostazione di prestazioni da regolare a sentimento.