WireGuard s’encalla: un límit d’MTU o una regla de reenviament que falta?

El costum és baixar l’MTU tan bon punt WireGuard es comporta malament, i aquest costum amaga una altra avaria. Una passarel·la que no reenvia i un camí que no porta paquets grans produeixen patrons distingibles: un falla en les dues direccions i a totes les mides, l’altre sobreviu a les peticions petites i mor amb les grans. Identifiqueu quina forma teniu abans de canviar cap número. La prova és barata i elimina la meitat de les causes possibles.

Dues avaries, dues formes diferents

Un problema de reenviament apareix just després del servidor. L’acord de mà funciona, l’adreça del túnel respon, i res darrere de la passarel·la és abastable ni amb una petició minúscula. El paquet va arribar al servidor i no es va passar, o la resposta no tenia cap ruta de tornada.

Un problema de mida només apareix per sobre d’un llindar. El DNS, un acord TCP i una crida petita a l’API funcionen, mentre que la baixada d’un fitxer o una resposta gran es pengen. Els paquets que hi cabien van viatjar d’un extrem a l’altre, i els que no hi cabien es van descartar en algun lloc sense cap informe útil.

Aquestes descripcions assenyalen persones diferents i fitxers de configuració diferents, per això mesurar la forma val més que una conjectura. Un sol ping a la passarel·la no els pot separar.

Descarteu el reenviament abans d’encongir res

Proveu una destinació més enllà de la passarel·la, no la passarel·la mateixa. Un ping a l’adreça del túnel del servidor només demostra que la interfície està activa i que podeu arribar a la màquina que acaba el túnel. El trànsit per a la xarxa més àmplia depèn que el reenviament IP estigui activat en aquesta màquina i que un tallafoc permeti el flux reenviat. Totes dues coses han de ser certes, i si una és falsa es produeix el mateix silenci.

L’encaminament de tornada importa igual. Si la xarxa de destinació no sap com arribar a l’adreça del túnel del client, la petició arriba i la resposta desapareix, i el client informa d’un temps d’espera que sembla idèntic a un reenviament descartat.

On el disseny fa servir traducció d’adreces, la regla de traducció forma part d’aquest camí de tornada. Treure-la mentre es persegueix un problema d’MTU converteix un disseny que funciona en un de trencat, així que llegiu les regles existents abans d’editar-les.

Mesureu on comença el trencament

Primer llegiu l’estat del reenviament i les regles de filtratge. Són comprovacions només de lectura i responen la pregunta barata:

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

Després proveu mides amb el bit de no fragmentació, des del client, cap a un amfitrió més enllà de la passarel·la:

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

Si la primera prova funciona i la segona falla amb un error de fragmentació, el camí us està dient la seva mida útil. Si no funciona cap de les dues, esteu davant d’un reenviament o d’un encaminament, i l’MTU no és la variable que cal canviar.

Arregleu la capa que heu demostrat

Quan el reenviament és l’avaria, la correcció és una regla de reenviament o una ruta, expressada tan estretament com el disseny permeti. Quan la mida és l’avaria, la correcció és un MTU que té en compte l’encapsulació en aquest camí concret, aplicat a la interfície que el necessita i no a cada adaptador de la flota.

De qualsevol manera, després repetiu la mateixa tasca contra la mateixa destinació. Si la transferència gran original ara es completa, el canvi ha adreçat la capa que fallava. Si només ha millorat la prova petita, heu tractat un símptoma i el límit real continua al seu lloc.

Anoteu quina forma heu observat abans del canvi. Aquesta sola línia, registrada al costat de l’arreglament, és el que impedeix que la persona següent baixi un MTU que mai no era el problema.