WireGuard stoppar: ei MTU-grense eller ein manglande videresendingsregel?
Ingenting utover serveren er eit videresendings- eller returruteproblem. Små førespurnader som verkar medan store stoppar, er signaturen til pakkestorleiken.
Vanen er å senke MTU-en så snart WireGuard oppfører seg dårleg, og den vanen skjuler ein annan feil. Ein gateway som ikkje videresender, og ein sti som ikkje ber store pakkar, gjev attkjennelege mønster: den eine feilar i begge retningar og ved kvar storleik, den andre overlever små førespurnader og døyr på store. Avgjer kva form du har før du endrar noko tal. Testen er billeg, og han fjernar helvta av dei moglege årsakene.
To feil, to ulike former
Eit videresendingsproblem viser seg rett bak serveren. Handtrykket lukkast, tunneladressa svarar, og ingenting bak gatewayen er tilgjengeleg, ikkje ein gong med ein bitte liten førespurnad. Pakken nådde serveren og vart ikkje send vidare, eller svaret hadde ingen rute tilbake.
Eit storleiksproblem viser seg berre over ein terskel. DNS, eit TCP-handtrykk og eit lite API-kall verkar, medan ei filnedlasting eller eit stort svar heng. Pakkane som fekk plass gjekk heile vegen, og dei som ikkje fekk plass vart sleppte ein stad utan ein brukbar rapport.
Dei skildringane peikar på ulike menneske og ulike konfigurasjonsfiler, difor er det meir verdt å måle forma enn å gjette. Ein einaste ping til gatewayen kan ikkje skilje dei.
Utelukk videresending før du krympar noko
Test ein destinasjon bak gatewayen, ikkje gatewayen sjølv. Ein ping til tunneladressa til serveren bevisar berre at grensesnittet er oppe og at du når maskina som avsluttar tunnelen. Trafikk for det vidare nettet avheng av at IP-videresending er slått på på den maskina, og av ein brannmur som lèt den videresende straumen gjennom. Begge må vere sanne, og viss éin er usann, oppstår den same stilla.
Returrutering tyder like mykje. Viss destinasjonsnettet ikkje veit korleis det når tunneladressa til klienten, kjem førespurnaden og svaret forsvinn, og klienten rapporterer ein tidsavbrot som ser identisk ut med ei droppa videresending.
Der designet brukar adresseomsetting, er omsetjingsregelen ein del av den returvegen. Å fjerne han medan ein jagar eit MTU-problem gjer eitt fungerande design om til eitt øydelagt, så les dei eksisterande reglane før du redigerer dei.
Mål kvar brotet byrjar
Les først videresendingsstatusen og filterreglane. Dette er skriveverna kontrollar, og dei svarar på det billege spørsmålet:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Test deretter storleikar med don’t-fragment-biten, frå klienten, mot ein vert bak gatewayen:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Viss den første testen verkar og den andre feilar med ein fragmenteringsfeil, fortel stien deg sin brukbare storleik. Viss ingen av dei verkar, ser du på videresending eller ruting, og MTU er ikkje variabelen som skal endrast.
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
Reparer laget du beviste
Når videresending er feilen, er rettinga ein videresendingsregel eller ei rute, uttrykt så smalt som designet tillèt. Når storleiken er feilen, er rettinga ein MTU som tek omsyn til innkapslinga på nettopp denne stien, brukt på grensesnittet som treng det og ikkje på kvar adapter i flåten.
Uansett, gjenta deretter same oppgåva mot same destinasjon. Viss den opphavlege store overføringa no fullførast, tok endringa for seg laget som feila. Viss berre den litle testen vart betre, handsama du eit symptom, og den verkelege grensa står framleis.
Skriv ned kva form du såg før endringa. Den eine lina, notert ved sida av rettinga, er det som hindrar den neste i å senke ein MTU som aldri var problemet.