La oficina pierde Internet. Alguien grita “la VPN está caída”, Slack explota y de pronto estás depurando desde tu teléfono en un estacionamiento con una barra de LTE. Mientras tanto, el segundo ISP que pagas cada mes está ahí como una llanta de repuesto que nunca se hincha.
La conmutación por error de VPN con dos ISP no es difícil, pero es fácil hacerlo de manera que parezca redundante en un diagrama y aún así falle en producción. Esta es la versión pragmática: diseños que realmente mantienen los túneles activos, comprobaciones de salud que no mienten, enrutamiento que no hace blackhole y las hábitos operativos aburridos que evitan que un incidente se convierta en terapia para toda la empresa.
Qué debe significar “conmutación por error” (y qué no)
En el mundo de oficinas, “conmutación por error de VPN” suele significar “el túnel debe permanecer activo cuando un ISP falla”. Ese es el resultado. Pero sólo lo consigues si defines qué significa “activo” y qué estás dispuesto a aceptar durante la falla.
Define el éxito en términos operativos
- Objetivo de tiempo de recuperación (RTO): ¿Cuántos segundos de pérdida de paquetes son aceptables? ¿2 segundos? ¿30 segundos? “Cuando Bob lo nota” no es una métrica.
- Objetivo de punto de recuperación (RPO): Para VPN esto tiene menos que ver con datos y más con estado. Los flujos con estado (VoIP, RDP, cargas largas) se romperán al cambiar de ruta a menos que estés preservando sesiones (raro). Decide si romper sesiones es aceptable.
- Radio de impacto: ¿La conmutación afecta sólo al tráfico site-to-site, o también a salida a Internet, DNS, SaaS, voz?
- Acción del operador: “Automático” significa sin necesidad de CLI a las 2 a. m. Puede alertar fuerte. Simplemente no debería requerir que lo reinicies manualmente.
Además: la conmutación por error no es un botón mágico que hace perfecto el enrutamiento aguas arriba. Si tu ISP secundario tiene peering degradado, tu túnel puede estar “activo” mientras tus aplicaciones se derriten. El sistema debe detectar la utilidad, no sólo el estado del enlace.
Broma #1: Tener WAN dual sin comprobaciones de salud es como tener dos paraguas y seguir empapándote porque solo los abres cuando la app del tiempo dice “lluvia”.
Algunos hechos e historia que explican los modos de fallo actuales
Un poco de contexto hace que la conmutación por error moderna sea menos misteriosa y más “ah, por eso se rompe”. Aquí hay hechos concretos que vale la pena tener en la cabeza:
- IPsec existía antes de las oficinas “siempre en línea”. Los primeros estándares de IPsec surgieron a finales de los 90, cuando se asumía sitios estáticos y enlaces de larga duración; la conmutación rápida no era el objetivo principal de diseño.
- NAT no fue ciudadano de primera clase. La traversía de NAT (NAT-T) se popularizó más tarde; muchos comportamientos extraños provienen de encapsular ESP en UDP/4500 para cruzar NATs.
- El comportamiento de IKEv1 vs IKEv2 difiere ante fallos. Muchas configuraciones “funciona hasta que no” dependen de rarezas de IKEv1; IKEv2 generalmente se comporta mejor pero sigue dependiendo de timers y ajustes DPD.
- Los “fallos” de ISP de consumo suelen ser parciales. Muchas interrupciones no son enlace abajo. Son fallos de resolución DNS, PMTU roto o un flap de enrutamiento aguas arriba. Por eso detectar gateway muerto con un ping al siguiente salto del ISP es mentira.
- BGP se convirtió en la forma adulta de hacer multihoming para empresas. Pero la mayoría de oficinas no puede obtener espacio de direcciones independiente del proveedor ni BGP con circuitos baratos; por eso simulamos resiliencia en capas superiores.
- SD-WAN no inventó las comprobaciones de salud; las productizó. La idea central—medir pérdida/latencia hacia un objetivo real y encaminar tráfico—existe desde hace décadas en scripts caseros y funciones de routers.
- La pérdida de paquetes perjudica a VPNs más que a navegación casual. La sobrecarga de encapsulación IPsec más las retransmisiones pueden convertir “1% de pérdida” en “¿por qué Teams es inutilizable?” más rápido de lo que te gustaría.
- Los blackholes de PMTU son un modo de fallo viejo y repetible. La sobrecarga del túnel reduce la MTU efectiva; si ICMP está bloqueado, Path MTU Discovery se rompe y los paquetes grandes desaparecen en el vacío.
Topologías que funcionan: active/standby, active/active y “no hagas esto”
Topología A: Túneles activo/standby (la más simple, a menudo la mejor)
Construyes dos túneles site-to-site: uno sobre ISP1 y otro sobre ISP2. Sólo uno transporta tráfico en condiciones normales. Si las comprobaciones de salud fallan, mueves la ruta al túnel de reserva. Puedes hacerlo con:
- VPN basada en rutas (preferida): dos interfaces de túnel, dos nexthops, métricas/prioridades.
- VPN basada en políticas (funciona, pero se vuelve frágil a medida que la red crece).
- Enrutamiento dinámico (BGP/OSPF) sobre los túneles (conmutación limpia, más piezas móviles).
Por qué funciona: estable, predecible, menos sorpresas por enrutamiento asimétrico. Depurar a las 3 a. m. es tolerable.
Compromiso: “desperdicias” el enlace de reserva. Está bien. Tu CFO desperdicia más dinero en sillas de sala de reuniones.
Topología B: Túneles activo/activo (más difícil, usar solo cuando sea necesario)
Ambos túneles transportan tráfico simultáneamente. Haces enrutamiento por prefijo, direccionamiento por aplicación, o ECMP. Es común cuando quieres más ancho de banda o que un ISP no sea “peso muerto”.
Dónde falla:
- Enrutamiento asimétrico si el tráfico de retorno no sigue el mismo túnel.
- Firewalls stateful que fijan flujos a una ruta y luego rechazan paquetes que llegan por la interfaz “incorrecta”.
- Limitaciones del lado remoto (algunas pasarelas VPN en la nube no toleran cambios frecuentes de ruta).
Mi opinión: haz activo/standby a menos que tengas una limitación de ancho de banda medida que justifique la complejidad. Si necesitas activo/activo, sé honesto: estás construyendo una WAN pequeña. Trátala como una.
Topología C: “Conmutación por DNS” (no lo hagas)
Algunos equipos intentan: “Si ISP1 falla, cambia el DNS del endpoint VPN”. Eso no es conmutación por error; es un plan de mantenimiento disfrazado de resiliencia. Cachés DNS, TTLs ignorados por clientes y sesiones de larga duración asegurarán que tus usuarios implementen tu prueba de corte.
Mecánica: comportamiento de IKE/IPsec, NAT, DPD y la realidad del rekey
La conmutación por error de VPN es un juego de timers. Estás balanceando cuán rápido detectas una falla frente a cuántas veces flapeas durante pérdidas transitorias.
DPD: Dead Peer Detection es necesario, no suficiente
DPD (o keepalives equivalentes) puede decirte que el peer no responde. Pero si la ruta de Internet está medio rota—los paquetes salen pero las respuestas no regresan—necesitas pruebas adicionales.
Buenas prácticas:
- Habilita DPD con valores razonables (p. ej., intervalos de 10–30s, un número pequeño de reintentos).
- Usa también sondas del plano de datos (ICMP o TCP hacia un objetivo a través del túnel).
- Toma decisiones de conmutación por error basadas en pérdida/latencia sostenida, no en una sola sonda fallida.
NAT y direcciones de origen: elige identidades estables
En dual ISP, el gateway VPN local puede presentar diferentes IPs públicas. Los peers remotos pueden autenticarse por ID (FQDN) y no importar el cambio de IP origen, o pueden fijarse a una dirección específica. Muchos servicios cloud de VPN esperan que configures ambos túneles explícitamente; eso es bueno. Quieres que el lado remoto espere la falla.
Comportamiento de rekey durante la conmutación
Los eventos de rekey son un clásico “falla cada hora” misterioso. Durante la conmutación, los timers de rekey pueden alinearse mal con la inestabilidad de la ruta, llevando a intentos repetidos de negociación. Cuando sea posible:
- Desfase las vidas útiles de rekey entre túnel primario y secundario.
- Asegura que ambos túneles puedan negociar de forma independiente (sin confusión de SA compartidas).
- Conserva logs. Los fallos de rekey rara vez se arreglan por intuición.
MTU: el asesino silencioso de túneles
La encapsulación reduce la MTU. Si tienes MTU LAN de 1500 y encapsulas en IPsec sobre PPPoE (común en DSL), puede que necesites clamar TCP MSS o bajar la MTU de la interfaz. Si no, obtendrás fallos intermitentes que parecen “algunos sitios cargan, otros no”.
Broma #2: Los problemas de MTU son el equivalente informático de una silla que cruje: inofensiva hasta que vuelve loco a todo el mundo y empiezas a cuestionar tus decisiones de vida.
Enrutamiento que no miente: VPN basada en políticas vs basada en rutas vs BGP
VPN basada en rutas: recomendación por defecto
La VPN basada en rutas te da una interfaz de túnel. Puedes usar rutas estáticas, métricas y tu tabla de enrutamiento normal. Es más fácil de combinar con comprobaciones de salud y enrutamiento dinámico.
Regla: si tu plataforma soporta VPN basada en rutas, úsala salvo que tengas una restricción específica.
VPN basada en políticas: aceptable para redes muy pequeñas
La VPN basada en políticas ata el cifrado a selectores de tráfico (subred-a-subred). Funciona hasta que añades una tercera subred, luego una cuarta, alguien quiere enrutar un /32 para una VM de prueba y de pronto estás gestionando políticas de seguridad con hojas de cálculo.
Enrutamiento dinámico sobre túneles: conmutación limpia, mayor nivel de habilidad
BGP sobre IPsec (o GRE sobre IPsec) es la forma más robusta de conmutar rutas entre túneles, porque los protocolos de enrutamiento ya resuelven “qué ruta es viable” si les alimentas señales de interfaz y keepalive correctas.
Cuándo usarlo:
- Tienes múltiples sitios o múltiples prefijos.
- Necesitas re-ruta automática sin funciones SD-WAN específicas del proveedor.
- Puedes operarlo: monitorización, filtros de rutas y control de cambios.
Cuándo no:
- Eres una oficina única con una red remota y sin apetito por política de enrutamiento.
- No puedes garantizar que ambos extremos puedan ejecutar BGP limpiamente (algunos servicios gestionados lo restringen).
Una cita sobre fiabilidad (idea parafraseada): Gene Kranz, director de vuelo de la NASA, enfatizaba ser “duro y competente” bajo presión—la fiabilidad es mayormente preparación, no heroicidad.
Comprobaciones de salud: probar que la ruta sirve, no sólo “activa”
El problema central con la conmutación en oficinas es que la mayoría de configuraciones de “WAN dual” detectan la falla equivocada. El módem cableado sigue sincronizado, así que el router cree que está bien. Mientras tanto, el enrutamiento aguas arriba está haciendo blackhole al tráfico hacia el peer VPN.
Qué sondear
- Alcanzabilidad del underlay: ¿Puedes alcanzar un objetivo de Internet estable vía cada ISP? Usa múltiples objetivos en redes diferentes. Evita usar “ping al gateway del ISP” como única prueba.
- Alcanzabilidad del overlay: ¿Puedes alcanzar algo a través del túnel? Un loopback en el firewall remoto es ideal. Mejor aún: un puerto de servicio (TCP/443 a un endpoint de salud) que pruebe más que ICMP.
- Calidad: Mide latencia y pérdida de paquetes. Define umbrales que se ajusten a tus aplicaciones (voz, VDI, compartición de archivos).
Cómo volver fiables las sondas
- Vincula las sondas a la interfaz/dirección de origen de cada ISP para que estés probando la ruta correcta.
- Usa múltiples sondas y requiere fallos consecutivos antes de declarar muerto.
- Limita la tasa de failback. Flapear entre ISPs convierte un problema menor aguas arriba en una caída total.
Tareas prácticas (con comandos, salidas y decisiones)
Estas son tareas prácticas que puedes ejecutar en un gateway VPN basado en Linux (o en un host de troubleshooting) para validar un diseño VPN con dos ISP. Los comandos son realistas. Las salidas son representativas. Después de cada uno verás qué significa la salida y qué decisión tomar.
Task 1: Confirmar que ambas WAN tienen rutas válidas
cr0x@server:~$ ip route show
default via 203.0.113.1 dev wan1 proto static metric 100
default via 198.51.100.1 dev wan2 proto static metric 200
10.10.0.0/16 dev lan0 proto kernel scope link src 10.10.0.1
203.0.113.0/24 dev wan1 proto kernel scope link src 203.0.113.20
198.51.100.0/24 dev wan2 proto kernel scope link src 198.51.100.20
Significado: Existen dos rutas por defecto; wan1 es preferida por métrica menor. La ruta LAN está presente.
Decisión: Si quieres underlay activo/standby, esto es correcto. Si pretendías activo/activo, necesitas enrutamiento por políticas o ECMP, no sólo dos default con métricas.
Task 2: Verificar reglas de enrutamiento por política (si haces sondeo de underlay dual o activo/activo)
cr0x@server:~$ ip rule show
0: from all lookup local
1000: from 203.0.113.20 lookup 100
1001: from 198.51.100.20 lookup 200
32766: from all lookup main
32767: from all lookup default
Significado: El tráfico con origen en cada IP WAN usa una tabla de enrutamiento específica.
Decisión: Mantén esto si necesitas sondas (y algo de tráfico de túnel) fijadas al ISP correcto. Si falta, tu “sonda wan2” puede salir silenciosamente por wan1 y mentirte.
Task 3: Confirmar que cada WAN puede alcanzar el peer VPN en el underlay (vinculado a la interfaz)
cr0x@server:~$ ping -I wan1 -c 3 192.0.2.10
PING 192.0.2.10 (192.0.2.10) from 203.0.113.20 wan1: 56(84) bytes of data.
64 bytes from 192.0.2.10: icmp_seq=1 ttl=55 time=18.4 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=55 time=18.1 ms
64 bytes from 192.0.2.10: icmp_seq=3 ttl=55 time=18.3 ms
--- 192.0.2.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 18.1/18.2/18.4/0.1 ms
Significado: Underlay hacia el peer es alcanzable vía wan1, con baja pérdida.
Decisión: Repite para wan2. Si wan2 no puede alcanzar el peer, no culpes a IPsec todavía; arregla enrutamiento, filtrado del ISP o problemas aguas arriba.
Task 4: Comprobar que IKE escuche en ambas WAN
cr0x@server:~$ sudo ss -lunp | grep -E ':(500|4500)\s'
UNCONN 0 0 0.0.0.0:500 0.0.0.0:* users:(("charon",pid=1324,fd=12))
UNCONN 0 0 0.0.0.0:4500 0.0.0.0:* users:(("charon",pid=1324,fd=13))
Significado: El daemon IKE (ejemplo: strongSwan charon) escucha en UDP/500 y UDP/4500 en todas las interfaces.
Decisión: Si sólo está enlazado a una IP, la conmutación secundaria nunca funcionará. Arregla la configuración del daemon o el firewall del sistema.
Task 5: Validar estado del túnel IPsec (ejemplo strongSwan)
cr0x@server:~$ sudo swanctl --list-sas
vpn-primary: #12, ESTABLISHED, IKEv2, rekeying in 46 minutes
local 'office-fw' @ 203.0.113.20[4500]
remote 'dc-fw' @ 192.0.2.10[4500]
AES_GCM_16_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
vpn-primary-child: #34, INSTALLED, TUNNEL, reqid 1
local 10.10.0.0/16
remote 10.50.0.0/16
vpn-secondary: #0, CONNECTING, IKEv2
local 'office-fw' @ 198.51.100.20[4500]
remote 'dc-fw' @ 192.0.2.10[4500]
Significado: El primario está establecido; el secundario está intentando pero no activo.
Decisión: Si el secundario nunca se establece, verifica que el peer remoto esté configurado para aceptar la segunda identidad/origen y que NAT/firewall lo permitan.
Task 6: Confirmar que las rutas a subredes remotas prefieren el túnel primario
cr0x@server:~$ ip route get 10.50.1.25
10.50.1.25 dev vti0 src 10.255.0.2 uid 0
cache
Significado: El tráfico a la red remota usa vti0 (interfaz de túnel primaria).
Decisión: Si sale directamente por wan1, tu VPN basada en rutas no está en realidad enrutable. Arregla rutas, VTI o selectores de tráfico.
Task 7: Probar la alcanzabilidad del overlay (sondea un loopback remoto a través del túnel)
cr0x@server:~$ ping -c 3 10.50.255.1
PING 10.50.255.1 (10.50.255.1) 56(84) bytes of data.
64 bytes from 10.50.255.1: icmp_seq=1 ttl=63 time=21.9 ms
64 bytes from 10.50.255.1: icmp_seq=2 ttl=63 time=22.1 ms
64 bytes from 10.50.255.1: icmp_seq=3 ttl=63 time=22.0 ms
--- 10.50.255.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 21.9/22.0/22.1/0.1 ms
Significado: El plano de datos funciona a través del túnel.
Decisión: Si el underlay está arriba pero el overlay falla, enfócate en selectores IPsec, políticas de firewall o enrutamiento del lado remoto.
Task 8: Comprobar problemas de MTU/fragmentación con ping DF
cr0x@server:~$ ping -c 3 -M do -s 1472 10.50.255.1
PING 10.50.255.1 (10.50.255.1) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1436
ping: local error: message too long, mtu=1436
ping: local error: message too long, mtu=1436
--- 10.50.255.1 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2051ms
Significado: La MTU efectiva a lo largo del túnel es 1436. Tu paquete de 1500 bytes no puede pasar con DF establecido.
Decisión: Clama TCP MSS (p. ej., a 1360–1400 según la sobrecarga) o ajusta MTU en túnel/LAN apropiadamente. Si ICMP está bloqueado aguas arriba, verás blackholes en lugar de errores claros.
Task 9: Inspeccionar xfrm state para confirmar que los SAs están instalados (Linux IPsec)
cr0x@server:~$ sudo ip xfrm state
src 203.0.113.20 dst 192.0.2.10
proto esp spi 0xc12f4a9d reqid 1 mode tunnel
replay-window 32 flag af-unspec
aead rfc4106(gcm(aes)) 0x4f9b... 128
src 192.0.2.10 dst 203.0.113.20
proto esp spi 0x1a2b3c4d reqid 1 mode tunnel
replay-window 32 flag af-unspec
aead rfc4106(gcm(aes)) 0x0aa1... 128
Significado: Existen ESP SAs en ambas direcciones para el primario.
Decisión: Si faltan SAs mientras IKE dice “established”, puede que haya problemas de negociación de CHILD_SA o conflictos de políticas.
Task 10: Verificar NAT traversal y encapsulado UDP en la red
cr0x@server:~$ sudo tcpdump -ni wan1 udp port 4500 -c 5
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wan1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
12:04:11.120111 IP 203.0.113.20.4500 > 192.0.2.10.4500: UDP-encap: ESP(spi=0xc12f4a9d,seq=0x2f1), length 132
12:04:11.140225 IP 192.0.2.10.4500 > 203.0.113.20.4500: UDP-encap: ESP(spi=0x1a2b3c4d,seq=0x19a), length 132
12:04:12.120332 IP 203.0.113.20.4500 > 192.0.2.10.4500: UDP-encap: ESP(spi=0xc12f4a9d,seq=0x2f2), length 132
12:04:12.140447 IP 192.0.2.10.4500 > 203.0.113.20.4500: UDP-encap: ESP(spi=0x1a2b3c4d,seq=0x19b), length 132
12:04:13.120552 IP 203.0.113.20.4500 > 192.0.2.10.4500: UDP-encap: ESP(spi=0xc12f4a9d,seq=0x2f3), length 132
5 packets captured
Significado: ESP está encapsulado en UDP/4500 y el tráfico fluye en ambas direcciones.
Decisión: Si sólo ves paquetes salientes, sospecha filtrado aguas arriba, NAT incorrecto o que el lado remoto no responde. Si ves sólo IKE/500 y no 4500 mientras estás detrás de NAT, NAT-T puede estar mal negociado.
Task 11: Confirmar que el firewall permite IKE/IPsec en ambas WAN
cr0x@server:~$ sudo nft list ruleset | sed -n '1,120p'
table inet filter {
chain input {
type filter hook input priority 0; policy drop;
iif "lo" accept
ct state established,related accept
iifname "wan1" udp dport { 500, 4500 } accept
iifname "wan2" udp dport { 500, 4500 } accept
iifname "lan0" accept
counter reject with icmpx type admin-prohibited
}
}
Significado: UDP/500 y UDP/4500 se aceptan en ambas interfaces WAN.
Decisión: Si falta wan2, las negociaciones del túnel secundario fallarán silenciosamente. Arregla el firewall antes de tocar configuraciones IPsec.
Task 12: Observar cambios de rutas durante una falla inducida
cr0x@server:~$ ip monitor route
Deleted default via 203.0.113.1 dev wan1 proto static metric 100
Added default via 198.51.100.1 dev wan2 proto static metric 200
Added 10.50.0.0/16 dev vti1 proto static metric 50
Deleted 10.50.0.0/16 dev vti0 proto static metric 10
Significado: La default primaria y la ruta del túnel primario fueron removidas; el secundario se activó y la ruta cambió a vti1.
Decisión: Esto es lo que quieres. Si las rutas no cambian, tu lógica de conmutación no está integrada con el enrutamiento (o falla al dispararse). Si flapean repetidamente, añade timers de hold-down y amplía los umbrales de las sondas.
Task 13: Confirmar salud a nivel de aplicación a través de la VPN (prueba TCP)
cr0x@server:~$ nc -vz -w 2 10.50.20.10 443
Connection to 10.50.20.10 443 port [tcp/https] succeeded!
Significado: El overlay puede alcanzar un servicio real. El éxito sólo por ICMP puede ocultar problemas de firewall o MTU.
Decisión: Usa esto como objetivo de sonda cuando te importe la disponibilidad de aplicaciones. Si falla durante la conmutación pero ping funciona, sospecha MSS/MTU, inspección stateful o asimetría de enrutamiento.
Task 14: Buscar síntomas de enrutamiento asimétrico con conntrack
cr0x@server:~$ sudo conntrack -S
cpu=0 found=24872 invalid=36 ignore=0 insert=0 insert_failed=0 drop=0 early_drop=0 error=0 search_restart=0
Significado: Tienes paquetes marcados como invalid, que suelen aumentar durante enrutamiento asimétrico o cambios de ruta.
Decisión: Si los invalid aumentan durante la conmutación, considera activo/standby en vez de activo/activo, o asegura enrutamiento simétrico con policy routing y manejo de NAT/estado consistente.
Guía de diagnóstico rápido
Cuando la VPN “conmuta” pero los usuarios todavía se quejan, necesitas aislar dónde vive la falla: underlay (ISP), overlay (IPsec), enrutamiento (tu equipo) o el lado remoto. Hazlo en este orden.
Primero: sanity del underlay (probar que la ruta del ISP es utilizable)
- Comprueba enlace y direccionamiento en ambas WAN (portadora arriba, DHCP/PPPoE, rutas).
- Sondea múltiples objetivos estables por WAN (ping o TCP bound a interfaz). Si sólo un ISP está degradado, no toques la VPN todavía.
- Confirma que puedes alcanzar la IP pública del peer VPN remoto desde cada WAN.
Segundo: plano de control del overlay (¿IKE negocia?)
- Confirma que UDP/500 y UDP/4500 están permitidos en ambas direcciones.
- Mira logs de IKE por loops de negociación, fallos de auth o desajuste de propuestas.
- Valida que el túnel secundario esté configurado en el peer remoto y no bloqueado por “solo permitir IP origen conocido”.
Tercero: plano de datos del overlay (¿pasan los paquetes?)
- Haz ping a un loopback remoto u host de prueba a través del túnel.
- Realiza una conexión TCP a un servicio real a través del túnel.
- Prueba PMTU con pings DF y clama MSS si es necesario.
Cuarto: enrutamiento y simetría (¿por dónde fue realmente el tráfico?)
- Checa selección de rutas hacia subredes remotas.
- Busca enrutamiento asimétrico con invalids en conntrack o drops de firewall.
- Si hay enrutamiento dinámico, verifica anuncios de rutas y filtros.
Quinto: lado remoto y dependencias de aplicación
- Confirma que el firewall remoto tiene rutas de vuelta a las redes de la oficina por el túnel activo.
- Comprueba DNS, proveedores de identidad y proxies “útiles” que pueden haberse fijado a la ruta antigua.
Tres mini-historias corporativas desde el campo
Mini-historia 1: El incidente causado por una suposición equivocada
La oficina tenía dos ISPs. La diapositiva presumía “conectividad redundante”. La realidad: ISP2 estaba enchufado y tenía una IP, pero nadie había probado nunca un VPN site-to-site sobre él porque “el firewall lo soporta”. Esa frase debería llevar una etiqueta de advertencia.
Un martes, ISP1 no se cayó; se volvió raro. El tráfico saliente funcionaba con algunos destinos. ¿La red del peer VPN? Blackhole aguas arriba. La detección de gateway muerto del firewall seguía declarando el enlace sano porque podía hacer ping al siguiente salto del ISP. Los usuarios podían navegar, lo que hacía creer a la dirección que el problema era “el equipo de VPN”.
El equipo forzó la conmutación manual a ISP2. El túnel nunca subió. El peer remoto solo permitía la IP pública conocida de ISP1, y la identidad del certificado estaba ligada a esa suposición. Habían construido redundancia en papel, pero operativamente era un punto único de fallo con una cuota mensual adjunta.
Lo solucionaron correctamente: configuraron ambos túneles en el remoto, usaron una identidad IKE estable no ligada a una IP WAN única e implementaron sondas de overlay que probaban un loopback detrás del firewall remoto. Dos semanas después simularon la falla durante horario laboral y vieron los túneles comportarse como adultos.
Mini-historia 2: La optimización que salió mal
Otra compañía quiso “usar ambos circuitos por ahorro”. Activaron activo/activo con ECMP entre dos VTI IPsec y se felicitaron cuando iperf mostró más throughput en laboratorio.
En producción, la mesa de ayuda empezó a recoger tickets que sonaban no relacionados: desconexiones intermitentes de archivos, audio unidireccional en VoIP y “el ERP se queda pensando”. Nada estaba totalmente caído. Todo estaba ligeramente encantado.
El culpable fue el enrutamiento asimétrico combinado con políticas de seguridad stateful en el lado remoto. Algunos flujos salían por el túnel A y volvían por el B. El firewall los descartaba como inválidos. Incluso cuando no se descartaban, el reordenamiento y la jitter aumentaron porque las rutas eran diferentes.
La solución fue poco glamourosa: revertir a activo/standby para la mayor parte del tráfico, reservar activo/activo sólo para unos pocos flujos sin estado y forzar simetría con policy routing donde era necesario. Los gráficos de throughput parecían menos excitantes. Los usuarios dejaron de llamar. Ese es el KPI que importa.
Mini-historia 3: La práctica aburrida pero correcta que salvó el día
Una oficina mediana tenía dual ISP con dos túneles IPsec a un datacenter. Nada sofisticado: VPN basada en rutas, primario/secundario, comprobaciones que sondeaban un loopback remoto y un puerto TCP, más un timer de hold-down de 60 segundos antes del failback.
También hacían algo que a nadie le encanta: simulacros trimestrales de conmutación durante una ventana de mantenimiento. No sólo desenchufaban cables; simulaban fallas parciales—inyección de pérdida, caídas de DNS, blackholes de rutas aguas arriba—porque eso es lo que los ISPs reales hacen cuando tienes planes de fin de semana.
Cuando una cuadrilla de construcción cortó la fibra (predecible, eterno), la oficina perdió unos segundos de tráfico y siguió funcionando. El túnel cambió, las rutas se actualizaron y el sistema de monitorización avisó con un limpio “failover succeeded”. Nadie tuvo que SSH desde un teléfono.
La revisión posterior al incidente fue corta: confirmar cronologías, confirmar que el simulacro coincidía con la realidad, enviar el ticket al ISP y volver al trabajo. Aburrido es una característica.
Errores comunes: síntoma → causa raíz → solución
Esta es la sección que lees cuando ya llegas tarde a algo.
1) Síntoma: ISP1 falla y el túnel cae; el túnel por ISP2 nunca sube
- Causa raíz: El peer remoto sólo permite una IP origen / sólo un túnel configurado / identidad IKE incorrecta para el secundario.
- Solución: Configura ambos túneles en el lado remoto explícitamente; usa ID estable (FQDN o DN de certificado) no ligado a una IP WAN; confirma alcance UDP/500 y UDP/4500 por ISP2.
2) Síntoma: El túnel indica “up” pero los usuarios no alcanzan nada
- Causa raíz: El plano de control está establecido; el plano de datos roto por rutas faltantes, selectores de tráfico erróneos o enrutamiento en el lado remoto.
- Solución: Sonda un loopback remoto a través del túnel; verifica que la ruta a la subred remota apunte a la interfaz de túnel; revisa rutas remotas de vuelta a las subredes de oficina.
3) Síntoma: Ocurre la conmutación, pero SaaS funciona y las apps internas no
- Causa raíz: Sólo la ruta VPN está rota (alcanzabilidad del peer, ESP bloqueado o overlay no ha cambiado ruta), mientras que Internet general sigue bien.
- Solución: Sonda el IP público del peer VPN desde cada ISP; usa sondas de overlay; no confíes en “Internet está arriba” como prueba de que la VPN está bien.
4) Síntoma: Sitios aleatorios o descargas grandes fallan sólo por VPN, especialmente tras conmutación
- Causa raíz: MTU/PMTU blackhole; ICMP bloqueado; TCP MSS demasiado grande para la ruta encapsulada.
- Solución: Clama MSS en el túnel o en la salida LAN; ajusta MTU del túnel; permite ICMP fragmentation-needed cuando sea posible; verifica con pings DF.
5) Síntoma: Activo/activo parece bien hasta que las llamadas suenan robóticas
- Causa raíz: Jitter/reordenamiento de ruta; enrutamiento asimétrico; ECMP distribuyendo flujos por enlaces de distinta calidad.
- Solución: Usa direccionamiento por aplicación consciente; fija la voz al mejor enlace; o deja de ser ingenioso y usa activo/standby.
6) Síntoma: Flapping—conmutación frecuente cada pocos minutos
- Causa raíz: Umbrales de sonda agresivos; objetivo de sonda único; failback sin hold-down.
- Solución: Usa múltiples objetivos de sonda; requiere fallos consecutivos; añade hold-down para el failback; afina umbrales según la tolerancia de tus apps.
7) Síntoma: El túnel secundario sube, pero el tráfico de retorno muere (tráfico unidireccional)
- Causa raíz: El lado remoto sigue enroutando de vuelta vía el túnel primario; propagación de rutas retrasada; enrutamiento asimétrico + drop por firewall stateful.
- Solución: Asegura que el remoto use prioridades de ruta que coincidan con el estado del túnel; si usas BGP, valida withdrawal/advertisement; si es estático, usa rutas monitorizadas ligadas al estado del túnel.
8) Síntoma: Todo falla sólo durante rekey, especialmente en el secundario
- Causa raíz: Timers de rekey coinciden con enlace inestable; propuestas desajustadas; DPD demasiado lento/rápido, provocando negociaciones repetidas.
- Solución: Alinea propuestas criptográficas; desface rekey; ajusta DPD; valida logs durante ventanas de rekey.
Listas de verificación / plan paso a paso
Si quieres conmutación por error de VPN en oficina que no requiera un ingeniero de soporte emocional dedicado, sigue este plan. Es opinado porque la realidad es opinada.
Paso 1: Elige tu arquitectura objetivo
- Por defecto: IPsec basada en rutas, túneles activo/standby, comprobaciones de plano de datos que conduzcan cambios de ruta.
- Ruta de mejora: añade enrutamiento dinámico (BGP) sobre ambos túneles cuando tengas múltiples prefijos/sitios.
- Evita: conmutación por DNS, scripts que editen configs en caliente y ECMP a menos que entiendas simetría y estado.
Paso 2: Haz las identidades y la configuración robustas a cambios WAN
- Usa IDs IKE estables (FQDN o certificados) en lugar de “mi IP pública”.
- Configura ambos túneles en el peer remoto explícitamente.
- Documenta puertos y protocolos requeridos (UDP/500, UDP/4500; ESP si no hay NAT-T).
Paso 3: Implementa comprobaciones que midan utilidad
- Sondas de underlay: 2–3 objetivos de Internet por WAN (bound a interfaz), no sólo el next hop del ISP.
- Sondas de overlay: ping a un loopback remoto más conexión TCP a un servicio interno.
- Lógica de decisión: fallos consecutivos, umbrales y hold-down para failback.
Paso 4: Ata la salud al enrutamiento, no a la esperanza
- Rutas monitorizadas o métricas que cambian cuando las sondas fallan.
- Orden claro de preferencia: primario salvo que se demuestre lo contrario.
- Si tienes que hacer activo/activo, implementa controles de simetría y prepárate para depurar drops de estado.
Paso 5: Diseña para MTU y la realidad del rekey
- Ajusta MTU/MSS correctamente desde el principio. No es un “agradable tener”.
- Desfase los timers de rekey si tu plataforma lo permite.
- Conserva logs el tiempo suficiente para detectar patrones horarios/diarios.
Paso 6: Monitorización y alertas que no lloren a cada rato
- Alerta sobre: túnel caído, fallos de sondas de overlay y frecuencia de flapping.
- Registra: qué ISP está activo, pérdida/latencia de sondas y cambios de rutas.
- Tener una señal única “VPN failover succeeded”; reduce pánico y ruido de tickets.
Paso 7: Prueba como un adulto
- Prueba pérdida total del ISP (enlace abajo).
- Prueba fallas parciales (bloqueo UDP/4500, inyección de pérdida, ruptura de DNS).
- Prueba el comportamiento de failback (hold-down y estabilidad).
Preguntas frecuentes
1) ¿Debería usar activo/activo o activo/standby para la VPN de oficina?
Activo/standby salvo que tengas una necesidad de ancho de banda medida que un enlace no pueda cubrir. Activo/activo introduce problemas de simetría y estado que son caros de depurar.
2) ¿Puedo fiarme sólo de DPD para la conmutación por error?
No. DPD detecta la capacidad de respuesta del peer, no la utilidad de la aplicación. También necesitas sondas del plano de datos a través del túnel y, idealmente, una comprobación TCP a nivel de aplicación.
3) ¿Por qué mi firewall dice que el túnel está activo pero nada funciona?
Porque IKE puede estar establecido mientras las rutas, los selectores o el enrutamiento de retorno del lado remoto están mal. Siempre prueba la alcanzabilidad del overlay a una IP/servicio remoto conocido.
4) ¿Cuál es el mejor objetivo de sonda para la salud del overlay?
Una IP de loopback en el gateway VPN remoto (estable, siempre enrutada) más una sonda TCP a un servicio real que te importe (p. ej., HTTPS en un balanceador interno).
5) ¿Necesito BGP para tener buena conmutación por error?
No para una oficina única a un sitio único. Rutas estáticas con tracking pueden ser perfectamente fiables. Usa BGP cuando tengas múltiples prefijos, múltiples sitios o estés cansado de gestionar rutas estáticas.
6) ¿Qué tan rápido debe ser el failover?
Suficientemente rápido para que los usuarios no lo noten, lo bastante lento para no flappear. En la práctica: detección en ~10–30 segundos para muchas oficinas, con hold-down de failback de 60–300 segundos. Afina según el comportamiento medido del enlace.
7) ¿Por qué fallan transferencias grandes pero los pings pequeños funcionan?
Clásico blackhole de MTU/PMTU. Los ICMP pequeños pasan, los segmentos TCP grandes no. Arregla el clamping MSS y confirma con pings DF.
8) ¿Puedo hacer failover cambiando el DNS público del endpoint VPN?
Puedes, pero no es conmutación fiable. Cachés DNS y sesiones de larga duración te traicionarán. Usa dos túneles y lógica real de enrutamiento/sondas.
9) ¿Qué pasa si mi ISP usa CGNAT en el enlace de respaldo?
Sigue siendo posible si el peer remoto acepta NAT-T desde puertos/direcciones origen cambiantes, pero es más riesgoso. Prefiere una IP pública real para la terminación VPN o usa un relay/terminador en la nube que controles.
10) ¿Cómo prevenir flapping de failback cuando ISP1 está “mayormente de vuelta”?
Añade un timer de hold-down y requiere sondas sostenidamente sanas antes de fallar de vuelta. Además, sondea múltiples objetivos; un camino recuperado no significa que Internet esté realmente sano.
Conclusión: próximos pasos que puedes hacer esta semana
Si quieres conmutación por error de VPN de oficina que no requiera supervisión manual, deja de pensar en “dos circuitos” y empieza a pensar en “rutas medibles y dirigibles”. Construye dos túneles, prueba que ambos funcionan y haz que el router/firewall elija basándose en el plano de datos—no en luces de enlace esperanzadas.
Pasos prácticos siguientes
- Inventario de la realidad: Confirma que ambos ISPs pueden alcanzar el peer VPN remoto y que UDP/500/4500 pasan en ambas direcciones.
- Poner en marcha el túnel secundario: Configúralo en ambos extremos. Verifica que se establezca y pueda pasar tráfico antes de llamarlo “redundante”.
- Añadir sondas de overlay: Haz ping a un loopback remoto y ejecuta una sonda TCP a un servicio a través del túnel. Haz que el enrutamiento siga los resultados de las sondas.
- Arreglar MTU temprano: Prueba pings DF, clama MSS y documenta los valores elegidos.
- Realizar un simulacro de conmutación: Induce la falla en una ventana controlada, observa cambios de rutas, confirma impacto en usuarios y afina umbrales para evitar flapping.
Haz esto y obtendrás el premio real: el segundo ISP dejará de ser una donación mensual a los dioses del networking y empezará a ser lo que debía ser—un seguro aburrido que realmente paga.