I frame jumbo non fanno trasportare pacchetti da 9000 byte a un percorso VPN

Hai abilitato frame da 9000 byte sulla LAN e ti aspettavi che la VPN diventasse più veloce. È diventata più lenta, o ha smesso del tutto di far passare i trasferimenti grandi. I frame jumbo sono un accordo di collegamento locale; non allargano il percorso che il tunnel attraversa.

Il budget utilizzabile è fissato dal limite più piccolo del percorso, inclusa l'incapsulamento che il tunnel aggiunge.

Cosa cambiano davvero i frame jumbo

Una MTU è una proprietà di una singola interfaccia. Alzarla su un server e sul suo switch significa che quei due possono scambiarsi frame più grandi senza frammentazione. Non dice nulla del router oltre lo switch, del provider o dell'altro capo di un tunnel. Quei dispositivi hanno i propri limiti, e un pacchetto che ne supera uno viene scartato o frammentato secondo regole che non hai impostato tu.

Accordo locale, conseguenze globali. È tutta qui la confusione.

La tassa dell'incapsulamento

Un tunnel avvolge il tuo pacchetto dentro un altro. WireGuard su IPv4 UDP aggiunge circa 60 byte di overhead; la modalità UDP di OpenVPN è nello stesso intervallo, e IPsec varia con modalità e algoritmi. Quei byte escono dal budget del percorso esterno, non dal nulla.

Quindi un collegamento esterno da 1500 byte non può trasportare un pacchetto interno da 1500 byte una volta aggiunta l'intestazione del tunnel.

Vale la pena fare il calcolo una volta. Su un percorso da 1500 byte, un'interfaccia WireGuard vuole una MTU intorno a 1420 perché il pacchetto incapsulato ci stia. Imposta l'interfaccia interna a 9000 e ogni pacchetto grande avrà bisogno di una frammentazione che il tunnel non può fare, oppure verrà scartato.

Trova il collegamento più piccolo del percorso

Percorri la rotta e trova la MTU più bassa. La LAN di solito è 1500 o 9000, la WAN di solito 1500, e un collegamento mobile o PPP può essere ancora più basso. Poi sottrai l'overhead del tunnel. Se il risultato è più piccolo della MTU dell'interfaccia interna, hai la risposta. La scoperta della MTU di percorso può trovarlo automaticamente, ma solo quando i messaggi ICMP da cui dipende sono lasciati passare.

L'ICMP filtrato è la ragione classica per cui un trasferimento grande si blocca mentre le richieste piccole funzionano bene.

Verifica la dipendenza dalla dimensione senza allargare la modifica

Usa un trasferimento rappresentativo e conserva i valori originali per poterli rimettere. ping -M do -s 1472 verifica un pacchetto da 1500 byte con il bit DF impostato; riduci la dimensione finché non passa. Se falliscono solo i pacchetti grandi, hai un problema di dimensione e non di instradamento.

Attenzione all'offload lato host quando leggi le catture. L'offload di segmentazione può mostrare frame molto più grandi di ciò che è realmente passato sul cavo, facendo sembrare rotto un percorso che funziona e a posto uno rotto.

Quando una MTU grande è il progetto giusto

Una rete privata controllata può legittimamente far girare frame più grandi da un capo all'altro, a condizione che ogni dispositivo del percorso sia d'accordo e che l'overhead del tunnel sia conteggiato. Quello è un progetto coordinato con un valore documentato per collegamento, non un numero grande digitato in un client.

Per un'uscita pubblica comune, supponi 1500 o meno e lascia che il tunnel scelga una MTU interna sicura. RFC 8201 copre la scoperta della MTU di percorso per il caso IPv6 ed è un riferimento utile su come dovrebbe funzionare il feedback.