Háromféle OpenVPN-feladatátvétel pfSense-en, három mechanizmus

Az „OpenVPN failover” a pfSense-en legalább három, egymástól független tervet takar, és mindegyik más mechanizmust igényel. Egy alagutat életben tartani egy tartalék internetkapcsolaton át, újracsatlakozni egy másik kiszolgálóhoz, és a LAN-forgalmat egy másik, már felállított alagútba terelni nem egyetlen funkció változatai. Válassza ki a hibát, amely ellen védekezik, mielőtt átjárócsoportot épít. Az a csoport, amelyik az egyiket megoldja, a másik kettőért semmit sem tesz.

Nevezze meg a hibát, mielőtt csoportot épít

Írja le azt a mondatot, amelyet egy kiesés alatt igaznak szeretne látni. „Az alagút a tartalék WAN-en keresztül újracsatlakozik” és „a fióktelep továbbra is eléri az alkalmazást a másik alagúton át” különböző mondatok. Csak az első szól a szállításról.

Ezután rendelje hozzá egy mechanizmushoz. A helyi WAN elvesztése interfészválasztási probléma, egy halott távoli végpont kapcsolatlista-probléma, egy használhatatlan útvonal egy felállított alagúton belül pedig útválasztási és házirend-probléma.

Helyi WAN: a szállítás áthelyezése

Egy pfSense OpenVPN-kliens esetében a támogatott több-WAN elrendezés megfelelő átjárócsoportot választ ki mint az interfészt, amelyhez a kliens kötődik. Ez az, ami a külső kapcsolatnak lehetővé teszi, hogy a tartalék linken keresztül lépjen ki, amikor az elsődleges meghibásodik. Önmagában nem változtatja meg, hogyan van irányítva a belső forgalom.

Ugyanennek a tervnek a kiszolgálóoldala különálló. Egy OpenVPN-kiszolgálónak, amelynek több nyilvános címen kell elérhetőnek lennie, minden ilyen bejegyzéshez figyelőre és bejövő házirendre van szüksége, nem csak egy kliensre, amely két linken át tud tárcsázni. Egy működő nyilvános bejegyzés nem bizonyítja, hogy a második be van állítva.

A továbbított LAN-csomagok házirendalapú útválasztási szabálya nem az a beállítás, amely egy helyben létrehozott VPN-szállítási kapcsolatot áthelyez. Ez két különböző keresés, és az egyik megváltoztatása nem változtatja meg a másikat.

Távoli végpont: másik kiszolgáló

Az alternatív remote a kapcsolatlista funkciója. A kliens a következő bejegyzést próbálja, amikor az aktuális nem válaszol, ami akkor hasznos, ha egy adott hoszt esett ki, és nem akkor, ha a saját felfelé irányuló linkje. A két hiba a felhasználó asztaláról hasonlónak látszik, és különböző javításokat igényel.

Minden jelöltnek valódi helyettesítőnek kell lennie: kompatibilis hitelesítés, kompatibilis kliensházirend és hozzáférés ugyanazokhoz a privát erőforrásokhoz. Egy második hosztnév, amely ugyanarra a meghibásodott infrastruktúrára oldódik fel, nem tartalék. Egy kiszolgáló a szükséges útvonal nélkül szintén nem az, akármilyen egészségesnek látszik a kézfogása.

Ez a mechanizmus sem teszi lehetővé, hogy két alagút egyszerre továbbítson. Egymás után cseréli le az egyik kapcsolatot a másikra, és a köztük lévő rés minden számára látható, ami futott.

Alagútútvonal: másik kijárat választása

Amikor két alagút már áll, és a forgalomnak az egészségesebbet kell használnia, a mechanizmus egy hozzárendelt VPN-interfész saját átjáróval, plusz egy kifejezett házirendszabály, amely a megfelelő forgalmat oda küldi. Az ezen hozzárendelt interfészek fölötti átjárócsoport kifejezheti a prioritást és a felügyeletet.

Ez a terv a kiválasztásról szól, nem a helyreállításról. Az új kapcsolatok áthelyezése a második alagútra semmit sem mond az elsőn már felállított munkamenetekről, és arról sem, hogy a túloldal elfogadja-e az új forrás címet. Helyreállítási mechanizmusként kezelni azt jelenti, hogy túl magasra tesszük az elvárásokat.

Ha az a követelmény, hogy a meglévő munkamenetek életben maradjanak, mondja ki egyértelműen. A legtöbb megvalósítás nem telepít át élő folyamot alagutak között, és ha úgy tervezünk, mintha mégis megtennék, olyan feladatátvételt kapunk, amely a diagramon helyesnek látszik, a gyakorlatban pedig minden nyitott kapcsolatot eldob.

Monitorok, NAT és a fail-closed szabály

Egy monitornak azt kellene tesztelnie, amit az alagútnak szállítania kell. Egy célpont, amely az alagút partnerétől válaszol, de a mögötte lévő alkalmazáshálózatból nem, egészségesnek jelent, miközben a felhasználók semmit sem látnak. Egy elérhetetlen diagnosztikai célpont halottnak jelent, miközben az útvonal rendben van. Válassza ki a címet szándékosan, és erősítse meg, hogy csak a tervezett alagúton át érhető el.

Ellenőrizze a kimenő NAT-ot mindkét kijáratnál. Az elsődlegesen működő fordítás nem írja le a tartalék forráscímét, és a távoli privát hálózatnak olyan visszatérési útvonalra van szüksége, amely megfelel annak a forrásnak, amelyet bemutat. Az egyik útvonalon helyes fordítás a másikon csendesen hibás lehet.

Ezután döntse el, mi történik a forgalommal, amely soha nem használhatja a WAN-t. A pfSense-nek meghatározott viselkedése van azokra a szabályokra, amelyek kiválasztott átjárója kiesett, és egy későbbi széles engedélyező szabály vagy egy alapértelmezett útvonal felülírhatja a szándékát. Írja le a blokkolt eredményt követelményként, majd igazolja úgy, hogy leviszi az útvonalat.

Tesztelje külön a veszteséget és a helyreállítást, olyan forgalommal, amelyet Ön jogosult előállítani, és figyeljen három dolgot egyszerre: a WAN-t, amely a külső kapcsolatot viszi, az alagutat, amely az alkalmazáskérést viszi, és az útvonalat, amelyet a válasz vesz. Egy pár zöld átjárójelző nem tartozik ahhoz a háromhoz. A Netgate több-WAN útmutatója leírja a szállítási kötést és az exportált kliensalternatívákat, amelyeken ez alapul.