Két OpenVPN-kliens egyetlen Linux-átjárón: ossza fel a szabályzatot

Két OpenVPN-démon is jelenthet sikeres alagutat, miközben az átjáró minden klienst ugyanazon keresztül küld. A kézfogásban semmi nem dönti el, melyik alagutat használja egy kliens; a kernel dönti el, csomagról csomagra, végighaladva a szabályzat szabályain, majd azon a táblán, amelyet az egyes szabályok megneveznek. Ha így nézi, a konfiguráció már nem OpenVPN-beállításokról szól, hanem két tulajdonossal rendelkező útválasztási mátrixszá válik.

A kernel dönt, nem a démon

Egy továbbított csomag a LAN-interfészen érkezik, és az útválasztó kód prioritási sorrendben értékeli a szabálylistát. Az első szabály, amelynek szelektorja illeszkedik, megnevez egy táblát, és annak a táblának az útvonalai választják ki a kimeneti eszközt. Ha a táblában nincs illeszkedő útvonal, a keresés a következő szabályra lép tovább, és éppen ez a részlet teszi, hogy egy félkész beállítás halkan, nem pedig hangosan hiúsul meg.

Az alagút folyamatának nincs beleszólása ebbe a bejárásba. Létrehoz egy interfészt, és telepíthet útvonalakat, de hogy egy adott kliens csomagja belép-e abba az interfészbe, teljes mértékben attól a táblától függ, amelyhez küldték. Ezért két azonos importált útvonalú alagút verseng, és az utolsó író nyer mindenki számára. Ezért nézhet ki kiegyensúlyozottnak egy beállítás a konfigurációs fájlokban, miközben mégis minden klienst egyetlen démonon keresztül küld.

Adjon minden példánynak saját erőforrás-készletet

Kezdje a nevekkel, mert az újrahasznált nevek azok, amelyeken a két példány véletlenül megosztja az állapotot. Rendeljen külön alagúteszközöket, külön konfigurációs fájlokat, külön hitelesítő adatokat és külön szolgáltatásegységeket. Jegyezze fel az egyes példányok külső végpontját és alagút-címét ugyanabba a táblába, mint a szabályzat mátrixát, hogy egy későbbi változtatásnak egyetlen helye legyen, ahol megnézheti.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull távol tartja a szerver által tolt útvonalakat a helyi táblától, és pontosan ezt akarja, amikor a szabályzati tábláknak kifejezettnek kell lenniük. Érdemes a kézikönyvben ellenőrizni, nem feltételezni, hogy egy adott szerver tolj-e redirect-gateway beállítást is, és hogy az ügyfélverziója támogatja-e a szűrőformát.

Írja meg a mátrixot: forrás, tábla, eszköz

Minden klienscsoporthoz adjon hozzá egy szabályt, amely forráscím alapján választ táblát, majd tegye a szándékolt útvonalat abba a táblába:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

A táblának kellenek azok a célútvonalak, amelyekkel a csoportnak rendelkeznie kell, valamint mindazok a helyi vagy kezelési kivételek, amelyek az átjárót használhatóvá teszik. Az a tábla, amely csak alapértelmezett útvonalat tartalmaz, teljes alagút szabályzat az adott csoport számára, ami lehet, hogy éppen helyes, de döntésnek kell lennie, nem kihagyásnak.

Az alagút saját szállítása nincs klienscsoportban

Az egyes démonok titkosított csomagjai magán az átjárón keletkeznek, a külső partner címére. Az a szabály, amely csak egy kliens forrás-előtagjára illeszkedik, békén hagyja ezeket a csomagokat, ezért a forrásra korlátozott szabályok biztonságosabbak, mint a mindenre illeszkedő szabályok. Egy szelektor nélküli szabály elfoghatja az alagút saját szállítását, és visszaküldheti egy alagúton, és akkor a kapcsolat olyan módon hiúsul meg, amely szolgáltatói problémának látszik.

Tartsa a helyi kezelési munkamenetet és az alsó réteg útvonalát kifejezetten a szabályzati táblákon kívül. Írja fel ezeket a kivételeket a mátrix mellé; a tervezés részét képezik, nem olyan kerülőút, amelyet egy incidens során újra fel kell fedezni.

Az útvonal kiválasztása nem engedélyezi azt

A továbbítási engedély egy második döntés, amely később születik meg az úton. Egy tűzfalszabály, amely elfogadja a második alagúton kilépő csomagokat, nem készteti az útválasztó kódot arra, hogy azt válassza, és egy helyes tábla nem ad továbbítási engedélyt. Mindkettőnek léteznie kell, és egy teszt, amely csak az egyiket bizonyítja, félrevezeti a másikkal kapcsolatban. Amikor az egyik csoport működik, a másik nem, vizsgálja meg ezt a két lépést külön, ahelyett hogy újraírná a táblákat.

A forrásfordítás egy harmadik döntés, és azt a forráscsoportra és arra az alagúteszközre kell korlátozni, amely ténylegesen szállítja. Adjon hozzá egy dedikált láncot a két példányhoz ahelyett, hogy kiürítené a postrouting láncot, mert a nem kapcsolódó szolgáltatásoknak lehetnek bejegyzései ott, és egy ürítés csendesen eltávolítja azokat.

Mi történik, ha egy alagút kiesik

A hibaviselkedést előre döntse el. Amikor egy alagúttábla elveszíti az útvonalát, a keresés átesik a következő szabályra, és a csoport forgalma hiba nélkül folytatódik a másik alagúton vagy a szokásos felső kapcsolaton. Ha ez nem elfogadható, adjon hozzá egy lezáró szabályt alacsonyabb prioritási számmal, amely elérhetetlen eredményt ad vissza arra a forrásra, hogy a veszteség látható legyen, ne pedig elnyelve.

Küldjön friss kérést minden forráscsoportból, és jegyezzen fel négy tényt: a kiválasztott táblát, a kimeneti eszközt, a lefordított forrást, és hogy a válasz ugyanazon az úton jött-e vissza. Utána engedjen le egy alagutat, és ismételje meg. Két TUN-eszköz egy interfészlistában bizonyítja, hogy mindkét démon elindult; semmit sem mond arról, melyiket használta egy adott kliens. A második futás, egy alagút hiányában, az, amely megmutatja, hogy a tartalék szabálya azt teszi-e, amit szándékozott.