WireGuard se ustavi: omejitev MTU ali manjkajoče pravilo posredovanja?
Vse za strežnikom je težava posredovanja ali povratne poti. Majhne zahteve delujejo, velike se ustavijo — to je podpis velikosti paketa.
Navada je znižati MTU takoj, ko se WireGuard začne obnašati slabo, in ta navada skriva drugo napako. Prehod, ki ne posreduje, in pot, ki ne nosi velikih paketov, dajeta razločljive vzorce: eden odpove v obe smeri in pri vsaki velikosti, drugi preživi majhne zahteve in umre pri velikih. Ugotovite, katero obliko imate, preden spremenite katero koli število. Test je poceni in odpravi polovico možnih vzrokov.
Dve napaki, dve različni obliki
Težava posredovanja se pojavi takoj za strežnikom. Rokovanje uspe, naslov tunela odgovori, in nič za prehodom ni dosegljivo niti z majhno zahtevo. Paket je prispel do strežnika in ni bil posredovan, ali odgovor ni imel povratne poti.
Težava velikosti se pojavi le nad pragom. DNS, rokovanje TCP in majhen klic API delujejo, medtem ko se prenos datoteke ali velik odgovor ustavi. Paketi, ki so se prilegli, so potovali od enega do drugega konca, tisti, ki se niso, pa so bili nekje zavrženi brez uporabnega poročila.
Ti opisi kažejo na različne ljudi in različne konfiguracijske datoteke, zato je merjenje oblike vredno več kot ugibanje. En sam ping do prehoda jih ne more ločiti.
Izključite posredovanje, preden karkoli zmanjšate
Preizkusite cilj za prehodom, ne prehoda samega. Ping na naslov tunela strežnika dokazuje le, da je vmesnik aktiven in da dosežete stroj, ki zaključi tunel. Promet za širše omrežje je odvisen od omogočenega posredovanja IP na tem stroju in od požarnega zidu, ki dovoli posredovani tok. Oboje mora biti resnično, in če je eno napačno, nastane enaka tišina.
Povratno usmerjanje je enako pomembno. Če ciljno omrežje ne ve, kako doseči naslov tunela odjemalca, zahteva prispe in odgovor izgine, odjemalec pa poroča o časovni prekoračitvi, ki je videti enako kot zavrženo posredovanje.
Kjer načrt uporablja prevajanje naslovov, je pravilo prevajanja del te povratne poti. Če ga odstranite med iskanjem težave z MTU, spremenite delujočo zasnovo v pokvarjeno, zato preberite obstoječa pravila, preden jih uredite.
Izmerite, kje se prelom začne
Najprej preberite stanje posredovanja in pravila filtriranja. To so pregledi samo za branje in odgovorijo na poceni vprašanje:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9
Nato preizkusite velikosti z bitom don’t-fragment, z odjemalca, proti gostitelju za prehodom:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9
Če prvi preizkus deluje in drugi ne uspe z napako razdrobljenosti, vam pot pove svojo uporabno velikost. Če ne deluje noben, gledate posredovanje ali usmerjanje, in MTU ni spremenljivka, ki bi jo bilo treba spremeniti.
| 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 plast, ki ste jo dokazali
Ko je posredovanje napaka, je popravek pravilo posredovanja ali pot, izražena čim ožje, kot zasnova dopušča. Ko je velikost napaka, je popravek MTU, ki upošteva enkapsulacijo na tej konkretni poti, uporabljen na vmesniku, ki ga potrebuje, in ne na vsakem vmesniku v floti.
Kakor koli, po tem ponovite isto nalogo proti istemu cilju. Če se prvotni velik prenos zdaj zaključi, je sprememba obravnavala plast, ki je odpovedala. Če se je izboljšal le majhen preizkus, ste zdravili simptom in prava meja je še vedno na mestu.
Zapišite, katero obliko ste opazili pred spremembo. Tista ena vrstica, zabeležena ob popravku, je tisto, kar prepreči naslednji osebi, da zniža MTU, ki nikoli ni bil težava.