WireGuard zamrzá: limit MTU, nebo chybějící pravidlo předávání?
Vše za serverem ukazuje na problém předávání nebo zpětné trasy. Malé požadavky procházejí, velké zamrzají, a to je podpis velikosti paketu.
Zvykem je snížit MTU, jakmile se WireGuard začne chovat špatně, a ten zvyk skrývá jinou závadu. Brána, která nepředává, a cesta, která neunese velké pakety, dávají rozlišitelné vzory: jeden selhává v obou směrech a při každé velikosti, druhý přežívá malé požadavky a umírá na velkých. Určete, který tvar máte, než změníte jakékoli číslo. Test je levný a odstraňuje polovinu možných příčin.
Dvě závady, dva různé tvary
Problém s předáváním se objeví hned za serverem. Handshake projde, adresa tunelu odpovídá, a nic za bránou není dostupné ani s malým požadavkem. Paket dorazil na server a nebyl předán, nebo odpověď neměla zpáteční trasu.
Problém s velikostí se objeví jen nad určitou hranicí. DNS, TCP handshake a malé volání API fungují, zatímco stahování souboru nebo velká odpověď zamrznou. Pakety, které se vešly, prošly od konce ke konci, a ty, které se nevešly, byly někde zahozeny bez použitelné zprávy.
Ty popsané projevy ukazují na různé lidi a různé konfigurační soubory, proto se vyplatí tvar změřit, ne hádat. Jediný ping na bránu je nedokáže rozlišit.
Vylučte předávání, než cokoli zmenšíte
Testujte cíl za bránou, ne bránu samotnou. Ping na adresu tunelu serveru dokazuje jen to, že rozhraní je nahoře a že se dostanete ke stroji, který tunel ukončuje. Provoz pro širší síť závisí na tom, zda je na tom stroji zapnuté IP předávání, a na firewallu, který předávaný tok povolí. Musí platit obojí, a když je jedno nepravdivé, nastane stejné ticho.
Zpětnému směrování je třeba věnovat stejnou pozornost. Pokud cílová síť neví, jak se dostat na adresu tunelu klienta, požadavek dorazí a odpověď zmizí, a klient hlásí časový limit, který vypadá stejně jako zahozené předávání.
Tam, kde návrh používá překlad adres, je pravidlo překladu součástí té zpětné cesty. Odstranit ho při honbě za problémem MTU znamená přeměnit funkční návrh na rozbitý, proto si před úpravou přečtěte stávající pravidla.
Změřte, kde přerušení začíná
Nejprve si přečtěte stav předávání a pravidla filtrování. Jsou to kontroly jen pro čtení a odpovídají na levnou otázku:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Potom otestujte velikosti s bitem don’t-fragment, z klienta, směrem k hostiteli za bránou:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Když první sonda projde a druhá selže s chybou fragmentace, cesta vám říká svou použitelnou velikost. Když neprojde ani jedna, díváte se na předávání nebo směrování a MTU není proměnná, kterou je třeba měnit.
| 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 |
Opravte vrstvu, kterou jste prokázali
Když je závadou předávání, opravou je pravidlo předávání nebo trasa, vyjádřené co nejúžeji, jak návrh dovolí. Když je závadou velikost, opravou je MTU, které zohledňuje zapouzdření na této konkrétní cestě, aplikované na rozhraní, které ho potřebuje, a ne na každý adaptér ve flotile.
Ať tak či onak, potom zopakujte stejný úkol proti stejnému cíli. Pokud původní velký přenos nyní doběhne, změna řešila vrstvu, která selhávala. Pokud se zlepšila jen malá sonda, léčili jste příznak a skutečný limit zůstává na místě.
Zapište, jaký tvar jste před změnou pozorovali. Ten jediný řádek, zaznamenaný vedle opravy, je to, co zabrání dalšímu člověku snížit MTU, které nikdy nebylo problémem.