WireGuard stannar: en MTU-gräns eller en saknad vidarebefordringsregel?

Vanan är att sänka MTU:n så snart WireGuard beter sig illa, och den vanan döljer ett annat fel. En gateway som inte vidarebefordrar och en väg som inte bär stora paket ger urskiljbara mönster: den ena misslyckas i båda riktningarna och vid varje storlek, den andra överlever små förfrågningar och dör på stora. Avgör vilken form du har innan du ändrar något tal. Testet är billigt och det tar bort hälften av de möjliga orsakerna.

Två fel, två olika former

Ett vidarebefordringsproblem visar sig direkt bakom servern. Handskakningen lyckas, tunneladressen svarar, och inget bakom gatewayen går att nå, inte ens med en liten förfrågan. Paketet nådde servern och skickades inte vidare, eller så hade svaret ingen väg tillbaka.

Ett storleksproblem visar sig bara över en tröskel. DNS, en TCP-handskakning och ett litet API-anrop fungerar, medan en filnedladdning eller ett stort svar hänger sig. Paketen som fick plats gick hela vägen, och de som inte fick plats släpptes någonstans utan en användbar rapport.

De beskrivningarna pekar på olika människor och olika konfigurationsfiler, därför är det mer värt att mäta formen än att gissa. En enda ping till gatewayen kan inte skilja dem.

Uteslut vidarebefordran innan du krymper något

Testa en destination bortom gatewayen, inte gatewayen själv. En ping till serverns tunneladress bevisar bara att gränssnittet är uppe och att du når maskinen som avslutar tunneln. Trafik för det bredare nätet beror på att IP-vidarebefordran är påslagen på den maskinen och på en brandvägg som tillåter det vidarebefordrade flödet. Båda måste vara sanna, och om en är falsk uppstår samma tystnad.

Returroutning betyder lika mycket. Om destinationsnätet inte vet hur det når klientens tunneladress kommer förfrågan fram och svaret försvinner, och klienten rapporterar en timeout som ser identisk ut med en tappad vidarebefordran.

Där designen använder adressöversättning är översättningsregeln en del av den returvägen. Att ta bort den medan man jagar ett MTU-problem gör en fungerande design till en trasig, så läs de befintliga reglerna innan du redigerar dem.

Mät var brottet börjar

Läs först vidarebefordringsstatusen och filterreglerna. Det är skrivskyddade kontroller och de svarar på den billiga frågan:

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

Testa sedan storlekar med don’t-fragment-biten, från klienten, mot en värd bortom gatewayen:

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

Om det första testet fungerar och det andra misslyckas med ett fragmenteringsfel talar vägen om sin användbara storlek. Om ingen av dem fungerar tittar du på vidarebefordran eller routning, och MTU är inte variabeln som ska ändras.

Reparera det lager du bevisade

När vidarebefordran är felet är korrigeringen en vidarebefordringsregel eller en rutt, uttryckt så snävt som designen tillåter. När storleken är felet är korrigeringen en MTU som tar hänsyn till inkapslingen på just den vägen, tillämpad på gränssnittet som behöver den och inte på varje adapter i flottan.

Hur som helst, upprepa sedan samma uppgift mot samma destination. Om den ursprungliga stora överföringen nu fullbordas tog ändringen itu med lagret som misslyckades. Om bara det lilla testet förbättrades behandlade du ett symptom och den verkliga gränsen står kvar.

Skriv ned vilken form du såg före ändringen. Den enda raden, antecknad bredvid korrigeringen, är det som hindrar nästa person från att sänka en MTU som aldrig var problemet.