WireGuard stringa: MTU riba ar trūkstama perdavimo taisyklė?
Viskas už serverio yra perdavimo arba grįžimo maršruto problema. Mažos užklausos veikia, o didelės stringa – tai paketo dydžio požymis.
Įprotis yra sumažinti MTU vos tik WireGuard pradeda elgtis blogai, ir tas įprotis paslepia kitą gedimą. Tinklo vartai, kurie neperduoda, ir kelias, kuris neneša didelių paketų, duoda atskiriamus modelius: vienas žlunga abiem kryptimis ir esant bet kokiam dydžiui, kitas išgyvena mažas užklausas ir miršta prie didelių. Nustatykite, kuri forma yra pas jus, prieš keisdami bet kokį skaičių. Testas pigus ir pašalina pusę galimų priežasčių.
Du gedimai, dvi skirtingos formos
Perdavimo problema pasireiškia iškart už serverio. Rankos paspaudimas pavyksta, tunelio adresas atsako, o už vartų nieko nepasiekiama net su maža užklausa. Paketas pasiekė serverį ir nebuvo perduotas, arba atsakymas neturėjo grįžimo maršruto.
Dydžio problema pasireiškia tik virš slenksčio. DNS, TCP rankos paspaudimas ir mažas API iškvietimas veikia, o failo atsisiuntimas ar didelis atsakymas pakimba. Paketai, kurie tilpo, nukeliavo nuo pradžios iki galo, o tie, kurie netilpo, buvo kažkur numesti be naudingos ataskaitos.
Tie aprašymai nurodo skirtingus žmones ir skirtingus konfigūracijos failus, todėl formos matavimas vertas daugiau nei spėjimas. Vienas ping į vartus negali jų atskirti.
Pašalinkite perdavimą, kol ko nors nesumažinote
Išbandykite tikslą už vartų, o ne pačius vartus. Ping į serverio tunelio adresą įrodo tik tai, kad sąsaja veikia ir kad pasiekiate mašiną, kuri užbaigia tunelį. Didesnio tinklo srautas priklauso nuo to, ar toje mašinoje įjungtas IP perdavimas, ir nuo ugniasienės, kuri leidžia perduodamą srautą. Abu turi būti tiesa, o jei vienas yra netiesa, atsiranda ta pati tyla.
Grįžimo maršrutizavimas yra ne mažiau svarbus. Jei paskirties tinklas nežino, kaip pasiekti kliento tunelio adresą, užklausa ateina ir atsakymas dingsta, o klientas praneša apie skirtąjį laiką, kuris atrodo lygiai taip pat kaip atmestas perdavimas.
Ten, kur projektas naudoja adresų vertimą, vertimo taisyklė yra to grįžimo kelio dalis. Jos pašalinimas vejantis MTU problemą paverčia veikiantį projektą sugedusiu, todėl prieš redaguodami perskaitykite galiojančias taisykles.
Išmatuokite, kur prasideda lūžis
Pirmiausia perskaitykite perdavimo būseną ir filtravimo taisykles. Tai tik skaitymo patikros ir jos atsako į pigų klausimą:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Tada patikrinkite dydžius su don’t-fragment bitu, iš kliento, link pagrindinio kompiuterio už vartų:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Jei pirmoji patikra veikia, o antroji žlunga su fragmentavimo klaida, kelias jums sako savo naudingą dydį. Jei neveikia nė viena, žiūrite į perdavimą arba maršrutizavimą, o MTU nėra keičiamas kintamasis.
| 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 |
Pataisykite sluoksnį, kurį įrodėte
Kai perdavimas yra gedimas, pataisa yra perdavimo taisyklė arba maršrutas, išreikštas kuo siauriau, kiek projektas leidžia. Kai dydis yra gedimas, pataisa yra MTU, kuris atsižvelgia į inkapsuliavimą šiame konkrečiame kelyje, taikomas sąsajai, kuriai jo reikia, o ne kiekvienam adapteriui parke.
Bet kokiu atveju po to pakartokite tą pačią užduotį tam pačiam tikslui. Jei pradinis didelis perkėlimas dabar baigiasi, pakeitimas sprendė tą sluoksnį, kuris žlugo. Jei pagerėjo tik maža patikra, gydėte simptomą ir tikroji riba vis dar vietoje.
Užrašykite, kokią formą pastebėjote prieš pakeitimą. Ta viena eilutė, užrašyta prie pataisos, yra tai, kas neleidžia kitam žmogui sumažinti MTU, kuris niekada nebuvo problema.