Supervisar una VPN del router sin confiar en una sola luz de estado

La página de estado dice conectado, la luz está verde y la oficina no puede llegar al servidor de archivos. Uno de esos hechos trata del túnel y el otro del camino a través de él. Supervisar ambos es la diferencia entre una alerta sobre la que puede actuar y una que aprende a ignorar.

Cinco comprobaciones, en orden, desde el par hacia fuera.

Comprobación 1: estado del par o de la asociación

Cada protocolo expone su propio estado. WireGuard muestra el último handshake y los contadores de transferencia por par mediante wg show. OpenVPN escribe el estado de la sesión en su archivo de estado o en la interfaz de gestión, e IPsec expone las asociaciones de seguridad mediante herramientas como ipsec statusall. La trampa es leer una marca de tiempo como veredicto: un par de WireGuard inactivo sin nada que enviar no hará un handshake reciente, y eso no es una caída.

Compare la marca de tiempo con el tráfico esperado y la configuración de keepalive antes de avisar a alguien.

Comprobación 2: la ruta seleccionada

Una interfaz de túnel puede existir mientras nada enruta hacia ella. Revise la tabla de reenvío para el destino que le importa, no para la subred propia del túnel. Si el prefijo falta o apunta a otro lugar, el estado del par es irrelevante.

Esa comprobación detecta el fallo que una luz de estado nunca muestra.

Una segunda comprobación útil también compara la dirección de origen. ip route get 10.20.5.10 devuelve el siguiente salto, la interfaz y el origen preferido, y un origen equivocado basta para romper el tráfico de retorno en el extremo remoto. Anote la terna esperada una vez y alerte cuando cambie cualquier elemento. Esa sola línea detecta cambios de NAT, fluctuaciones de la interfaz y errores de enrutamiento por política.

Comprobación 3: una ruta de aplicación permitida

Pruebe algo representativo del requisito real. Un ping originado en el router sale de la dirección y la política del propio router, que pueden diferir del tráfico LAN reenviado, y muchos equipos limitan ICMP. Si el requisito es un servicio privado, pruebe ese servicio en su puerto real.

Mantenga el volumen de la prueba modesto. Un bucle de supervisión no debería convertirse en el tráfico que mide.

Comprobación 4: qué cambió y cuándo

Correlacione cambios de WAN, renovaciones de claves, retiradas de rutas y fallos de aplicaciones en una sola línea temporal. Distinga un fallo del túnel de una ruta de respaldo que restaura en silencio el acceso normal a internet, porque ambas producen informes de usuario idénticos y diagnósticos opuestos. Los errores de zona horaria invertirán el orden, así que normalice antes de comparar. La línea temporal es lo que convierte cuatro comprobaciones en una causa.

Conserve los registros de las transiciones, no de la carga útil.

Comprobación 5: la alerta debe nombrar el límite

Una alerta que dice VPN caída envía a alguien al lugar equivocado la mitad de las veces. Una que dice handshake del par obsoleto desde hace doce minutos, ruta a 10.20.0.0/16 ausente o prueba al puerto 445 fallida señala una comprobación concreta.

Conserve contadores operativos en lugar de navegar por cargas útiles. Los contadores responden la pregunta de supervisión sin recopilar contenido que no necesita.

Y deje que la política de conmutación decida qué ocurre después. La supervisión debe identificar qué límite falló, no autorizar una omisión amplia cada vez que falla una prueba. El manual de OpenVPN 2.6 documenta el archivo de estado y la interfaz de gestión que hacen que la primera comprobación sea programable.