Hogyan adjunk egy teszt-LAN-nak saját WireGuard-kimenetet
Szűkítse egy LAN forgalmát egy WireGuard-kimenetre dedikált útválasztási táblával és elérhetetlen őrrel, miközben az átjáró megtartja a szokásos WAN-alapértelmezett útvonalát.
Három terv oldja meg ugyanazt a laborproblémát: egy kis LAN-nak WireGuard-társon keresztül kell kijutnia, miközben az átjáró maga megtartja a szokásos felfelé irányuló kapcsolatát. A csábító rövidítés a router alapértelmezett útvonalát a tunelbe tenni, de ez megtöri a doboz saját kezelési útvonalát és mindent, amit továbbít. Az érdekes lehetőség az egy interfészre és egy előtagra korlátozott szabályalapú útválasztás. Válasszon köztük úgy, hogy három kérdésre válaszol a gépről, amely valóban a rendelkezésére áll.
Döntse el, hol él a kimenet
Első kérdés: továbbít ez a gazdagép még valami mást is? Egy dedikált laborátjáró megél egy alapértelmezésben mindent eldobó továbbítási szabályzattal. Egy termelési feladatokat ellátó router nem tud, és egy versengő szabálykészlet rátelepítése egy felügyelt tűzfalra pontosan az a mód, ahogy a kieséseket ütemezni szokták. Második: ön birtokolhat-e két szabályzatobjektumot és azok sorrendjét újraindításokon át? Harmadik: az ön társa engedélyezi-e a tunel forráscímét és nyújt-e internetes kimenetet? Az a társ, amely csak egy magánhálózatot tesz elérhetővé, más termék, és semmilyen helyi útválasztási változtatás nem orvosolja ezt. Ha bármelyik válasz nem, akkor tegye a kimenetet inkább egy névtérbe vagy egy eldobható virtuális gépbe.
A névtér vagy a VM memóriába kerül, és tiszta robbanási sugarat ad. A szabályalapú útválasztás két szabályba kerül, és egyetlen dobozt hagy hibakeresésre.
Válassza azt a kimenetet, amely engedélyezi a forrását
Ebben a laborban a legtöbb hiba még egyetlen tűzfalszabály létezése előtt történik. A kimenet üzemeltetőjének el kell fogadnia azt a forráscímet, amelyet a csomagjai a fordítás után hordanak, és ebben a tervben ez a tunel címe, nem a LAN előtagja. Ezért a maszkolás a kezdetektől a terv része, és nem késői kiegészítés.
Erősítsen meg három dolgot az üzemeltetőnél: a társ engedélyezi a tunel címét, továbbítja az IPv4-et ahelyett, hogy magánál végződne, és alkalmazza a kimenő NAT-ot. Az első nélkül a csomagjai megérkeznek és eltűnnek. A harmadik nélkül magánforrással lépnek ki, és a következő ugrásnál meghalnak. Ezután ellenőrizze, hogy a wg-quick nem telepíti-e a saját alapértelmezett útvonalát, amit a Table = off akadályoz meg; ez a beállítás az útvonalak létrehozását nyomja el, nem a társ AllowedIPs-ellenőrzéseit vagy annak DNS-kezelését.
Két szabályzatobjektum végzi a terelést
A tereléshez tábla és szabály kell. A tábla két útvonalat tart: a LAN előtagját kifelé a LAN-interfészből és egy alapértelmezettet kifelé a tunelből. A szabály a LAN-interfészen érkező és ezt az előtagot hordozó forgalmat a táblába küldi. Használja a iif szelektort a forrás-egyezés mellett, mert az átjáró saját WireGuard-csomagjai helyben keletkeznek, és soha nem egyeznek egy bejövő interfésszel.
Az őr a keresés előtt jön, nem utána. Ez a sorrend a terv teljes biztonsági tulajdonsága.
Az őr egy második szabály ugyanazon a szelektoron, amelynek ítélete unreachable. Adjon neki magasabb numerikus prioritást, hogy a keresés még mindig nyerjen, amíg a tunel fenn van. Amikor a tunel útvonala eltűnik, a keresés semmit nem ad vissza, és az őr leállítja a kutatást ahelyett, hogy hagyná a főtábla WAN-alapértelmezésére esni.
ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0
Zárja be a visszaesési rést, mielőtt kinyitja
Először az őrt telepítse, és utána a keresést. A fordított sorrend másodpercekig tartó ablakot hagy, amelyben egy tesztkliens forgalma elérheti a felfelé irányuló kapcsolatot.
A szűrő fejezi be a képet. A forward horogban fogadja el a LAN-ból a tunelbe irányt a tesztelőtag számára és a létrejött visszirányt, majd dobjon el minden mást; az előtag NAT-ja a tunel interfészére a postrouting helyre kerül. Éppen a policy drop meghagyása a továbbító láncon az, ami a hiányzó útvonalat szakadás helyett csenddé teszi. A fordított útvonal szűrése laza módot igényel a tunel interfészén, mert egy nyilvános forrás, amely kibontva érkezik, a legjobb fordított útvonalával a WAN oldalon rendelkezik. A Linux az all és az interfészenkénti érték közül a magasabbat veszi, tehát a tunel interfészének beállítása nem ugyanaz, mint az érvényesítés mindenholi gyengítése.
Bizonyítsa a hibaesettel
Tegyen fel pontos kérdést a kernelnek a kliens forráscímének és az érkezési interfésznek a megnevezésével. Mindkettő nélkül a keresés más kérdésre válaszol, és mindkét esetben helyesnek látszik. Utána nézze meg a tűzfal számlálóit, a társ átviteli állapotát és a kliens saját szolgáltatását.
Tesztelje rendesen az eltávolítást. Állítsa le a tunelt, miközben a szabály és a szűrő a helyén marad: a kliensnek meg kell akadnia, az átjáró saját forgalmának pedig tovább kell működnie. Utána állítsa le a társat a helyi interfész érintése nélkül, és ez az az eset, amely elkapja a kizárólag az útvonal meglétére támaszkodó terveket. Végül indítsa újra, és ellenőrizze ismét a szabályok sorrendjét, mert az őrt eltávolító bontóhorog az egész tervet visszaadja a főtáblának. Jegyezze fel a tábla számát, a prioritásokat és az interfészneveket a változási jegyre, mert a következő ember, aki szabályt ad hozzá, fogja ezt elrontani.