La segunda entrada VPN de WAN falla mientras la primaria sigue funcionando

El túnel primario sigue en pie, los usuarios siguen trabajando y el segundo circuito del ISP queda inactivo hagas lo que hagas. Publicaste una dirección para el circuito de respaldo, apuntaste un nombre hacia ella, quizá añadiste una entrada de respaldo al cliente, y el cliente o nunca la prueba o se autentica y luego muere. En los casos que he seguido, la función de failover solía estar bien; lo que faltaba era una de las cinco cosas que hacen utilizable una entrada. Un nombre puede resolverse a la dirección de respaldo mientras nada escucha en esa interfaz, y un listener puede aceptar una conexión mientras la respuesta sale por la primaria. Trata cada WAN como una entrada separada con su propio contrato y el fallo deja de parecer un error del cliente.

Cada WAN necesita su propio contrato de entrada

Anota cinco campos por WAN: el nombre y la dirección públicos, el transporte y el puerto, la interfaz o el contexto que lo termina, la identidad del par que debe presentar y por dónde sale la respuesta. Dos circuitos significan dos conjuntos completos. Si el segundo conjunto no tiene interfaz de terminación ni ruta de retorno, no tienes una entrada de respaldo; tienes un registro DNS que describe una intención.

El equipo y su versión también deben soportar la disposición. Un registro DNS no puede abrir un servicio en otra interfaz, y en muchas plataformas el listener se configura por dirección y no por dispositivo. El IPsec basado en interfaz en un ASA ata los mapas criptográficos y los grupos de túnel a la interfaz exterior, así que un segundo enlace ascendente necesita política donde esos paquetes llegan de verdad. Los diseños basados en rutas se comportan distinto: el listener puede ligarse a todas las direcciones o a una dirección concreta, y esa elección decide si el ISP B puede responder siquiera.

Comprueba que el segundo WAN responde de verdad

Prueba desde fuera de ambos circuitos, no desde una máquina detrás de la puerta de enlace, y prueba el nombre exacto que usa el perfil del cliente. Para un listener TLS, la comprobación rápida es openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts ejecutada desde un host fuera de tu red. Quieres un handshake completado cuya cadena coincida con el nombre del perfil, no solo un puerto TCP que acepte una conexión.

RFC 9525 explica qué comprueba el cliente: la identidad a la que pretendía llegar, comparada con el certificado que presenta el servicio. Una segunda entrada que devuelve el certificado de la entrada primaria, o un certificado por defecto que no lista ninguno de los nombres, falla esta prueba aunque el puerto esté abierto y el cortafuegos lo permita.

Dos patrones explican la mayoría de los fallos aquí. Una conexión que se cuelga suele significar que no hay listener en esa interfaz, una regla de acceso que solo permite las subredes primarias, o un dispositivo del operador delante del segundo circuito que descarta el puerto. Un handshake que termina con la identidad equivocada suele significar otro trustpoint, un host virtual por defecto o una configuración copiada de la primaria sin ajustar la identidad.

Sigue la respuesta, no solo la petición

El segundo WAN suele romperse en la vuelta. Una petición llega por el ISP B, el equipo responde y la respuesta sale por la ruta por defecto del ISP A con una dirección de origen que el cliente nunca pidió. La traducción con estado lo empeora: si el mapeo se construyó para la interfaz primaria, el paquete de vuelta no encuentra la traducción o lleva un origen que el cortafuegos del cliente descarta. Los proveedores también descartan direcciones de origen que no pertenecen al circuito que te dieron, y por eso esto parece un agujero negro unidireccional en lugar de un error de protocolo limpio.

Comprueba la decisión de enrutamiento para el tráfico originado en la segunda entrada. La respuesta debe salir por la interfaz por la que llegó la petición, o al menos llevar una dirección que el lado lejano acepte como perteneciente a esa ruta. En plataformas de enrutamiento por política eso significa una regla ligada a la interfaz de entrada o al origen traducido, más una declaración de traducción ligada a cada interfaz exterior. Captura a la vez en ambas interfaces mientras el cliente se conecta; un SYN que llega por el ISP B con el SYN-ACK saliendo por el ISP A resuelve la cuestión en una sola pasada.

Dale al cliente una forma de enterarse de la segunda entrada

El failover es una decisión del lado del cliente, y cada familia de clientes aprende las alternativas de forma distinta. En un ASA, la lista de servidores de respaldo se entrega mediante los atributos webvpn de la política de grupo, mientras que otros clientes esperan una lista dentro del perfil o un segundo perfil manual que el usuario elige. La guía de políticas de conexión de Cisco describe tanto la información configurada en el cliente como la proporcionada por la puerta de enlace, y esos detalles específicos del protocolo no deben generalizarse a cada cliente o modo de túnel. Confirma qué mecanismo implementa el cliente desplegado antes de construir la segunda entrada en torno al equivocado.

Sea cual sea el mecanismo, el cliente debe poder resolver el nombre alternativo antes de perder la ruta primaria. Esa dependencia es la que la gente pasa por alto: si el nombre de respaldo lo responde un resolutor solo accesible por el túnel que acaba de fallar, el respaldo ni siquiera puede empezar. Publica el segundo nombre en un resolutor que responda localmente o por internet. Espera una autenticación nueva y una sesión de aplicación nueva tras el cambio, porque el failover del cliente no es failover con estado y las sesiones largas no lo sobreviven.

Una dirección en dos proveedores es otro producto

Mantener una única dirección pública accesible por ambos circuitos es un servicio de enrutamiento, no una casilla en la VPN. Necesita espacio de direcciones que ambos proveedores estén dispuestos a transportar, anunciado de forma que sus redes lo acepten, y eso es lo que da el multihoming con espacio independiente del proveedor y BGP. Asignar la dirección del ISP A a la interfaz del ISP B no llega ahí; el paquete llega a una red que nunca anunció el prefijo y se descarta aguas arriba.

No necesitas nada de eso para publicar dos entradas. Si el cliente puede mantener dos nombres y fallar entre ellos, dos entradas independientes bastan, y te ahorras un número AS, un acuerdo de peering y un prefijo que deba aceptarse en todas partes. Considera la opción de dirección portátil solo cuando de verdad necesites un punto de entrada estable que los clientes no puedan reconfigurar para sustituir, o cuando el failover basado en DNS con su retardo de TTL sea demasiado lento para la interrupción contra la que diseñas.

Qué comprobar después

Trabaja hacia fuera desde la entrada que falla en este orden: si la segunda dirección responde desde fuera, si presenta la identidad que el cliente espera, si la respuesta sale por el camino por el que llegó la petición, y si el cliente puede aprender el nombre antes de necesitarlo. Donde la respuesta sea no, arregla esa capa y vuelve a probar con el perfil desplegado y no con un host de prueba, porque un handshake del laboratorio demuestra menos que una conexión completada por el cliente real.

Mantén un registro breve por WAN, con dirección, puerto, interfaz de terminación, nombre del certificado, ruta de retorno y regla de traducción, y revísalo cada vez que cambie un circuito, un dispositivo NAT o una versión de cliente. Las rutas de respaldo inactivas se pudren en silencio: nada avisa de la entrada que nadie usa hasta el día en que todos dependen de ella.