Tři druhy přepnutí OpenVPN v pfSense, tři mechanismy

„OpenVPN failover“ v pfSense zahrnuje nejméně tři nesouvisející návrhy a každý z nich vyžaduje jiný mechanismus. Udržet tunel živý přes záložní internetové připojení, znovu se připojit k jinému serveru a směrovat provoz LAN do jiného již zavedeného tunelu nejsou varianty jedné funkce. Vyberte poruchu, proti které se bráníte, dřív než postavíte skupinu bran. Skupina, která opraví jednu z nich, nedělá nic pro zbývající dvě.

Pojmenujte poruchu, než postavíte skupinu

Napište větu, kterou chcete mít během výpadku pravdivou. „Tunel se znovu připojí přes záložní WAN“ a „pobočka se stále dostane do aplikace přes druhý tunel“ jsou různé věty. Jen první se týká transportu.

Pak ji přiřaďte mechanismu. Ztráta místního WAN je problém volby rozhraní, mrtvý vzdálený koncový bod je problém seznamu připojení a nepoužitelná cesta uvnitř zavedeného tunelu je problém směrování a politiky.

Místní WAN: přesunout transport

Pro klienta OpenVPN v pfSense podporované uspořádání více WAN vybírá vhodnou skupinu bran jako rozhraní, ke kterému se klient váže. Právě to umožňuje vnějšímu připojení odejít přes záložní linku, když primární selže. Samo o sobě nemění, jak je směrován vnitřní provoz.

Serverová strana stejného návrhu je oddělená. Server OpenVPN, který má být dostupný na několika veřejných adresách, potřebuje posluchač a vstupní politiku pro každý z těchto záznamů, ne jen klienta, který umí vytáčet přes dvě linky. Jeden funkční veřejný záznam není důkazem, že druhý je nakonfigurovaný.

Pravidlo směrování podle politiky pro předávané pakety LAN není nastavení, které přesouvá lokálně vytvořené transportní připojení VPN. Jsou to dva různé lookupy a změna jednoho nemění druhý.

Vzdálený koncový bod: jiný server

Alternativní remote je funkce seznamu připojení. Klient zkusí další záznam, když ten současný neodpovídá, což je užitečné, když je dole konkrétní hostitel, a ne když je dole vaše vlastní odchozí linka. Obě poruchy vypadají z uživatelského stolu podobně a vyžadují různé opravy.

Každý kandidát musí být skutečná náhrada: kompatibilní autentizace, kompatibilní klientská politika a přístup ke stejným privátním zdrojům. Druhé jméno hostitele, které se překládá na stejnou nefunkční infrastrukturu, není záloha. Server bez požadované trasy také ne, ať jeho handshake vypadá jakkoli zdravě.

Tento mechanismus také nezpůsobí, aby dva tunely předávaly provoz najednou. Nahrazuje jedno připojení druhým, postupně, a mezera mezi nimi je vidět pro všechno, co běželo.

Cesta tunelu: vybrat jiný východ

Když už jsou dva tunely nahoru a provoz má používat ten zdravější, mechanismem je přiřazené rozhraní VPN s vlastní branou plus výslovné pravidlo politiky, které tam posílá správný provoz. Skupina bran nad těmito přiřazenými rozhraními může vyjádřit prioritu a sledování.

Ten návrh je o výběru, ne o obnově. Přesun nových připojení do druhého tunelu nic neříká o relacích už zavedených na prvním ani o tom, zda protější strana přijme novou zdrojovou adresu. Považovat to za mechanismus obnovy je způsob, jak nastavit příliš vysoká očekávání.

Pokud je požadavkem, aby stávající relace přežily, řekněte to výslovně. Většina implementací nemigruje živý tok mezi tunely a navrhování, jako by to dělaly, dává přepnutí, které vypadá správně na schématu a v praxi zahodí každé otevřené připojení.

Monitory, NAT a pravidlo fail-closed

Monitor by měl testovat něco, co má tunel dodávat. Cíl, který odpovídá od protějšku tunelu, ale ne z aplikační sítě za ním, ohlásí zdravý stav, zatímco uživatelé nic nevidí. Nedosažitelný diagnostický cíl ohlásí mrtvý stav, zatímco cesta je v pořádku. Vyberte adresu záměrně a potvrďte, že je dosažitelná jen zamýšleným tunelem.

Zkontrolujte odchozí NAT pro oba východy. Fungující překlad na primárním nepopisuje zdrojovou adresu zálohy a vzdálená privátní síť potřebuje zpáteční trasu, která odpovídá zdroji, jenž prezentujete. Překlad správný na jedné cestě může být na druhé tiše špatný.

Pak rozhodněte, co se stane s provozem, který nikdy nesmí použít WAN. pfSense má definované chování pro pravidla, jejichž vybraná brána je dole, a pozdější široké propouštěcí pravidlo nebo výchozí trasa může váš záměr zrušit. Zapište zablokovaný výsledek jako požadavek a ověřte ho tím, že cestu vypnete.

Testujte ztrátu a obnovu odděleně, s provozem, který smíte generovat, a sledujte tři věci najednou: WAN, který nese vnější připojení, tunel, který nese požadavek aplikace, a cestu, kterou se vydá odpověď. Pár zelených indikátorů bran není jedna z těch tří. Průvodce Netgate pro více WAN popisuje vazbu transportu a exportované klientské alternativy, na kterých to závisí.