WireGuard stöðvast: MTU-mörk eða vantar framsendingarreglu?
Allt handan við þjóninn er framsendingar- eða bakleiðarvandamál. Litlar beiðnir sem virka á meðan stórar stöðvast eru fingrafar pakkastærðar.
Venjan er að lækka MTU um leið og WireGuard fer að hegða sér illa, og sú venja felur annað bilun. Hlið sem sendir ekki fram og slóð sem ber ekki stóra pakka gefa greinanleg mynstur: önnur bregst í báðar áttir og við hverja stærð, hin lifir litlar beiðnir af og deyr á stórum. Greinið hvaða lögun þið hafið áður en þið breytið einhverri tölu. Prófið er ódýrt og það fjarlægir helming mögulegra orsaka.
Tvær bilanir, tvö mismunandi form
Framsendingarvandamál birtist strax handan við þjóninn. Handabandið tekst, tunnelfangið svarar, og ekkert bak við hliðið er aðgengilegt, jafnvel ekki með litla beiðni. Pakkinn náði þjóninum og var ekki sendur áfram, eða svarið hafði enga bakleið.
Stærðarvandamál birtist aðeins yfir þröskuldi. DNS, TCP-handaband og lítið API-kall virka, á meðan niðurhal skráar eða stórt svar hangir. Pakkarnir sem komust fóru enda á milli, og þeir sem komust ekki voru felldir einhvers staðar án nothæfrar skýrslu.
Þessar lýsingar benda á mismunandi fólk og mismunandi stillingarskrár, þess vegna er meira virði að mæla lögunina en að giska. Eitt ping á hliðið getur ekki aðskilið þau.
Útilokið framsendingu áður en þið minnkið eitthvað
Prófið áfangastað handan við hliðið, ekki hliðið sjálft. Ping á tunnelfang þjónsins sannar aðeins að viðmótið sé uppi og að þið náið í vélina sem endar tunnilinn. Umferð fyrir víðara netið er háð því að IP-framsending sé virk á þeirri vél og eldvegg sem leyfir framsenda flæðið. Bæði verða að vera sönn, og ef annað er ósatt verður sama þögnin.
Bakleiðarleiðsla skiptir jafn miklu máli. Ef áfangastaðarnetið veit ekki hvernig það nær tunnelfangi biðlarans koma beiðnin og svarið hverfur, og biðlarinn tilkynnir tímanút sem lítur nákvæmlega út eins og felldri framsendingu.
Þar sem hönnunin notar fangaskipti er skiptireglan hluti af þeirri bakleið. Að fjarlægja hana þegar elt er MTU-vandamál breytir virkri hönnun í brotna, svo lesið gildandi reglur áður en þið breytið þeim.
Mælið hvar rofið byrjar
Lesið fyrst stöðu framsendingar og síureglurnar. Þetta eru lestraraðgerðir og þær svara ódýru spurningunni:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9Prófið síðan stærðir með don’t-fragment-bitinu, frá biðlaranum, í átt að vél handan við hliðið:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9Ef fyrsta prófið virkar og annað bregst með sundrunarvillu segir slóðin þér nothæfa stærð sína. Ef ekkert virkar eruð þið að horfa á framsendingu eða leiðslingu, og MTU er ekki breytan sem á að breyta.
| 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 |
Lagið það lag sem þið sönnuðuð
Þegar framsendingin er bilunin er lagfæringin framsendingarregla eða leið, sett fram eins þröngt og hönnunin leyfir. Þegar stærðin er bilunin er lagfæringin MTU sem tekur tillit til innpökkunar á þessari tilteknu slóð, beitt á viðmótið sem þarf á henni að halda en ekki á hvern millistykki flotans.
Hvort sem er, endurtakið sömu verkefni gegn sama áfangastað eftir það. Ef upphaflega stóra flutningnum lýkur núna tók breytingin á því lagi sem brást. Ef aðeins litla prófið batnaði meðhöndluðuð þið einkenni og raunverulega mörkin eru enn á sínum stað.
Skrifið niður hvaða lögun þið sáu fyrir breytinguna. Sú eina lína, skráð við hlið lagfæringarinnar, er það sem kemur í veg fyrir að næsti maður lækki MTU sem var aldrei vandamálið.