Trei tipuri de failover OpenVPN pe pfSense, trei mecanisme

„OpenVPN failover” pe pfSense acoperă cel puțin trei proiecte fără legătură între ele, iar fiecare cere alt mecanism. Menținerea unui tunel viu printr-o legătură de internet de rezervă, reconectarea la alt server și dirijarea traficului LAN într-un alt tunel deja stabilit nu sunt variante ale aceleiași funcții. Alegeți defecțiunea împotriva căreia vă apărați înainte de a construi un grup de gateway-uri. Un grup care remediază una dintre ele nu face nimic pentru celelalte două.

Numiți defecțiunea înainte de a construi un grup

Scrieți propoziția care vreți să fie adevărată în timpul unei pene. „Tunelul se reconectează prin WAN-ul de rezervă” și „sucursala ajunge în continuare la aplicație prin celălalt tunel” sunt propoziții diferite. Doar prima privește transportul.

Apoi asociați-o unui mecanism. Pierderea WAN-ului local este o problemă de alegere a interfeței, un capăt îndepărtat mort este o problemă de listă de conexiuni, iar o cale inutilizabilă în interiorul unui tunel stabilit este o problemă de rutare și politică.

WAN local: mutați transportul

Pentru un client OpenVPN pfSense, aranjamentul multi-WAN acceptat selectează un grup de gateway-uri potrivit ca interfață la care se leagă clientul. Aceasta este ce permite conexiunii exterioare să iasă prin legătura de rezervă când prima cade. În sine nu schimbă modul în care este rutat traficul interior.

Partea de server a aceluiași proiect este separată. Un server OpenVPN care trebuie să fie accesibil prin mai multe adrese publice are nevoie de un ascultător și de o politică de intrare pentru fiecare dintre aceste intrări, nu doar de un client care poate suna prin două legături. O intrare publică funcțională nu este dovada că a doua este configurată.

O regulă de rutare bazată pe politică pentru pachetele LAN redirecționate nu este setarea care mută o conexiune de transport VPN generată local. Sunt două căutări diferite, iar schimbarea uneia nu o schimbă pe cealaltă.

Capăt îndepărtat: alt server

Un remote alternativ este o funcție a listei de conexiuni. Clientul încearcă următoarea intrare când cea curentă nu răspunde, ceea ce e util când un anumit host este căzut, nu când este căzută propria legătură de acces. Cele două defecțiuni arată similar de la biroul unui utilizator și cer remedieri diferite.

Fiecare candidat trebuie să fie un substituent real: autentificare compatibilă, politică de client compatibilă și acces la aceleași resurse private. Un al doilea nume de host care se rezolvă la aceeași infrastructură defectă nu este rezervă. Un server fără ruta necesară nu este nici el, oricât de sănătos ar arăta handshake-ul său.

Acest mecanism nici nu face două tuneluri să transmită simultan. Înlocuiește o conexiune cu alta, secvențial, iar golul dintre ele este vizibil pentru tot ce rula.

Calea tunelului: alegeți altă ieșire

Când două tuneluri sunt deja ridicate și traficul trebuie să îl folosească pe cel mai sănătos, mecanismul este o interfață VPN alocată cu propriul gateway, plus o regulă de politică explicită care trimite traficul potrivit acolo. Un grup de gateway-uri peste aceste interfețe alocate poate exprima prioritate și monitorizare.

Acest proiect este despre selecție, nu despre recuperare. Mutarea conexiunilor noi pe al doilea tunel nu spune nimic despre sesiunile deja stabilite pe primul și nimic despre dacă partea îndepărtată va accepta noua adresă sursă. Tratarea lui ca mecanism de recuperare este modul de a fixa așteptări prea mari.

Dacă cerința este ca sesiunile existente să supraviețuiască, spuneți-o explicit. Majoritatea implementărilor nu migrează un flux viu între tuneluri, iar proiectarea ca și cum ar face-o produce un failover care arată corect pe o diagramă și în practică renunță la fiecare conexiune deschisă.

Monitoare, NAT și regula fail-closed

Un monitor ar trebui să testeze ceva ce tunelul trebuie să livreze. O țintă care răspunde de la partenerul tunelului, dar nu din rețeaua de aplicații de dincolo de el, va raporta stare sănătoasă în timp ce utilizatorii nu văd nimic. O țintă de diagnostic inaccesibilă va raporta stare moartă în timp ce calea este în regulă. Alegeți adresa deliberat și confirmați că este accesibilă doar prin tunelul prevăzut.

Verificați NAT-ul de ieșire pentru ambele ieșiri. O traducere funcțională pe primarul nu descrie adresa sursă a rezervei, iar rețeaua privată îndepărtată are nevoie de o rută de întoarcere care să corespundă sursei pe care o prezentați. O traducere corectă pe o cale poate fi tăcut greșită pe cealaltă.

Apoi decideți ce se întâmplă cu traficul care nu trebuie să folosească niciodată WAN-ul. pfSense are un comportament definit pentru regulile al căror gateway selectat este căzut, iar o regulă largă de permisiune ulterioară sau o rută implicită pot anula intenția dumneavoastră. Notați rezultatul blocat ca cerință și verificați-l scoțând calea.

Testați pierderea și recuperarea separat, cu trafic pe care sunteți autorizat să îl generați, și urmăriți trei lucruri deodată: WAN-ul care poartă conexiunea exterioară, tunelul care poartă cererea aplicației și calea pe care o ia răspunsul. O pereche de indicatori verzi de gateway nu este unul dintre acele trei. Ghidul Netgate pentru mai multe WAN-uri descrie legarea transportului și alternativele de client exportate de care depinde acest lucru.