Tri druhy prepnutia OpenVPN v pfSense, tri mechanizmy

„OpenVPN failover“ v pfSense zahŕňa najmenej tri nesúvisiace návrhy a každý z nich vyžaduje iný mechanizmus. Udržať tunel živý cez záložné internetové pripojenie, znovu sa pripojiť k inému serveru a smerovať prevádzku LAN do iného už zavedeného tunela nie sú varianty jednej funkcie. Vyberte poruchu, proti ktorej sa bránite, skôr než postavíte skupinu brán. Skupina, ktorá opraví jednu z nich, nerobí nič pre zvyšné dve.

Pomenujte poruchu, kým postavíte skupinu

Napíšte vetu, ktorú chcete mať počas výpadku pravdivú. „Tunel sa znovu pripojí cez záložný WAN“ a „pobočka sa stále dostane do aplikácie cez druhý tunel“ sú rôzne vety. Len prvá sa týka transportu.

Potom ju priraďte mechanizmu. Strata miestneho WAN je problém voľby rozhrania, mŕtvy vzdialený koncový bod je problém zoznamu pripojení a nepoužiteľná cesta vnútri zavedeného tunela je problém smerovania a politiky.

Miestny WAN: presunúť transport

Pre klienta OpenVPN v pfSense podporované usporiadanie viacerých WAN vyberá vhodnú skupinu brán ako rozhranie, ku ktorému sa klient viaže. Práve to umožňuje vonkajšiemu pripojeniu odísť cez záložnú linku, keď primárna zlyhá. Samo o sebe nemení, ako je smerovaná vnútorná prevádzka.

Serverová strana rovnakého návrhu je oddelená. Server OpenVPN, ktorý má byť dostupný na viacerých verejných adresách, potrebuje poslucháča a vstupnú politiku pre každý z týchto záznamov, nie iba klienta, ktorý vie vytočiť cez dve linky. Jeden funkčný verejný záznam nie je dôkazom, že druhý je nakonfigurovaný.

Pravidlo smerovania podľa politiky pre preposielané pakety LAN nie je nastavenie, ktoré presúva lokálne vytvorené transportné pripojenie VPN. Sú to dva rôzne lookupy a zmena jedného nemení druhý.

Vzdialený koncový bod: iný server

Alternatívny remote je funkcia zoznamu pripojení. Klient vyskúša ďalší záznam, keď ten súčasný neodpovedá, čo je užitočné, keď je dole konkrétny hostiteľ, a nie keď je dole vaša vlastná odchádzajúca linka. Obe poruchy vyzerajú z používateľského stola podobne a vyžadujú rôzne opravy.

Každý kandidát musí byť skutočná náhrada: kompatibilná autentifikácia, kompatibilná klientska politika a prístup k tým istým privátnym zdrojom. Druhé meno hostiteľa, ktoré sa prekladá na tú istú nefunkčnú infraštruktúru, nie je záloha. Server bez požadovanej trasy tiež nie, nech jeho handshake vyzerá akokoľvek zdravo.

Tento mechanizmus tiež nespôsobí, aby dva tunely preposielali naraz. Nahrádza jedno pripojenie druhým, postupne, a medzera medzi nimi je viditeľná pre všetko, čo bežalo.

Cesta tunela: vybrať iný východ

Keď už sú dva tunely hore a prevádzka má používať ten zdravší, mechanizmom je priradené rozhranie VPN s vlastnou bránou plus výslovné pravidlo politiky, ktoré tam posiela správnu prevádzku. Skupina brán nad týmito priradenými rozhraniami môže vyjadriť prioritu a sledovanie.

Ten návrh je o výbere, nie o obnove. Presun nových pripojení do druhého tunela nič nehovorí o reláciách už zavedených na prvom ani o tom, či protistrana prijme novú zdrojovú adresu. Považovať to za mechanizmus obnovy je spôsob, ako nastaviť príliš vysoké očakávania.

Ak je požiadavkou, aby existujúce relácie prežili, povedzte to výslovne. Väčšina implementácií nemigruje živý tok medzi tunelmi a navrhovanie, akoby to robili, dáva prepnutie, ktoré vyzerá správne na schéme a v praxi zahodí každé otvorené pripojenie.

Monitory, NAT a pravidlo fail-closed

Monitor by mal testovať niečo, čo má tunel dodávať. Cieľ, ktorý odpovedá od partnera tunela, ale nie z aplikačnej siete za ním, ohlási zdravý stav, kým používatelia nič nevidia. Nedosiahnuteľný diagnostický cieľ ohlási mŕtvy stav, kým cesta je v poriadku. Vyberte adresu zámerne a potvrďte, že je dosiahnuteľná len zamýšľaným tunelom.

Skontrolujte odchádzajúci NAT pre oba východy. Fungujúci preklad na primárnom neopisuje zdrojovú adresu zálohy a vzdialená privátna sieť potrebuje spiatočnú trasu, ktorá zodpovedá zdroju, ktorý prezentujete. Preklad správny na jednej ceste môže byť na druhej ticho nesprávny.

Potom rozhodnite, čo sa stane s prevádzkou, ktorá nikdy nesmie použiť WAN. pfSense má definované správanie pre pravidlá, ktorých vybraná brána je dole, a neskoršie široké prepúšťacie pravidlo alebo predvolená trasa môže váš zámer zrušiť. Zapíšte zablokovaný výsledok ako požiadavku a overte ho vypnutím cesty.

Testujte stratu a obnovu oddelene, s prevádzkou, ktorú smiete generovať, a sledujte tri veci naraz: WAN, ktorý nesie vonkajšie pripojenie, tunel, ktorý nesie požiadavku aplikácie, a cestu, ktorou sa vydá odpoveď. Dvojica zelených indikátorov brán nie je jedna z tých troch. Príručka Netgate pre viac WAN opisuje väzbu transportu a exportované klientske alternatívy, na ktorých to závisí.