Tres tipos de failover de OpenVPN en pfSense, tres mecanismos

„OpenVPN failover“ en pfSense abrangue polo menos tres deseños non relacionados, e cada un precisa un mecanismo distinto. Manter vivo un túnel a través dunha conexión de internet de reserva, reconectar a outro servidor e dirixir o tráfico LAN a outro túnel xa establecido non son variantes dunha mesma función. Escolla o fallo contra o que se protexe antes de construír un grupo de pasarelas. O grupo que corrixe un deles non fai nada polos outros dous.

Nomee o fallo antes de construír un grupo

Escriba a frase que quere que sexa certa durante unha caída. „O túnel reconecta polo WAN de reserva“ e „a sucursal segue chegando á aplicación polo outro túnel“ son frases distintas. Só a primeira trata do transporte.

Despois relaciónea cun mecanismo. A perda do WAN local é un problema de elección de interface, un punto final remoto morto é un problema de lista de conexións, e unha ruta inutilizable dentro dun túnel establecido é un problema de encamiñamento e política.

WAN local: mover o transporte

Para un cliente OpenVPN de pfSense, a disposición multi-WAN admitida selecciona un grupo de pasarelas axeitado como a interface á que se liga o cliente. Isto é o que permite á conexión exterior saír polo enlace de reserva cando falla a principal. Por si só non cambia como se encamiña o tráfico interior.

O lado do servidor do mesmo deseño é separado. Un servidor OpenVPN que debe ser accesible por varios enderezos públicos precisa un escoitador e unha política de entrada para cada unha desas entradas, non só un cliente capaz de marcar por dous enlaces. Unha entrada pública que funciona non é proba de que a segunda estea configurada.

Unha regra de encamiñamento baseada en política para paquetes LAN reenviados non é o axuste que move unha conexión de transporte VPN xerada localmente. Son dúas buscas distintas, e cambiar unha non cambia a outra.

Punto final remoto: outro servidor

Un remote alternativo é unha función da lista de conexións. O cliente proba a entrada seguinte cando a actual non responde, o que é útil cando un host concreto está caído e non cando o está o seu propio enlace ascendente. Os dous fallos parecen iguais desde o escritorio dun usuario e precisan correccións distintas.

Cada candidato ten que ser un substituto real: autenticación compatible, política de cliente compatible e acceso aos mesmos recursos privados. Un segundo nome de host que resolve á mesma infraestrutura avariada non é reserva. Un servidor sen a ruta necesaria tampouco o é, por moi san que pareza o seu aperta de mans.

Este mecanismo tampouco fai que dous túneles transmitan á vez. Substitúe unha conexión por outra, secuencialmente, e o oco entre elas é visible para todo o que estaba a correr.

Ruta do túnel: escoller outra saída

Cando dous túneles xa están levantados e o tráfico debe usar o máis san, o mecanismo é unha interface VPN asignada coa súa propia pasarela, máis unha regra de política explícita que envía o tráfico correcto cara a alí. Un grupo de pasarelas sobre esas interfaces asignadas pode expresar prioridade e monitorización.

Ese deseño trata de selección, non de recuperación. Mover conexións novas ao segundo túnel non di nada sobre as sesións xa establecidas no primeiro, nin sobre se o lado remoto aceptará o novo enderezo de orixe. Tratalo como mecanismo de recuperación é a forma de fixar expectativas demasiado altas.

Se o requisito é que as sesións existentes sobrevivan, dígao explicitamente. A maioría das implementacións non migran un fluxo vivo entre túneles, e deseñar coma se o fixeran produce un failover que parece correcto nun diagrama e na práctica deixa caer todas as conexións abertas.

Monitores, NAT e a regra fail-closed

Un monitor debería probar algo que o túnel debe entregar. Un obxectivo que responde desde o par do túnel pero non desde a rede de aplicacións detrás del informará san mentres os usuarios non ven nada. Un obxectivo de diagnóstico inalcanzable informará morto mentres a ruta está ben. Escolla o enderezo deliberadamente e confirme que só é alcanzable polo túnel previsto.

Revise o NAT de saída para ambas as saídas. Unha tradución que funciona na principal non describe o enderezo de orixe da reserva, e a rede privada remota necesita unha ruta de retorno que coincida coa orixe que presenta. Unha tradución correcta nunha ruta pode estar silenciosamente mal na outra.

Despois decida que pasa co tráfico que nunca debe usar o WAN. pfSense ten un comportamento definido para as regras cuxa pasarela seleccionada está caída, e unha regra ampla de paso posterior ou unha ruta por defecto poden desfacer a súa intención. Anote o resultado bloqueado como requisito e verifíqueo baixando a ruta.

Probe a perda e a recuperación por separado, con tráfico que estea autorizado a xerar, e observe tres cousas á vez: o WAN que leva a conexión exterior, o túnel que leva a petición da aplicación e a ruta que toma a resposta. Un par de indicadores de pasarela en verde non é unha desas tres. A guía multi-WAN de Netgate describe a vinculación do transporte e as alternativas de cliente exportadas das que depende isto.