VPN conectada pero un servicio falla: aísla la etapa

«Conectado» es el dato menos informativo de un ticket de VPN. Registra que dos pares completaron un handshake y nada sobre el nombre consultado, la interfaz por la que salió el paquete, su tamaño o si el extremo remoto lo aceptó. Por eso un servicio puede fallar mientras el resto de aplicaciones del mismo portátil funciona. Recorre las etapas en orden y la primera que falle nombrará la avería.

Empieza por el nombre, no por el túnel

Resuelve antes de enrutar, porque una mala respuesta vuelve inútil toda prueba posterior. Consulta el nombre con el resolutor del sistema y compara esa respuesta con la dirección que la aplicación usó realmente. Un nombre privado que vuelve como dirección pública significa que la consulta fue a un resolutor que no tiene nada que ver. Un nombre que no resuelve es la misma categoría, solo más ruidosa.

resolvectl query host.internal
getent hosts host.internal

Los navegadores con su propio ajuste de DNS seguro fallan aquí mientras el resto del sistema funciona. Por eso una queja solo del navegador pertenece primero a esta etapa, antes de que nadie toque una ruta. Compara ambos comandos y no uno, porque getent sigue la ruta NSS y la consulta al resolutor no.

Pregunta al núcleo qué camino eligió

La tabla de enrutamiento es un orden de preferencia, y el camino que elige el núcleo no siempre es el que muestra el diagrama. Pregúntale directamente por el destino en cuestión. La respuesta nombra la interfaz, el siguiente salto y la dirección de origen que se usará. Un paquete puede salir por el túnel con una dirección de origen que el extremo remoto rechaza, y una entrada más específica en la tabla física puede enviarlo por la interfaz Wi-Fi.

ip route get 10.20.30.40
ip -brief address show

Lee los campos dev, via y src en ese orden, porque cada uno descarta una sospecha distinta. Esta etapa también posee el estado que instaló el cliente, ya que las reglas de cortafuegos y las rutas pueden persistir tras una salida anormal. Por eso «sin internet sin el túnel» y «sin internet si el cliente no se ejecuta» son una misma familia de fallos, no dos.

Prueba el tamaño del paquete

Una respuesta pequeña que vuelve mientras una transferencia grande se atasca apunta primero al MTU de la ruta. Una sola sonda con el bit do-not-fragment activado, enviada desde dentro del túnel, separa esta etapa del resto. Sube la carga útil hasta que la sonda falle y tendrás el número que importa.

ping -M do -s 1400 10.20.30.40

Sondas pequeñas que pasan mientras un listado de directorio o una subida se cuelga es la firma de esta etapa. La queja suena a credenciales o a regla de cortafuegos, y no es ninguna de las dos.

El número es una propiedad de la ruta, no del cliente, así que un valor que funciona en una conexión de oficina puede fallar en un enlace móvil. Guarda el comando de sonda con el ticket, porque la siguiente persona necesita la misma medición. Si pasa una carga menor, la solución es un clamp o un MTU de túnel más bajo, no un cifrado nuevo.

Prueba el extremo remoto

Prueba el destino por su dirección y luego mira qué escucha allí. Una conexión rechazada y una conexión que nunca responde son hallazgos distintos. La primera dice que algo está arriba y no sirve ese puerto, y la segunda dice que no volvió nada. Ninguna es un problema de cliente por defecto.

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

Nada accesible por un túnel puede ser un servicio que solo escucha en 127.0.0.1, porque el oyente nunca ve el paquete. Cuando el cortafuegos del host remoto permite la subred de oficina y rechaza el grupo del túnel, el resultado parece una avería del cliente y no lo es. El escritorio remoto o el uso compartido de archivos se rompen mientras el tráfico web sobrevive; normalmente acaba aquí, diga como diga el usuario.

Asigna la queja a una etapa

La mayoría de los informes encajan en una de cinco formas, y cada forma nombra una etapa. Un sitio que solo funciona por el túnel es una respuesta de nombre o una política ligada a la dirección de origen. Las actualizaciones fallan sin el túnel mientras la navegación funciona: es un problema de nombre o de ruta para ese cliente.

Que todo se detenga al arrancar un cliente de proveedor es estado instalado, es decir, una cuestión de ruta y cortafuegos. Un servicio inalcanzable mientras el resto está bien es el extremo remoto. Las transferencias que se atascan a los pocos segundos son el tamaño del paquete. Empareja la forma antes de ejecutar comandos, porque decide qué pruebas recoger primero.

Anota la etapa que produjo el primer fallo junto con la salida del comando. Un ticket que dice que la dirección de origen era incorrecta, con la línea de ruta adjunta, merece actuación, mientras que uno que informa de la VPN como rota no.