Cómo construir una política de conmutación por error de VPN en el router sin fugas
Decide qué debe hacer el tráfico cuando cae el túnel preferido: túnel de respaldo, WAN normal o bloqueo. Luego constrúyelo y pruébalo en el router.
La conmutación por error funcionó exactamente como estaba configurada, y ese era el problema. Cuando cayó el túnel principal, el router movió la ruta por defecto al módem de cable, los portátiles siguieron navegando y nadie llamó. Dos días después alguien notó que el recurso compartido de finanzas había estado accesible por la vía abierta de internet durante seis horas. Una política de conmutación por error de VPN en el router no es un truco de enrutamiento; es una decisión sobre qué debe hacer el tráfico cuando la ruta preferida ya no está, y esa decisión debe existir antes de que la ruta desaparezca.
Decide el resultado antes de elegir el detector
Normalmente hay tres resultados sobre la mesa: enviar a los clientes afectados por un túnel de respaldo, dejarles usar la WAN normal o bloquearlos del todo. Anota cuál se aplica a cada VLAN, SSID o clase de dispositivo. Una única regla plana de «cambiar a la WAN» es cómo el recurso de finanzas de arriba acabó en una ruta pública.
Los tres no son intercambiables. El respaldo por WAN mantiene al servicio de soporte atendiendo teléfonos mientras expone los nombres internos al resolver local. Un túnel de respaldo conserva la política, pero puede aterrizar en una dirección de salida que el otro extremo no acepta. El bloqueo es correcto para una VLAN de nóminas e incorrecto para una red de invitados que nunca usó el túnel.
| Resultado | Adecuado para | Qué se rompe |
|---|---|---|
| Túnel de respaldo | La política debe mantenerse, se requiere acceso remoto | Nueva dirección de salida, ruta de retorno, renovación de clave más lenta |
| WAN normal | Tráfico de invitados o solo público | Nombres internos, exposición de DNS e IPv6 |
| Bloqueo | Nóminas, administración, cualquier cosa solo-VPN | Los usuarios pierden todo acceso y te llaman |
Ajusta el detector al fallo que de verdad temes
El estado del handshake, el estado de la interfaz y el reenvío utilizable son tres señales distintas, y al usuario solo le importa la última. Un par de WireGuard puede mostrar un handshake reciente mientras el upstream del proveedor tira paquetes a un agujero negro. OpenVPN el cliente puede quedarse en «conectado» después de que la ruta que empujó dejara de resolverse.
En pfSense la disposición práctica es un grupo de puertas de enlace alimentado por dpinger, que sondea una dirección de monitorización y marca una puerta como caída cuando la pérdida o la latencia superan sus umbrales. Apunta esa monitorización a algo más allá del túnel, como un host en la LAN remota o una dirección pública a la que llegas a través de él. Apuntarla a la propia dirección de par del túnel mide la parte que ya sabes que está viva.
Construye el grupo para que el respaldo siga siendo el último recurso
Usa niveles en lugar de una lista plana de miembros. Primario en el nivel 1, túnel de respaldo en el nivel 2, WAN en el nivel 3 solo para las VLAN cuya política lo permita. En pfSense esto está en System > Routing > Gateway Groups: añade ambas puertas de enlace, dales niveles distintos, pon Trigger Level en member down plus packet loss, guarda y luego aplica el grupo como predeterminado de la interfaz o en el campo Gateway de las reglas de cortafuegos que lo necesiten.
Para una instancia de cliente OpenVPN en pfSense 2.5 y posteriores, el ajuste Default Gateway de la instancia decide si el túnel sustituye o no la ruta por defecto del sistema. El enrutamiento de políticas por regla solo se comporta como esperas cuando la ruta que supones que existe está realmente instalada. Comprueba Status > Gateways después del cambio en lugar de confiar en el icono de estado del túnel.
Dos ajustes causan la mayor parte del parpadeo. Uno es un intervalo de sondeo más corto que la reconvergencia del propio proveedor. El otro es un grupo donde primario y respaldo comparten nivel, así que ambos siguen siendo elegibles todo el tiempo. Añade histéresis con umbrales de pérdida y latencia antes de que tus usuarios sientan las transiciones por ti.
Cierra las rutas que el túnel nunca poseyó
Primero las fugas de DNS. El resolver sigue respondiendo en la WAN y reenviando por ella, así que los nombres se siguen resolviendo a través del ISP mientras el tráfico está fijado al túnel. Restringe las interfaces de salida del resolver, empuja el resolver interno a los clientes y bloquea el puerto 53 para todo lo demás en las VLAN solo-VPN.
IPv6 necesita su propia decisión. Una LAN de doble pila puede perder el túnel y conservar una ruta por defecto global IPv6 que funciona, así que los navegadores prefieren IPv6 y salen por la WAN mientras IPv4 parece perfectamente contenido. O enrutas IPv6 dentro del túnel o dejas de anunciar un prefijo global mientras el túnel está caído. Media política es peor que ninguna, porque parece que funciona.
Luego la ruta de retorno. Si la salida de respaldo usa una dirección de origen distinta, el otro extremo debe saber cómo enviar el tráfico de vuelta, y cada estado ligado a la dirección antigua ya está muerto. Las sesiones abiertas cuando cayó el primario no migran; se quedan paradas hasta que caducan y la aplicación decide qué hacer.
Prueba la caída, el parpadeo y el camino de vuelta
Quita el primario con tráfico inofensivo en marcha y luego lee cuatro cosas: Status > Gateways para los estados de los miembros del grupo, pfctl -ss para los estados aún fijados a la puerta antigua, un traceroute desde un cliente para la ruta de salida y una consulta al resolver para ver qué servidor respondió.
Ahora hazlo parpadear. Sube el primario treinta segundos, bájalo treinta, dos veces. Si el tráfico persigue cada transición, los umbrales están demasiado ajustados o los niveles son incorrectos. Arréglalo según tu calendario, porque si no un proveedor lo hará según el suyo.
Por último, confirma que aún puedes administrar el router. Mantén una ruta fuera de banda como un cable de consola, una VLAN de gestión o un módem celular. Una prueba de conmutación por error que te deja fuera es una prueba que no puedes terminar, y un router inalcanzable no puede volver por sí solo.
Antes de dar la política por terminada, deberías poder responder cuatro preguntas sin abrir un terminal: qué VLAN pueden usar la WAN mientras el túnel está caído, qué vigila el detector y cuánto espera, qué servidores de nombres y rutas IPv6 se mueven con la ruta, y cómo vuelves a entrar si el respaldo también falla. Si alguna respuesta es «lo que fuera el valor por defecto», la política sigue perteneciendo al router y no a ti.