Trasportare un pacchetto interno fisso da 1,500 byte attraverso una VPN

Hai un requisito che non si piega: il lato remoto deve ricevere lo stesso pacchetto IP da 1,500 byte che il mittente emette, intestazioni incluse. Un tunnel non può incapsulare quel pacchetto più il proprio framing dentro un secondo pacchetto IP da 1,500 byte, quindi qualcosa nel progetto deve cedere. L’ordine qui sotto è quello che uso in una finestra di modifica: scrivere il budget in byte, dimostrare ciò che l’underlay può realmente trasportare, poi scegliere esattamente un meccanismo di trasporto e confermare il pacchetto interno sul lato remoto.

Scrivi il budget in byte prima di modificare un profilo

L’incapsulamento aggiunge byte a diversi livelli, e il totale è una proprietà del tuo profilo, non una costante che puoi cercare. La famiglia di indirizzi, la scelta del cifrario, il protocollo di trasporto e qualsiasi opzione di compressione o framing spostano il numero, ed è per questo che una sottrazione copiata da un’altra installazione è inutile come budget. Parti dal requisito interno, aggiungi l’overhead misurato per pacchetto della tua configurazione e scrivi la dimensione esterna risultante sul ticket di modifica prima che qualcuno tocchi un file.

Due numeri decidono il progetto: il pacchetto esterno più grande che il percorso trasporta senza frammentazione e i byte extra necessari al tuo incapsulamento. Quando il primo è inferiore al secondo più 1,500, uno dei due deve cambiare. La scelta diventa allora ristretta anziché creativa, ed è per questo che scrivo entrambi i numeri prima di discutere le opzioni. Nulla a livello di tunnel comprime via quei byte, e nessun singolo valore intero di MTU elimina il requisito che ti è stato dato.

Sonda l’underlay con ping con bit do-not-fragment

Misura il percorso invece di fidarti dell’MTU dell’interfaccia, perché l’anello più piccolo nel percorso esterno è quello che conta. Su Linux, -M do imposta il bit do-not-fragment e -s prende il payload ICMP, quindi un frame da 1,500 byte risponde con 1,472 byte di payload una volta sottratti l’intestazione IP da 20 byte e l’intestazione ICMP da 8 byte. Aumenta il payload finché la sonda non fallisce, poi salta a una dimensione jumbo per vedere se il percorso lo trasporta del tutto.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

Un percorso che supera 1,472 e fallisce 8,972 non può trasportare un pacchetto interno da 1,500 byte più l’overhead in un singolo pacchetto esterno. Questa è la risposta che ti serviva prima di aprire la configurazione della VPN. Decide anche quale delle due sezioni successive si applica a te, quindi tieni i due risultati delle sonde accanto al ticket. Indovinare qui costa una finestra di manutenzione, perché un tunnel che si dichiara attivo non ti dice nulla sul pacchetto più grande che il percorso accetterà.

Alza l’MTU del percorso solo dove ogni hop è d’accordo

I frame jumbo sono una proprietà end-to-end, non un’impostazione che abiliti sui due endpoint che ti capita di controllare. Ogni switch, router e passaggio di provider sul percorso esterno deve concordare sulla dimensione maggiore, e un singolo hop da 1,500 byte scarterà silenziosamente il pacchetto che hai appena ingrandito. Alzare solo l’interfaccia locale è la classica modifica a metà che fa sembrare rotto il tunnel mentre l’underlay scarta in silenzio.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Cambia l’interfaccia, poi ri-sonda lo stesso percorso prima di cambiare qualsiasi altra cosa. Se la sonda fallisce ancora, torna indietro con ip link set dev eth1 mtu 1500 e passa alla frammentazione invece di discutere con un provider di un collegamento che non possiedi.

Usa la frammentazione del tunnel quando l’underlay non può crescere

Un meccanismo di frammentazione supportato sotto il pacchetto interno permette a più pacchetti esterni di trasportare un solo pacchetto interno, e l’endpoint remoto del tunnel li riassembla prima di consegnare l’originale allo stack. L’opzione di frammentazione UDP di OpenVPN Community è una implementazione di questa idea, e non è la stessa cosa della normale frammentazione IP del pacchetto esterno. Entrambi i peer devono eseguire una versione che supporta il formato, e il percorso dati deve essere quello che pensi: i client OpenVPN 3 e i canali dati accelerati dal kernel hanno limiti diversi, quindi un profilo che funziona su un client può fallire su un altro.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

La normale frammentazione esterna è l’altra opzione, ed è quella più debole. I router IPv6 non frammentano affatto un pacchetto inoltrato, quindi un pacchetto esterno sovradimensionato muore semplicemente e il mittente lo scopre solo se il relativo messaggio ICMPv6 sopravvive al percorso. I frammenti invitano anche al filtraggio e all’amplificazione delle perdite, ed è per questo che la considero un ripiego e non un piano.

Un vettore esterno basato su stream aggira la questione della dimensione segmentando il proprio flusso di byte, e il pacchetto interno ricostruito può comunque essere di 1,500 byte. Si tratta di una decisione di trasporto con un costo proprio, incluso il noto comportamento del TCP dentro il TCP, quindi prendila deliberatamente e non come effetto collaterale di una discussione sull’MTU.

Conferma che il pacchetto interno arrivi invariato

La verifica non è un handshake riuscito. Cattura sull’interfaccia del tunnel a entrambe le estremità e confronta dimensione e contenuto del pacchetto che l’applicazione ha realmente inviato con quello che il lato remoto ha ricevuto.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

Se la cattura mostra il pacchetto interno a dimensione piena all’estremità remota, la scelta di trasporto funziona e il compito restante è annotarla. Se non mostra nulla mentre il tunnel si dichiara attivo, il pacchetto esterno viene scartato da qualche parte tra gli endpoint, il che ti riporta alla sonda e non alle impostazioni del cifrario.

Annota tre cose nel ticket di modifica prima di chiuderlo: il budget esterno misurato, il meccanismo scelto e il comando che ha dimostrato che il pacchetto interno è sopravvissuto. La prossima persona che toccherà questo tunnel avrà bisogno di tutte e tre, e nessuna di esse può essere ricostruita dal solo file di configurazione.