A WireGuard elakad: MTU-korlát vagy hiányzó továbbítási szabály?

A szokás az, hogy a WireGuard első rossz viselkedésekor csökkentjük az MTU-t, és ez a szokás más hibát takar el. Egy átjáró, amely nem továbbít, és egy útvonal, amely nem visz nagy csomagokat, megkülönböztethető mintákat ad: az egyik mindkét irányban és minden méretnél elbukik, a másik túléli a kis kéréseket és meghal a nagyokon. Állapítsa meg, melyik forma van Önnél, mielőtt bármelyik számot megváltoztatja. A próba olcsó, és a lehetséges okok felét kiszűri.

Két hiba, két különböző forma

A továbbítási probléma közvetlenül a kiszolgáló után jelentkezik. A kézfogás sikerül, az alagút címe válaszol, és az átjáró mögött semmi nem érhető el még egy apró kéréssel sem. A csomag eljutott a kiszolgálóig, és nem adták tovább, vagy a válasznak nem volt visszaútja.

A méretprobléma csak egy küszöb felett jelentkezik. A DNS, egy TCP-kézfogás és egy kis API-hívás működik, miközben egy fájllehúzás vagy egy nagy válasz elakad. A beférő csomagok végigmentek, a be nem férők pedig valahol használható jelentés nélkül elvesztek.

Ezek a leírások különböző emberekre és különböző konfigurációs fájlokra mutatnak, ezért a forma mérése többet ér a találgatásnál. Egyetlen ping az átjáróhoz nem tudja szétválasztani őket.

Zárja ki a továbbítást, mielőtt bármit csökkentene

Az átjárón túli célt tesztelje, ne magát az átjárót. A kiszolgáló alagútcímére küldött ping csak azt bizonyítja, hogy az interfész aktív, és eléri azt a gépet, amely lezárja az alagutat. A szélesebb hálózat forgalma attól függ, hogy engedélyezve van-e az IP-továbbítás azon a gépen, és egy tűzfaltól, amely átengedi a továbbított folyamot. Mindkettőnek igaznak kell lennie, és ha bármelyik hamis, ugyanaz a csend áll elő.

A visszaútvonal-kezelés ugyanolyan fontos. Ha a célhálózat nem tudja, hogyan érje el az ügyfél alagútcímét, a kérés megérkezik és a válasz eltűnik, az ügyfél pedig olyan időtúllépést jelent, amely pontosan úgy néz ki, mint egy eldobott továbbítás.

Ahol a terv címt fordítást használ, a fordítási szabály része ennek a visszaútnak. Eltávolítása az MTU-probléma üldözése közben egy működő tervet törtté tesz, ezért olvassa el a meglévő szabályokat szerkesztésük előtt.

Mérje meg, hol kezdődik a szakadás

Először olvassa el a továbbítás állapotát és a szűrőszabályokat. Ezek csak olvasási ellenőrzések, és megválaszolják az olcsó kérdést:

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9

Ezután próbálja ki a méreteket a don’t-fragment bittel, az ügyféltől, az átjárón túli gazdagép felé:

ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9

Ha az első próba működik, a második pedig töredezési hibával elbukik, az útvonal megmondja a használható méretét. Ha egyik sem működik, továbbítást vagy útvonalválasztást lát, és az MTU nem a változtatandó változó.

Javítsa meg a bizonyított réteget

Amikor a továbbítás a hiba, a javítás egy továbbítási szabály vagy egy útvonal, olyan szűken kifejezve, amennyire a terv engedi. Amikor a méret a hiba, a javítás egy MTU, amely figyelembe veszi ezen a konkrét útvonalon a beágyazást, és az arra rászoruló interfészre kerül, nem pedig a flotta minden adapterére.

Akárhogy is, utána ismételje meg ugyanazt a feladatot ugyanazon cél ellen. Ha az eredeti nagy átvitel most befejeződik, a változtatás azt a réteget kezelte, amely elbukott. Ha csak a kis próba javult, egy tünetet kezelt, és a valódi korlát még mindig a helyén van.

Jegyezze fel, milyen formát látott a változtatás előtt. Az az egy sor, a javítás mellé feljegyezve, az, ami megakadályozza a következő embert abban, hogy olyan MTU-t csökkentsen, amely soha nem volt a probléma.