Shorewall-zónák a két OpenVPN-csomagútvonalhoz
Válassza el a titkosított OpenVPN-szállítást a visszafejtett kliensforgalomtól, adjon a tunelnek saját zónát, és csak azt az egy szolgáltatást engedje, amelyre a kliensnek szüksége van.
Két csomagfolyam halad át egy Shorewall-átjárón, amely lezárja az OpenVPN-t, és csak az egyikük titkosított. Az első a kliens szállítása az internet felé néző interfészen lévő VPN-figyelőhöz. A második a titkosítatlan kérés, amely elhagyja az alagút interfészét egy irodai kiszolgáló vagy az átjárón lévő szolgáltatás felé. Térképezze fel mindkettőt a szabályzat szerkesztése előtt, mert az elsőt kielégítő szabály semmit nem tesz a másodikért.
Rajzolja fel a két folyamot a szabályzat szerkesztése előtt
Írja le a folyamokat sorokként forrással, céllal, protokollal és porttal. A külső útvonalon a forrás a kliens nyilvános címe, a cél pedig az átjáró figyelő portja; a Shorewall ezt internetről a tűzfal felé irányuló forgalomként kezeli. A belső útvonalon a forrás az alagút cím tartománya, a cél pedig a jóváhagyott szolgáltatás. A két sornak különböző a tulajdonosa akkor is, ha egyetlen adminisztrátor tartja karban mindkettőt.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
Csak akkor adjon hozzá sort, ha a kérés magán az átjárón végződik, például a feloldó vagy a felügyelet elérése. A hoszton lévő szolgáltatás a hoszt bemeneti szabályzatát követi, nem a továbbított útvonalat. A kettő keverése az, amitől egy szűk alagútszabály végül felfed egy felügyeleti interfészt.
Rendelje hozzá az alagút zónáját és az interfész hatókörét
Az utazó zónáját a /etc/shorewall/zones fájlban deklarálják, az alagút interfészét a /etc/shorewall/interfaces fájlban csatolják, a külső kapcsolatot pedig a /etc/shorewall/tunnels fájl írja le. Igazodjon a telepített kiadás szintaxisához, mert az oszlopok sorrendje és az opciók nevei a fő verziók között megváltoztak. Az útmutató példaportja nem ok arra, hogy más portot engedjen, mint amelyen a démon valójában figyel. A TCP és az UDP nem felcserélhető csak azért, mert a számok megegyeznek.
Az útmutató a tun+ mintával csoportosítja az interfészeket. Egy egynél több alagúttal rendelkező hoszton ez a helyettesítő karakter egy másik bizalmi szintű VPN-t is ugyanabba a zónába helyezhet. Vizsgálja felül a hatókört a ténylegesen létező interfészekhez képest, és tartsa az elnevezést a kapcsolatkezelő életciklusa alatt ahelyett, hogy kézzel szerkesztené az interfészneveket.
A történelmi útmutató sokkal régebbi OpenVPN-konfiguráció mintákat tartalmaz, és a kriptográfiai tanácsait nem szabad jelenlegi telepítésbe másolni. Kölcsönözze inkább a zóna- és folyammodellt. A kriptográfiai alapot az átjáró karbantartott OpenVPN-szabályzatából vegye.
Csak a besorolt útvonalat engedje
A VPN-zónából a LAN felé adott széles engedély kiinduló vázlat, nem kész szabályzat. Írja le az engedélyezett kliens forrást, a szolgáltatás tényleges címét, a protokollt és a portot. Utána olvassa el a fölötte lévő szabályokat és a zóna alapértelmezését, mert egy szűk kiegészítés nem törli a már illeszkedő széles engedélyt. Az átjáró hosztja felé irányuló forgalom külön viszony a rajta keresztül továbbított forgalomtól.
A kliens-kliens forgalom saját döntést igényel. Az OpenVPN client-to-client és a Shorewall routeback beállítása egyaránt befolyásolja, hogy a kliensek elérik-e egymást, és egyiket sem szabad csak azért engedélyezni, hogy egy LAN-alkalmazás működjön. Döntse el, hol érvényesül az elkülönítés, mielőtt teszteli.
Tartsa a válaszútvonalat ugyanabban a tervben. A szolgáltatásnak vagy az útválasztójának tudnia kell, hogyan küldje vissza a forgalmat az alagút tartományába, vagy a tervezésnek szándékosan és a tervezett hatókörön belül kell lefordítania a forrást.
Érvényesítse, majd bizonyítsa mindkét útvonalat
Az újraindítás előtt érvényesítse a konfigurációt, és tartson nyitva egy független felügyeleti munkamenetet arra az esetre, ha az új szabályzat hibás.
shorewall checkTiszta ellenőrzés után alkalmazza a konfigurációt, és olvassa vissza, mit töltött be a Shorewall. Ezek az olvasatok a futó szabályzatot írják le, nem azt, amit egy fájl mondani látszik.
shorewall show zones
ip route get 192.168.10.20Teszteljen egy friss engedélyezett kérést és egy szándékosan elutasított kérést ugyanattól a klienstől. A sikeres OpenVPN-kézfogás csak a külső cserét bizonyítja; az engedélyezett szolgáltatás és az elutasított erőforrás bizonyítja a szándékolt belső szabályzatot. Ezután csatlakoztassa újra a klienst, és ismételje meg, mert az alagút interfészének neve és címe munkamenetek között változhat. Ha az eredmény eltér, javítsa a zóna hatókörét, ne szélesítse a szabályt.