Tres tipos de conmutación por error de OpenVPN en pfSense, tres mecanismos

«Failover de OpenVPN» en pfSense abarca al menos tres diseños no relacionados, y cada uno necesita un mecanismo distinto. Mantener un túnel vivo a través de un enlace de internet de respaldo, reconectarse a otro servidor y dirigir el tráfico LAN hacia otro túnel ya establecido no son variantes de una misma función. Elija el fallo contra el que se está protegiendo antes de construir un grupo de puertas de enlace. El grupo que arregla uno de ellos no hace nada por los otros dos.

Nombre el fallo antes de construir un grupo

Escriba la frase que quiere que sea cierta durante una caída. «El túnel se reconecta por el WAN de respaldo» y «la sucursal sigue llegando a la aplicación por el otro túnel» son frases distintas. Solo la primera trata del transporte.

Después relaciónela con un mecanismo. La pérdida del WAN local es un problema de selección de interfaz, un extremo remoto muerto es un problema de lista de conexiones, y una ruta inutilizable dentro de un túnel establecido es un problema de enrutamiento y política.

WAN local: mover el transporte

Para un cliente OpenVPN de pfSense, la disposición multi-WAN admitida selecciona un grupo de puertas de enlace adecuado como la interfaz a la que se enlaza el cliente. Eso es lo que permite que la conexión exterior salga por el enlace de respaldo cuando falla el primario. Por sí solo no cambia cómo se enruta el tráfico interior.

El lado del servidor del mismo diseño es aparte. Un servidor OpenVPN que deba ser accesible por varias direcciones públicas necesita un listener y una política de entrada para cada una de esas entradas, no solo un cliente capaz de marcar por dos enlaces. Una entrada pública que funciona no es prueba de que la segunda esté configurada.

Una regla de enrutamiento por política para paquetes LAN reenviados no es el ajuste que mueve una conexión de transporte VPN generada localmente. Son dos búsquedas distintas, y cambiar una no cambia la otra.

Extremo remoto: otro servidor

Un remoto alternativo es una función de la lista de conexiones. El cliente prueba la siguiente entrada cuando la actual no responde, lo que resulta útil cuando un host concreto está caído y no cuando lo está su propio enlace ascendente. Los dos fallos se parecen desde el escritorio de un usuario y exigen arreglos distintos.

Cada candidato tiene que ser un sustituto real: autenticación compatible, política de cliente compatible y acceso a los mismos recursos privados. Un segundo nombre de host que resuelve a la misma infraestructura caída no es un respaldo. Un servidor sin la ruta requerida tampoco lo es, por muy sano que parezca su handshake.

Este mecanismo tampoco hace que dos túneles reenvíen a la vez. Sustituye una conexión por otra, de forma secuencial, y el hueco entre ambas es visible para todo lo que estuviera corriendo.

Ruta del túnel: elegir otra salida

Cuando ya hay dos túneles levantados y quiere que el tráfico use el más sano, el mecanismo es una interfaz VPN asignada con su propia puerta de enlace, más una regla de política explícita que envíe a ella el tráfico correcto. Un grupo de puertas de enlace sobre esas interfaces asignadas puede expresar prioridad y monitorización.

Ese diseño trata de selección, no de recuperación. Mover conexiones nuevas al segundo túnel no dice nada sobre las sesiones ya establecidas en el primero, ni sobre si el lado remoto aceptará la nueva dirección de origen. Tratarlo como mecanismo de recuperación es la forma de fijar expectativas demasiado altas.

Si el requisito es que las sesiones existentes sobrevivan, dígalo explícitamente. La mayoría de las implementaciones no migran un flujo vivo entre túneles, y diseñar como si lo hicieran produce un failover que se ve correcto en un diagrama y tumba cada conexión abierta en la práctica.

Monitores, NAT y la regla de cierre seguro

Un monitor debe probar algo que el túnel se supone que entrega. Un objetivo que responde desde el par del túnel pero no desde la red de aplicaciones más allá informará sano mientras los usuarios no ven nada. Un objetivo de diagnóstico inalcanzable informará muerto mientras la ruta está bien. Elija la dirección a propósito y confirme que solo es alcanzable por el túnel previsto.

Revise el NAT saliente para ambas salidas. Una traducción que funciona en el primario no describe la dirección de origen del respaldo, y la red privada remota necesita una ruta de retorno que coincida con la fuente que presente. Una traducción correcta en una ruta puede estar silenciosamente mal en la otra.

Luego decida qué pasa con el tráfico que nunca debe usar el WAN. pfSense tiene un comportamiento definido para las reglas cuya puerta de enlace seleccionada está caída, y una regla de paso amplia posterior o una ruta por defecto pueden deshacer su intención. Anote el resultado bloqueado como requisito y verifíquelo bajando la ruta.

Pruebe la pérdida y la recuperación por separado, con tráfico que esté autorizado a generar, y observe tres cosas a la vez: el WAN que lleva la conexión exterior, el túnel que lleva la petición de la aplicación y la ruta que toma la respuesta. Un par de indicadores de puerta de enlace en verde no es una de esas tres. La guía multi-WAN de Netgate describe el enlace de transporte y las alternativas de cliente exportadas de las que depende esto.