WireGuard si blocca: un limite MTU o una regola di inoltro mancante?

L’abitudine è abbassare l’MTU appena WireGuard si comporta male, e quell’abitudine nasconde un altro guasto. Un gateway che non inoltra e un percorso che non trasporta pacchetti grandi producono schemi distinguibili: uno fallisce in entrambe le direzioni e a ogni dimensione, l’altro sopravvive alle richieste piccole e muore su quelle grandi. Identificate la forma che avete prima di cambiare qualsiasi numero. Il test è economico ed elimina metà delle cause possibili.

Due guasti, due forme diverse

Un problema di inoltro compare subito dopo il server. La stretta di mano riesce, l’indirizzo del tunnel risponde, e nulla dietro il gateway è raggiungibile nemmeno con una richiesta minuscola. Il pacchetto ha raggiunto il server e non è stato passato, oppure la risposta non aveva una rotta di ritorno.

Un problema di dimensione compare solo sopra una soglia. Il DNS, una stretta di mano TCP e una piccola chiamata API funzionano, mentre un download di file o una risposta grande si bloccano. I pacchetti che entravano hanno viaggiato da un capo all’altro, e quelli che non entravano sono stati scartati da qualche parte senza un rapporto utilizzabile.

Quelle descrizioni indicano persone diverse e file di configurazione diversi, perciò misurare la forma vale più di un’ipotesi. Un solo ping verso il gateway non può separarle.

Escludete l’inoltro prima di ridurre qualsiasi cosa

Provate una destinazione oltre il gateway, non il gateway stesso. Un ping all’indirizzo del tunnel del server dimostra solo che l’interfaccia è attiva e che raggiungete la macchina che termina il tunnel. Il traffico per la rete più ampia dipende dall’inoltro IP attivo su quella macchina e da un firewall che consenta il flusso inoltrato. Entrambe le cose devono essere vere, e se una è falsa si produce lo stesso silenzio.

Il routing di ritorno conta altrettanto. Se la rete di destinazione non sa come raggiungere l’indirizzo del tunnel del client, la richiesta arriva e la risposta scompare, e il client segnala un timeout che sembra identico a un inoltro scartato.

Dove il progetto usa la traduzione degli indirizzi, la regola di traduzione fa parte di quel percorso di ritorno. Rimuoverla mentre si insegue un problema di MTU trasforma un progetto funzionante in uno rotto, quindi leggete le regole esistenti prima di modificarle.

Misurate dove inizia la rottura

Leggete prima lo stato dell’inoltro e le regole di filtraggio. Sono controlli di sola lettura e rispondono alla domanda economica:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Poi provate le dimensioni con il bit don’t-fragment, dal client, verso un host oltre il gateway:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

Se la prima prova funziona e la seconda fallisce con un errore di frammentazione, il percorso vi sta dicendo la sua dimensione utilizzabile. Se nessuna delle due funziona, state guardando un inoltro o un routing, e l’MTU non è la variabile da cambiare.

Riparate lo strato che avete dimostrato

Quando l’inoltro è il guasto, la correzione è una regola di inoltro o una rotta, espressa nel modo più stretto che il progetto consente. Quando la dimensione è il guasto, la correzione è un MTU che tiene conto dell’incapsulamento su questo percorso preciso, applicato all’interfaccia che ne ha bisogno e non a ogni adattatore della flotta.

In ogni caso, ripetete poi lo stesso compito verso la stessa destinazione. Se il trasferimento grande originale ora si completa, la modifica ha affrontato lo strato che falliva. Se è migliorata solo la prova piccola, avete trattato un sintomo e il limite reale è ancora al suo posto.

Annotate quale forma avete osservato prima della modifica. Quella sola riga, registrata accanto alla correzione, è ciò che impedisce alla persona successiva di abbassare un MTU che non è mai stato il problema.