Scoperta dell'MTU del percorso attraverso una VPN: dimensionamento e il vuoto ICMP

Un tunnel completa l'handshake, le richieste piccole tornano, e il primo trasferimento grande si blocca. Questo schema indica l'MTU del percorso molto prima di indicare la velocità effettiva. Ogni collegamento lungo la rotta limita la dimensione del pacchetto, e l'incapsulamento spende parte di quel margine in intestazioni esterne, quindi il pacchetto interno deve essere più piccolo di quanto suggerirebbe il percorso grezzo. Il guasto è silenzioso, ed è questo che lo rende costoso da diagnosticare.

Che cosa misura davvero l'MTU del percorso

L'MTU del percorso è il più piccolo MTU di collegamento sulla rotta tra due host, non l'MTU stampato sull'interfaccia locale. Il valore locale è il punto da cui parte la stima, e il percorso decide dove deve finire. Ecco perché un tunnel identico può funzionare su una rete di accesso e bloccarsi su un'altra: è cambiata la rotta, non la configurazione. Misurare una volta e assumere ovunque è l'errore che tiene in vita questo problema.

Per un tunnel, il numero che conta è l'MTU interno, cioè il margine del percorso esterno meno ciò che consuma l'incapsulamento. WireGuard aggiunge un'intestazione IP esterna e un'intestazione UDP; altri trasporti aggiungono le proprie. Imposta una dimensione interna troppo alta e ogni pacchetto a dimensione piena necessita di una frammentazione che potrebbe non avvenire mai.

Perché un tunnel riduce il pacchetto utilizzabile

Se l'interfaccia del tunnel mantiene l'MTU del collegamento fisico, ogni pacchetto grande dipende da qualcuno più a valle disposto a frammentarlo. IPv4 lo consente in linea di principio, ma un router a cui è stato detto di non frammentare restituisce invece un errore. I router IPv6 non frammentano mai in transito, quindi la stessa impostazione si comporta diversamente a seconda della famiglia di indirizzi. In ogni caso il mittente non impara nulla finché qualcosa non riporta indietro.

La conseguenza pratica è una dimensione che sta nell'handshake e non nel carico utile. Un TLS ClientHello o una query DNS sono abbastanza piccoli da attraversare intatti un percorso ridotto, mentre un trasferimento massivo no. I sintomi quindi si concentrano attorno a operazioni specifiche invece che a host specifici.

La scoperta funziona solo quando arriva il riscontro

La scoperta IPv4 si basa sul bit don't-fragment: un router che non può inoltrare il pacchetto restituisce ICMP fragmentation-needed con l'MTU del salto successivo, e il mittente abbassa la sua stima. IPv6 usa invece messaggi Packet Too Big, perché i router non frammentano in transito. Entrambi i meccanismi presumono che il messaggio trovi la via del ritorno al mittente, attraverso il tunnel e oltre qualsiasi firewall sul percorso di ritorno. Quando questa presunzione fallisce, il mittente continua a ritentare una dimensione che il percorso non può trasportare.

Un firewall che consente echo request ed echo reply non ha necessariamente consentito quei tipi di errore. ICMP è una famiglia, e i membri che contano qui sono gli errori, non la coppia di echo. Controlla la politica del traffico di controllo su entrambe le estremità del tunnel e sul percorso tra di esse, e segui le indicazioni supportate dalla piattaforma invece di consentire ogni tipo ICMP ovunque.

Lo stesso filtraggio può trovarsi dentro il tunnel. Se il percorso interno scarta l'errore ma quello esterno lo trasporta, il mittente può adattarsi a un limite che il traffico incapsulato in realtà non vede mai.

Prova il percorso invece di indovinare un numero

Tieni fissi destinazione, rete di accesso e tunnel, poi varia solo la dimensione del pacchetto. Una prova don't-fragment che fallisce con un suggerimento di MTU ti dà il limite del salto successivo; ripeti finché una dimensione passa, e registra sia la dimensione sia la famiglia di indirizzi.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

Un ping che passa non dimostra che passino i segmenti a dimensione piena di un'applicazione reale, quindi ripeti il test con il trasferimento che è fallito davvero. Confronta la prova più grande che ha funzionato con l'MTU del tunnel che hai configurato, e tieni separati i due numeri nelle tue note. Se differiscono di circa un'intestazione, hai trovato il sovraccarico dell'incapsulamento, non un guasto.

PLPMTUD, descritto nella RFC 4821, sonda verso l'alto e usa i riscontri del trasporto invece di fidarsi degli errori consegnati. Aiuta sui percorsi che filtrano ICMP, ma il supporto varia per stack e per applicazione. Un flusso TCP può riprendersi da solo mentre un'applicazione UDP con dimensione del datagramma fissa continua a fallire.

Scegli un valore e registra il ragionamento

Abbassare l'MTU del tunnel è sia una diagnostica sia una correzione legittima una volta che conosci il percorso. Non sostituisce il sapere quale percorso e quale meccanismo di riscontro fossero coinvolti, perché un valore tarato su un collegamento mobile sarà inutilmente piccolo su una connessione in fibra. Registra la dimensione scelta, la prova che l'ha giustificata e il passo di rollback.

Il meccanismo IPv4 è descritto nella RFC 1191 e la guida alla pacchettizzazione IPv6 nella RFC 8201; nominarli entrambi evita che il prossimo ingegnere debba riderivare la presunzione. Se il trasferimento si blocca ancora alla dimensione che hai scelto, smetti di abbassare il numero e guarda il livello successivo. Un percorso che fallisce a ogni dimensione non è un problema di MTU.