VPN-kliensek és a LAN: mikor érdemes külön zónát használni

Az alagút-interfész LAN-zónába helyezése a legrövidebb út egy működő VPN-hez, és rendszerint ez a rossz alapértelmezés. Ugyanazt a bizalmat adja a távoli kliensnek, mint a vezetékes LAN, amit a feladat ritkán igényel. Egy külön zóna néhány szabályba kerül, és láthatóvá teszi a határt. A döntés nem az, hogy jobbak-e a zónák; hanem az, hogy melyik három feltétel érvényes a hálózatára.

A zóna neve semmit nem titkosít, és nem hitelesít felhasználót. Csak interfészeket csoportosít a tűzfal házirend-modelljéhez.

Mit irányít valójában a zónatagság

Egy zóna interfészeket vagy forgalmat csoportosít a tűzfal modelljében. Bemeneti, kimeneti és továbbítási beállításai aztán különböző szerepeket irányítanak. A bemenet a router felé irányuló forgalom; a továbbítás a rajta át más hoszthoz tartó forgalom. Az OpenWrt zónákról szóló dokumentációja pontosan ezért kezeli a bemenetet, a kimenetet és a továbbítást külön beállításként.

Az engedély a VPN-zónából a LAN-zónába nem automatikusan fordított engedély. A továbbítási szabályok irányítottak, és az a szabály, amely kliensből szerverbe enged forgalmat, nem enged szerverből kliensbe munkameneteket. Az a kliens, amely kapcsolatot tud nyitni egy szerverhez, nem az a kliens, amely felé a szerver visszakapcsolatot tud nyitni.

Ez a különbség az oka annak, hogy hasznos a külön zóna: minden irányt és minden szerepet kifejezetten megadhat. Minden szabály mellé írja oda az irányt.

Első döntés: bemenet, továbbítás vagy mindkettő

Ha a távoli klienseknek DNS kell a routerről, csak arra a szolgáltatásra engedélyezze a bemenetet. Ha el kell érniük egy fájlszervert, engedélyezze a továbbítást arra a célra. A legtöbb VPN-terv mindkettőt igényli, de különböző szolgáltatásokhoz.

Széles bemeneti hozzáférés minden helyi szolgáltatáshoz szinte soha nem szükséges. Kezelje a router felügyeletét a hozzáféréstől külön döntésként. Ha a routernek csak DNS-re kell válaszolnia, írja le azt az egyetlen engedélyt, és hagyja a többit zárva.

Második döntés: milyen erőforrásokra van szükségük a távoli klienseknek

A szabályok írása előtt sorolja fel az ügyfél-tartományokat, a célokat és a VPN által nyújtandó szolgáltatásokat. A célok listája hasznosabb, mint egy bizalmi címke, mert túléli a tűzfal áttelepítését.

Tartsa a felügyeleti interfészeket elkülönítve a szokásos alkalmazáshozzáféréstől. Az a távoli kliens, amely elér egy wikit, ezzel még nem igényli a router adminoldalát vagy a hypervisor konzolját.

Ha egy engedélyezett cél tovább tud továbbítani, a zóna határa a tűzfalon ér véget, nem azon, amit a cél utána tesz.

Harmadik döntés: hogyan bizonyítja a határt

Minden változtatás után teszteljen egy engedélyezett és egy szándékosan tiltott folyamatot. Annak bizonyítása, hogy egy webhely betöltődik, nem tár fel nem szándékolt széles engedélyt. A VPN-kliens címtartományából teszteljen, ne a LAN-ból, és foglalja bele az irányt, amelynél kudarcot vár. Mindkét eredményt jegyezze fel a szabály mellé.

Őrizze meg az átjáró helyreállítási hozzáférését, mielőtt módosítja a távoli zóna házirendjét. Használja a tartós kezelt konfigurációt futásidejű módosítások helyett, különben a következő újraindítás visszaállítja a régi bizalmat. Az előző konfiguráció eszközön kívül tárolt másolata a legolcsóbb visszaállítás, amit valaha kaphat.

Ahogy a hálózat nő, dokumentálja a tagságot és a szabályok célját. Egy újonnan csatlakoztatott interfész nem örökölhet jogosultságokat csak azért, mert valaki kényelmes zónanevet adott neki.