IPIP dentro WireGuard: i 20 byte extra che nessuno aveva messo a budget

Ping piccoli attraversano il tunnel tutto il giorno, arriva il banner SSH e poi la sessione si blocca nel momento in cui inizia un trasferimento di file. Questo schema indica un budget di byte contato al livello sbagliato, dove il tunnel esterno è stato dimensionato per il proprio overhead e nessuno ha sottratto quello interno. Un pacchetto IPIP annidato è solo un altro pacchetto IP per WireGuard, ed è proprio per questo che consuma byte che non avete mai riservato. La correzione è aritmetica, e sta in tre comandi e una tabella.

Il sintomo che lo tradisce

I problemi di frammentazione si annunciano con la dimensione, mai con gli indirizzi. Il vostro peer risponde a un ping da 56 byte per un'ora e poi tace a 1400 byte mentre il tunnel resta attivo e nessuna rotta è cambiata. L'handshake entra, la prima finestra TCP completa no, e il trasferimento si blocca pochi secondi dopo essere sembrato sano.

Misurate il tetto prima di modificare qualsiasi cosa, perché un tetto non misurato è quello che inseguirete due volte. Inviate una sonda sotto la dimensione sospetta con il bit do-not-fragment impostato, ping -M do -s 1000 10.9.0.2, poi ripetetela a una dimensione che sapete già essere troppo grande. Quando l'inversione segue la dimensione del payload mentre la destinazione resta invariata, il routing fa il suo lavoro e manca un'intestazione al budget.

Contate ogni intestazione una volta, al livello giusto

Partite dall'MTU più piccolo del percorso e non dall'interfaccia del tunnel, perché il muro sta a monte di entrambe le estremità. WireGuard spende 60 byte su un trasporto esterno IPv4: 20 per IP, 8 per UDP e 32 per la propria intestazione, e 80 byte quando quel trasporto è IPv6. Un wg0 da 1420 byte tiene 20 byte di margine sotto i 1440 che un percorso da 1500 byte può davvero consegnare, ed è per questo che la cifra copiata da una wiki ancora si adatta qui. Disegnate l'intero stack sul diagramma, perché chi cambierà l'MTU dopo sceglierà altrimenti un nuovo numero tondo ed erediterà il vostro bug.

La quinta riga è dove i budget vanno storti, perché i 1400 byte che un'interfaccia annidata porta includono già i 40 byte di intestazioni del pacchetto originale. Solo 1360 di quei byte raggiungono il processo che legge il file. Trattate 1400 come payload dell'applicazione, come vi invita a fare qualsiasi diagramma privo di quella colonna, e il dispositivo interno finisce 40 byte troppo generoso contro un muro che non si è mosso.

Impostate i due MTU separatamente

Il carrier e il dispositivo annidato sono oggetti separati, quindi ciascuno ha bisogno del proprio valore. Applicateli in questo ordine, perché il dispositivo annidato non eredita nulla dal carrier:

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

La regola che vale la pena memorizzare: MTU interno = MTU esterno - 20 quando il pacchetto che il tunnel IPIP trasporta è IPv4, e - 40 appena un lato del pacchetto interno è IPv6, perché l'intestazione annidata cresce da 20 byte a 40. Nient'altro appartiene a quella sottrazione. L'overhead di WireGuard è già stato speso quando avete scelto 1420, e addebitarlo due volte produce un tunnel che funziona perfettamente e resta lento finché nessuno lo misura. Un'installazione in cui entrambi i dispositivi portano un 1400 tondo è l'impronta esatta di quell'errore.

IPv6 su qualsiasi lato del pacchetto annidato invalida ogni cifra sopra, quindi ricalcolate invece di copiare un numero da un sito simile. Le intestazioni sottratte sono da 40 byte ciascuna appena IPv6 compare nel percorso esterno o nel datagramma originale, e la cifra del payload scende esattamente di tanto.

La regola firewall che probabilmente non vi serve

Tra due peer WireGuard l'unica cosa sul filo è UDP, quindi una regola in ingresso per il protocollo 4, il numero che RFC 2003 assegna all'incapsulamento IPv4-in-IPv4, non crea il percorso annidato né lo mantiene vivo. L'intestazione IPIP vive dentro il payload cifrato, dove nessun firewall di bordo la vede. Aprire comunque il protocollo 4 non compra nulla oltre a una via consentita in più verso l'host.

La politica che menziona le sorgenti e le destinazioni del pacchetto originale appartiene dopo la decapsulazione, sulle interfacce del tunnel e nella tabella di routing. Mettetela lì e la regola di bordo può restare chiusa.

Cosa valida davvero WireGuard

AllowedIPs giudica la sorgente del pacchetto che WireGuard trasporta, e ciò che trasporta è il pacchetto incapsulato in IPIP. Una sorgente IPIP consentita viene accettata anche quando l'intestazione interna nomina un host che preferireste non instradare. La sorgente originale, quindi, non è ciò che il peer ha controllato per voi, e quella coppia interna di indirizzi ha bisogno della propria applicazione dopo la decapsulazione.

Il wrapper fornisce struttura di routing, non un secondo strato di crittografia. Chiamare IPIP protezione extra dentro WireGuard descrive un progetto diverso.

Verificate con una scala, non con un solo ping

Provate dimensioni che circondano il confine che avete calcolato, poi confermate cosa crede il kernel di entrambi i dispositivi. Con 1360 byte di payload più 40 byte di intestazioni che fanno 1400, il primo eco qui sotto entra e il secondo si siede un byte oltre il tetto:

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

Un passaggio pulito sotto il tetto e un fallimento alla prima dimensione sopra significano che l'aritmetica tiene da un capo all'altro. Poi rieseguite il trasferimento che si era bloccato in origine, perché una sonda sintetica dimostra il budget e non dice nulla sulle dimensioni di scrittura del mittente. Se il percorso annidato si rompe ancora a una dimensione che avete dimostrato entrare, ispezionate la decapsulazione e le rotte dell'estremità remota prima di tagliare altri dieci byte dall'MTU.