Egy OpenVPN-hub, három LAN: címterv és iroute-fájlok

Három privát LAN találkozhat egyetlen hubnál anélkül, hogy bármelyik telephely megismerné a többi belső felépítését, és az egész tervezés négy rövid konfigurációs döntésen nyugszik. Nem egy egzotikus protokollfunkció működteti, hanem egy címterv, amelyet senkinek nem kell kitalálnia, valamint ügyfelenkénti útvonalak, amelyek megmondják a hubnak, melyik ág melyik előtagot birtokolja. Ha bármelyiket elrontja, az alagút mégis feljön, és éppen ez teszi zavaróvá a hibát.

Haladjon végig a lépéseken sorrendben. Mindegyik az előző lépés tervétől függ, és egyik sem igényel új tanúsító hatóságot.

Kezdje egy tervvel, amelyet senkinek nem kell kitalálnia

Írjon fel négy nem átfedő előtagot, mielőtt hozzányúl egy konfigurációs fájlhoz: a hub saját LAN-ja, az egyes ágak LAN-ja és a vándorló ügyfeleknek adott készlet. Az átfedésmentesség tartja egyszerűen minden mást, mert az átfedő tartományok az útválasztást a leghosszabb egyezés rejtvényévé teszik, amelyet semmilyen ügyfelenkénti konfiguráció nem javít meg. Ezután erősítse meg, melyik gép az egyes LAN-ok alapértelmezett átjárója, mert egy ági útválasztó, amely nem a saját LAN-ja átjárója, a távoli útvonalakat egészen máshol igényli telepítve. Végül rögzítse az egyes ágakat azonosító hitelesített neveket, mert ezek a nevek azok a kulcsok, amelyekkel az ügyfelenkénti fájlokat keresik.

Egy szemléltető terv távol tartja a készletet a három LAN-tól. Az öné más lesz, és az egyetlen szigorú szabály, hogy két tartomány ne fedje át egymást.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Mondja meg a hub kernelének, hol vannak az ágak

A hubnak áganként két információra van szüksége: egy kernelútvonalra, amely az előtagot az alagút-eszközbe küldi, és egy iroute bejegyzésre, amely megmondja az OpenVPN folyamatnak, melyik ügyfél birtokolja. A kernelútvonal önmagában eljuttatja a csomagokat az alagútba, és ott megáll, mert a démonnak még el kell döntenie, melyik fél kapja meg őket. Az iroute bejegyzés önmagában a kernelben hagyja ezeket a csomagokat követhető útvonal nélkül. Mindkét sor ahhoz a konfigurációhoz tartozik, amelyet a démon ténylegesen betölt, és ezt érdemes ellenőrizni, mielőtt bármi mást hibakeresne.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Kapcsolja ki az ügyfél-ügyfél forgalmat, amikor a kernelnek kell a kikényszerítési pontnak lennie. Ez a beállítás a felek közötti forgalmat a démonon belül továbbítja, ami kényelmes, és azt is jelenti, hogy a továbbítási szabályok soha nem látják a folyamot. Az alábbiak mindegyike feltételezi, hogy a kernel lát minden ágak közötti csomagot.

Adja meg minden ágnak a szükséges útvonalakat

Minden ágnak útvonalakra van szüksége a többi ág és a hub LAN-ja felé, a saját csatlakoztatott LAN-ja felé pedig nem. A távoli előtagokat a hubról tolja ki, ahelyett hogy minden útválasztóba beillesztené, így egy negyedik telephely később négy szerkesztés helyett egy új ügyfelenkénti fájlt jelent. Az ügyfelenkénti fájl a iroute sort is tartalmazza, amely a tulajdonjogot és a hirdetést ugyanazon a helyen tartja. Tegye a könyvtárat és fájljait olvashatóvá a kiszolgáló jogosultsági modellje szerint, különben a keresés üzenet nélkül meghiúsul.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Egy negyedik telephely ugyanezt a mintát követi: külön hitelesített név, birtokolt előtag, kernelútvonal a hubban, iroute bejegyzés, és hirdetések csak azoknak a telephelyeknek, amelyeknek engedélyezett az elérés.

Mindkét irányban tesztelje, mielőtt késznek nevezi

Engedélyezze az IPv4-továbbítást mindhárom útválasztón, majd erősítse meg, hogy a tűzfal mindkét irányban engedi a szándékolt folyamokat, mert az egyirányú teszt törött visszaúttal gyakrabban sikeres, mint bárki várná. A telephelyek között nincs szükség forrásfordításra, és éppen az eredeti forrás megőrzése teszi lehetővé, hogy minden ág a saját szabályzatát alkalmazza egy kérésre.

Teszteljen az egyik ág LAN-ján lévő hosztról egy másik szolgáltatására, majd fordítsa meg az irányt, majd teszteljen egy ágról a hub LAN-jára. Ez a három eredmény különböző bizonyíték, és egyik sem jelenti a másikat. Ha egy ági útválasztó nem a saját LAN-ja alapértelmezett átjárója, telepítse a távoli előtagokat a valódi átjáróra, és a készletet is vegye fel, amikor az alagút ügyfeleinek kapcsolatot kell indítaniuk abba a LAN-ba.

Rögzítse a tervet, az ügyfelenkénti fájlokat és a tűzfalszabályokat egyetlen dokumentumként, mert a következő telephely-bővítést ezekhez mérik.

A tervezés azért áll össze, mert minden rétegnek egy feladata van: a terv egyedivé teszi az előtagokat, a kernelútvonal mozgatja a csomagokat, a iroute megnevezi a tulajdonost, és a tűzfal dönti el, mi engedélyezett. Amikor valami elromlik, ez a lista egyben az ellenőrzés sorrendje is.