WireGuard stopper: en MTU-grense eller en manglende videresendingsregel?
Ingenting utover serveren er et videresendings- eller returruteproblem. Små forespørsler som virker mens store stopper, er pakkestørrelsens signatur.
Vanen er å senke MTU-en så snart WireGuard oppfører seg dårlig, og den vanen skjuler en annen feil. En gateway som ikke videresender, og en sti som ikke bærer store pakker, gir gjenkjennelige mønstre: den ene feiler i begge retninger og ved hver størrelse, den andre overlever små forespørsler og dør på store. Avgjør hvilken form du har før du endrer noe tall. Testen er billig, og den fjerner halvparten av de mulige årsakene.
To feil, to forskjellige former
Et videresendingsproblem viser seg rett bak serveren. Håndtrykket lykkes, tunneladressen svarer, og ingenting bak gatewayen er tilgjengelig, selv ikke med en bitte liten forespørsel. Pakken nådde serveren og ble ikke sendt videre, eller svaret hadde ingen rute tilbake.
Et størrelsesproblem viser seg bare over en terskel. DNS, et TCP-håndtrykk og et lite API-kall virker, mens en filnedlasting eller et stort svar henger. Pakkene som fikk plass gikk hele veien, og de som ikke fikk plass ble sluppet et sted uten en brukbar rapport.
De beskrivelsene peker på forskjellige mennesker og forskjellige konfigurasjonsfiler, derfor er det mer verdt å måle formen enn å gjette. En enkelt ping til gatewayen kan ikke skille dem.
Utelukk videresending før du krymper noe
Test en destinasjon bak gatewayen, ikke gatewayen selv. En ping til serverens tunneladresse beviser bare at grensesnittet er oppe og at du når maskinen som avslutter tunnelen. Trafikk for det bredere nettet avhenger av at IP-videresending er slått på på den maskinen, og av en brannmur som tillater den videresendte strømmen. Begge må være sanne, og hvis én er usann, oppstår den samme stillheten.
Returrutering betyr like mye. Hvis destinasjonsnettet ikke vet hvordan det når klientens tunneladresse, kommer forespørselen og svaret forsvinner, og klienten rapporterer en tidsavbrudd som ser identisk ut med en droppet videresending.
Der designet bruker adresseoversettelse, er oversettelsesregelen en del av den returveien. Å fjerne den mens man jager et MTU-problem gjør ett fungerende design om til et ødelagt, så les de eksisterende reglene før du redigerer dem.
Mål hvor bruddet begynner
Les først videresendingsstatusen og filterreglene. Dette er skrivebeskyttede kontroller, og de svarer på det billige spørsmålet:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Test deretter størrelser med don’t-fragment-biten, fra klienten, mot en vert bak gatewayen:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Hvis den første testen virker og den andre feiler med en fragmenteringsfeil, forteller stien deg sin brukbare størrelse. Hvis ingen av dem virker, ser du på videresending eller ruting, og MTU er ikke variabelen som skal endres.
| 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 rettelsen en videresendingsregel eller en rute, uttrykt så smalt som designet tillater. Når størrelsen er feilen, er rettelsen en MTU som tar høyde for innkapslingen på nettopp denne stien, brukt på grensesnittet som trenger det og ikke på hver adapter i flåten.
Uansett, gjenta deretter samme oppgave mot samme destinasjon. Hvis den opprinnelige store overføringen nå fullføres, tok endringen for seg laget som feilet. Hvis bare den lille testen ble bedre, behandlet du et symptom, og den virkelige grensen står fortsatt.
Skriv ned hvilken form du så før endringen. Den ene linjen, notert ved siden av rettelsen, er det som hindrer den neste i å senke en MTU som aldri var problemet.