WireGuard stokt: een MTU-limiet of een ontbrekende doorstuurregel?

De gewoonte is de MTU te verlagen zodra WireGuard zich slecht gedraagt, en die gewoonte verbergt een ander defect. Een gateway die niet doorstuurt en een pad dat geen grote pakketten draagt, geven onderscheidbare patronen: de ene faalt in beide richtingen en bij elke grootte, de andere overleeft kleine verzoeken en sterft op grote. Bepaal welke vorm u heeft voordat u een getal verandert. De test is goedkoop en hij haalt de helft van de mogelijke oorzaken weg.

Twee storingen, twee verschillende vormen

Een doorstuurprobleem verschijnt direct achter de server. De handshake slaagt, het tunneladres antwoordt, en niets achter de gateway is bereikbaar, zelfs niet met een klein verzoek. Het pakket bereikte de server en werd niet doorgegeven, of het antwoord had geen route terug.

Een grootteprobleem verschijnt alleen boven een drempel. DNS, een TCP-handshake en een kleine API-aanroep werken, terwijl een bestandsdownload of een groot antwoord blijft hangen. De pakketten die pasten reisden van begin tot eind, en de pakketten die niet pasten werden ergens zonder bruikbaar rapport weggegooid.

Die beschrijvingen wijzen op verschillende mensen en verschillende configuratiebestanden, daarom is het meten van de vorm meer waard dan een gok. Een enkele ping naar de gateway kan ze niet scheiden.

Sluit doorsturen uit voordat u iets verkleint

Test een bestemming voorbij de gateway, niet de gateway zelf. Een ping naar het tunneladres van de server bewijst alleen dat de interface actief is en dat u de machine bereikt die de tunnel beëindigt. Verkeer voor het bredere netwerk hangt af van ingeschakelde IP-doorsturing op die machine en van een firewall die de doorgestuurde stroom toestaat. Beide moeten waar zijn, en als een van beide onwaar is, ontstaat dezelfde stilte.

Terugroutering is even belangrijk. Als het bestemmingsnetwerk niet weet hoe het het tunneladres van de client bereikt, komt het verzoek aan en verdwijnt het antwoord, en de client meldt een time-out die er identiek uitziet als een weggegooide doorsturing.

Waar het ontwerp adresvertaling gebruikt, is de vertaalregel deel van dat terugpad. Die verwijderen terwijl u een MTU-probleem achtervolgt, maakt van een werkend ontwerp een kapot ontwerp, dus lees de bestaande regels voordat u ze bewerkt.

Meet waar de breuk begint

Lees eerst de doorstuurstatus en de filterregels. Dit zijn alleen-lezen controles en ze beantwoorden de goedkope vraag:

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

Test daarna groottes met de don’t-fragment-bit, vanaf de client, richting een host voorbij de gateway:

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

Als de eerste test werkt en de tweede faalt met een fragmentatiefout, vertelt het pad u zijn bruikbare grootte. Als geen van beide werkt, kijkt u naar doorsturen of routering, en de MTU is niet de variabele die moet veranderen.

Repareer de laag die u heeft bewezen

Wanneer doorsturen het defect is, is de correctie een doorstuurregel of een route, zo nauw geformuleerd als het ontwerp toestaat. Wanneer de grootte het defect is, is de correctie een MTU die de inkapseling op precies dit pad meeneemt, toegepast op de interface die het nodig heeft en niet op elke adapter in de vloot.

Hoe dan ook, herhaal daarna dezelfde taak naar dezelfde bestemming. Als de oorspronkelijke grote overdracht nu voltooit, heeft de wijziging de laag aangepakt die faalde. Als alleen de kleine test verbeterde, heeft u een symptoom behandeld en de echte grens staat er nog.

Schrijf op welke vorm u voor de wijziging zag. Die ene regel, naast de correctie vastgelegd, is wat de volgende persoon ervan weerhoudt een MTU te verlagen die nooit het probleem was.