WireGuard zastajkuje: ograničenje MTU ili pravilo prosljeđivanja koje nedostaje?
Sve iza servera ukazuje na problem prosljeđivanja ili povratne rute. Mali zahtjevi koji prolaze dok veliki zastajkuju potpis su veličine paketa.
Navika je sniziti MTU čim se WireGuard počne loše ponašati, a ta navika skriva drugu grešku. Mrežni prolaz koji ne prosljeđuje i putanja koja ne nosi velike pakete daju različite obrasce: jedan pada u oba smjera i pri svakoj veličini, drugi preživljava male zahtjeve i gine na velikim. Utvrdite koji oblik imate prije nego promijenite bilo koji broj. Test je jeftin i uklanja polovinu mogućih uzroka.
Dvije greške, dva različita oblika
Problem prosljeđivanja pojavljuje se odmah iza servera. Rukovanje uspije, adresa tunela odgovara, a ništa iza prolaza nije dostupno čak ni malim zahtjevom. Paket je stigao do servera i nije proslijeđen, ili odgovor nije imao povratnu rutu.
Problem veličine pojavljuje se samo iznad praga. DNS, TCP rukovanje i mali API poziv rade, dok se preuzimanje datoteke ili veliki odgovor zakoči. Paketi koji su stali putovali su od kraja do kraja, a oni koji nisu ispušteni su negdje bez korisnog izvještaja.
Ti opisi upućuju na različite ljude i različite konfiguracijske datoteke, zato je mjerenje oblika vrijednije od nagađanja. Jedan ping prema prolazu ne može ih razdvojiti.
Isključite prosljeđivanje prije nego bilo što smanjite
Testirajte odredište iza prolaza, ne sam prolaz. Ping na adresu tunela servera dokazuje samo da je sučelje aktivno i da možete doći do računala koje završava tunel. Promet za širu mrežu zavisi od toga da je IP prosljeđivanje omogućeno na tom računalu i od vatrozida koji dopušta proslijeđeni tok. Oboje mora biti istinito, a ako je bilo što lažno, nastaje ista tišina.
Povratno usmjeravanje jednako je važno. Ako odredišna mreža ne zna kako doći do adrese tunela klijenta, zahtjev stigne a odgovor nestane, pa klijent prijavi istek vremena koji izgleda isto kao ispušteno prosljeđivanje.
Tamo gdje dizajn koristi prevođenje adresa, pravilo prevođenja dio je te povratne putanje. Uklanjanje tog pravila dok jurite problem MTU-a pretvara jedan radni dizajn u pokvaren, zato pročitajte postojeća pravila prije nego ih uredite.
Izmjerite gdje prekid počinje
Prvo pročitajte stanje prosljeđivanja i pravila filtriranja. To su provjere samo za čitanje i odgovaraju na jeftino pitanje:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Zatim provjerite veličine s bitom za zabranu fragmentacije, s klijenta, prema računalu iza prolaza:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Ako prva provjera radi a druga padne s greškom fragmentacije, putanja vam govori svoju upotrebljivu veličinu. Ako nijedna ne radi, gledate prosljeđivanje ili usmjeravanje, a MTU nije varijabla koju treba mijenjati.
| 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 |
Popravite sloj koji ste dokazali
Kada je prosljeđivanje greška, ispravka je pravilo prosljeđivanja ili ruta, izražena što je uže dizajn dopušta. Kada je veličina greška, ispravka je MTU koji uzima u obzir enkapsulaciju na toj konkretnoj putanji, primijenjen na sučelje kojem treba, a ne na svaki adapter u floti.
U svakom slučaju, poslije ponovite isti zadatak prema istom odredištu. Ako izvorni veliki prijenos sada završi, promjena je riješila sloj koji je padao. Ako se poboljšala samo mala provjera, liječili ste simptom i stvarna granica je još na mjestu.
Zapišite koji ste oblik primijetili prije promjene. Taj jedan redak, zabilježen uz ispravku, ono je što sprječava sljedeću osobu da snizi MTU koji nikada nije bio problem.