Tres tipus de failover d'OpenVPN a pfSense, tres mecanismes

„OpenVPN failover“ a pfSense abasta com a mínim tres dissenys no relacionats, i cadascun necessita un mecanisme diferent. Mantenir viu un túnel a través d'un enllaç d'internet de reserva, reconnectar-se a un altre servidor i dirigir el trànsit LAN cap a un altre túnel ja establert no són variants d'una mateixa funció. Trieu la fallada contra la qual us defenseu abans de construir un grup de passarel·les. El grup que arregla una d'elles no fa res per les altres dues.

Nomena la fallada abans de construir un grup

Escriviu la frase que voleu que sigui certa durant una caiguda. „El túnel es reconnecta pel WAN de reserva“ i „la sucursal continua arribant a l'aplicació per l'altre túnel“ són frases diferents. Només la primera tracta del transport.

Després relacioneu-la amb un mecanisme. La pèrdua del WAN local és un problema de selecció d'interfície, un extrem remot mort és un problema de llista de connexions, i un camí inutilitzable dins d'un túnel establert és un problema d'encaminament i política.

WAN local: moure el transport

Per a un client OpenVPN de pfSense, la disposició multi-WAN admesa selecciona un grup de passarel·les adequat com la interfície a la qual s'enllaça el client. Això és el que permet a la connexió exterior sortir per l'enllaç de reserva quan la primària falla. Per si sol no canvia com s'encamina el trànsit interior.

El costat del servidor del mateix disseny és separat. Un servidor OpenVPN que ha de ser accessible per diverses adreces públiques necessita un oient i una política d'entrada per a cadascuna d'aquestes entrades, no només un client capaç de marcar per dos enllaços. Una entrada pública que funciona no és prova que la segona estigui configurada.

Una regla d'encaminament basada en política per als paquets LAN reenviats no és el paràmetre que mou una connexió de transport VPN generada localment. Són dues cerques diferents, i canviar-ne una no canvia l'altra.

Extrem remot: un altre servidor

Un remote alternatiu és una funció de la llista de connexions. El client prova l'entrada següent quan l'actual no respon, cosa que és útil quan un amfitrió concret ha caigut i no quan ho ha fet el vostre propi enllaç ascendent. Les dues fallades semblen iguals des de l'escriptori d'un usuari i necessiten correccions diferents.

Cada candidat ha de ser un substitut real: autenticació compatible, política de client compatible i accés als mateixos recursos privats. Un segon nom d'amfitrió que resol a la mateixa infraestructura avariada no és reserva. Un servidor sense la ruta necessària tampoc ho és, per sa que sembli la seva encaixada de mans.

Aquest mecanisme tampoc fa que dos túnels transmetin alhora. Substitueix una connexió per una altra, seqüencialment, i el buit entre elles és visible per a tot el que s'estava executant.

Camí del túnel: triar una altra sortida

Quan ja hi ha dos túnels aixecats i el trànsit ha d'usar el més sa, el mecanisme és una interfície VPN assignada amb la seva pròpia passarel·la, més una regla de política explícita que hi envia el trànsit correcte. Un grup de passarel·les sobre aquestes interfícies assignades pot expressar prioritat i monitorització.

Aquest disseny tracta de selecció, no de recuperació. Moure connexions noves al segon túnel no diu res sobre les sessions ja establertes al primer, ni sobre si el costat remot acceptarà la nova adreça d'origen. Tractar-ho com a mecanisme de recuperació és la manera de fixar expectatives massa altes.

Si el requisit és que les sessions existents sobrevisquin, digueu-ho explícitament. La majoria d'implementacions no migren un flux viu entre túnels, i dissenyar com si ho fessin produeix un failover que sembla correcte en un diagrama i a la pràctica deixa caure totes les connexions obertes.

Monitors, NAT i la regla fail-closed

Un monitor hauria de provar alguna cosa que el túnel ha de lliurar. Un objectiu que respon des del parell del túnel però no des de la xarxa d'aplicacions del darrere informarà sa mentre els usuaris no veuen res. Un objectiu de diagnòstic inabastable informarà mort mentre el camí està bé. Trieu l'adreça deliberadament i confirmeu que només és abastable pel túnel previst.

Reviseu el NAT de sortida per a les dues sortides. Una traducció que funciona a la primària no descriu l'adreça d'origen de la reserva, i la xarxa privada remota necessita una ruta de retorn que coincideixi amb l'origen que presenteu. Una traducció correcta en un camí pot estar silenciosament malament en l'altre.

Després decidiu què passa amb el trànsit que no ha d'usar mai el WAN. pfSense té un comportament definit per a les regles la passarel·la seleccionada de les quals ha caigut, i una regla àmplia de pas posterior o una ruta per defecte poden desfer la vostra intenció. Anoteu el resultat bloquejat com a requisit i verifiqueu-lo baixant el camí.

Proveu la pèrdua i la recuperació per separat, amb trànsit que estigueu autoritzat a generar, i observeu tres coses alhora: el WAN que porta la connexió exterior, el túnel que porta la petició de l'aplicació i el camí que pren la resposta. Una parella d'indicadors de passarel·la en verd no és una d'aquestes tres. La guia multi-WAN de Netgate descriu la vinculació del transport i les alternatives de client exportades de què depèn això.