Cómo comprobar si un túnel VPN de Linux está realmente activo

Cron reinicia cada diez minutos un VPN perfectamente sano, y el mismo trabajo deja uno muerto funcionando durante una semana. Ambos fallos vienen de tratar «activo» como un único hecho cuando es al menos cuatro. Un dispositivo puede estar habilitado administrativamente, enrutado correctamente, totalmente cifrado y, aun así, no transportar nada útil. Separe primero las observaciones y la comprobación casi se escribe sola.

Los indicadores del enlace describen el dispositivo, no la ruta

La comprobación que todos copian busca una dirección de hardware de puros ceros. Ese truco separa una interfaz real de un marcador de posición en algunos controladores y no demuestra nada en los demás, porque un dispositivo tun no tiene ninguna MAC que informar. ip -brief link show tun0 ofrece en cambio indicadores: UP significa que un administrador habilitó el dispositivo, y LOWER_UP significa que el controlador considera utilizable el enlace. Leídos juntos, dicen que el dispositivo existe y no está administrativamente desactivado. Ninguno de los dos dice que un paquete tenga adónde ir.

OpenVPN crea su dispositivo tun antes de que se instalen las rutas, así que los indicadores pueden verse perfectos mientras nada está enrutado. Trátelos como una precondición, nunca como la respuesta.

Pregunte adónde iría un paquete

La consulta de ruta responde a la pregunta que los indicadores no pueden. ip route get 10.8.0.1 from 10.8.0.2 nombra la interfaz, la dirección de origen y la tabla que usaría el núcleo, que es exactamente contra lo que hay que comprobar un túnel dividido. Sin la dirección de origen está preguntando otra cosa, y con enrutamiento por políticas la respuesta puede variar según el origen. Es la prueba honesta más barata, porque consulta las mismas reglas que usará su tráfico.

Para WireGuard, añada el saludo. wg show imprime una marca de tiempo del último saludo por par, y una marca que dejó de avanzar significa que el par desapareció, digan lo que digan los indicadores de la interfaz. Una interfaz configurada sin saludo reciente es uno de los falsos positivos más habituales en la monitorización casera.

La tabla 220 cuenta la historia de IPsec

strongSwan instala rutas para los selectores negociados en la tabla 220 cuando la instalación de rutas está habilitada. ip route list table 220 por lo tanto separa lo negociado de lo enrutado: una tabla vacía junto a una conexión cargada significa que las SA de IKE y CHILD subieron mientras ningún tráfico se dirige hacia ellas. Compruebe ip xfrm state al lado, ya que enumera las asociaciones de seguridad instaladas y sus extremos.

Una política de trampa es el caso al que hay que estar atento. Espera tráfico interesante en lugar de enrutarlo, así que la tabla sigue vacía hasta que algo dispara el túnel.

El estado del gestor y el estado del demonio son listas distintas

NetworkManager enumera solo las conexiones que posee. nmcli -t -f NAME,TYPE connection show --active no devuelve nada para un túnel iniciado directamente por wg-quick o por un demonio OpenVPN.

Esa distinción importa cuando un script tiene que decidir a cuál de los dos gestores preguntar. Elija el que realmente posee el túnel en este host e ignore el silencio del otro. Si existen ambos, decida cuál es el autoritativo y desactive el segundo, porque dos gestores que reescriben rutas en una sola interfaz producen fallos que nadie puede reproducir. Una entrada ausente es información sobre el gestor, no sobre el túnel.

Condicione el siguiente paso a la sonda que necesita

Sondear un puerto UDP no demuestra nada sobre la disponibilidad, porque UDP no tiene saludo y nc -u tiene éxito en cuanto el paquete sale. Sondee lo que el siguiente paso consume de verdad: una conexión TCP al puerto redirigido, una petición a un host dentro del túnel, un nombre que solo se resuelve allí. Acote la espera con un tiempo de espera y un número de intentos, y falle ruidosamente cuando se agote.

Los ganchos superan el sondeo cuando el cliente los ofrece. --up y --down los scripts de OpenVPN se ejecutan después de que la interfaz cambie de estado, lo que elimina la carrera por completo, pero se ejecutan con los privilegios que conservó el demonio. Si OpenVPN bajó a una cuenta sin privilegios mediante user y group, el gancho se ejecuta como esa cuenta. Reiniciar un servicio del sistema entonces requiere sudo para permitir exactamente ese comando. Confíe el reintento al gestor de servicios en lugar de a un bucle de cron: una política de reinicio acotada con un límite de arranques saca a la luz un túnel roto, mientras que un bucle sin límite lo oculta indefinidamente.