¿VPN conectada pero sin internet? Revisa las cuatro capas

El cliente dice conectado, el navegador gira y cada sitio termina en un tiempo de espera. Esa combinación es habitual y no es una contradicción: conectado significa que el túnel negoció, y nada más. La resolución de nombres, el enrutamiento y la propia salida del servidor fallan cada uno a su manera, y cada uno tiene un dueño distinto. Recorre las capas en orden y detente en la primera que falle.

Empieza por la red de la que vienes

Baja el túnel con el propio control de desconexión del cliente y luego prueba dos sitios HTTPS no relacionados si la política lo permite. Deja el trabajo sensible cerrado durante esa prueba. Si el acceso normal también falla, la VPN no es el primer sospechoso.

Mira el enlace Wi-Fi, el router y cualquier página de portal que exija iniciar sesión antes de tocar el túnel. Un kill switch puede bloquear el tráfico mientras estás desconectado por diseño, así que sigue su procedimiento de prueba documentado en lugar de concluir que la red está muerta. Otra red de confianza es una comparación útil, y una salida VPN nueva no completará un inicio de sesión de hotel caducado. Si la red abierta funciona y el túnel no, la red queda exonerada y la siguiente capa es tuya.

Decide si el fallo es de resolución de nombres

Apunta el texto del error, porque un fallo de resolución, un tiempo de espera y un aviso de certificado apuntan cada uno a otro lugar. El patrón que hay que detectar pronto es un nombre de host que nunca has visitado fallando mientras una aplicación con sesión abierta sigue funcionando. Ese patrón trata de consultas nuevas, no de si el túnel transporta paquetes. Una sola consulta muestra qué devuelve el resolutor y tarda un segundo. Prueba también un segundo nombre, para que una respuesta en caché o un registro roto no decidan el diagnóstico.

nslookup example.com

Una IP arbitraria en la barra de direcciones HTTPS no es una prueba de DNS, porque el certificado y el host virtual suelen depender del nombre. Los nombres internos pueden necesitar el resolutor de la organización en lugar de un sustituto público, y un navegador con su propio resolutor seguro puede responder distinto de la consulta del sistema operativo. Cuando ambos discrepan, el resolutor del navegador es el que experimenta el usuario, y esa distinción pertenece al tique.

¿Túnel completo o solo subredes de la empresa?

Algunos perfiles existen solo para llegar a un puñado de subredes de la empresa; otros están hechos para transportarlo todo y necesitan una salida funcional detrás. Lee la finalidad documentada antes de suponer que el indicador cubre cada aplicación y cada familia de direcciones. Un perfil de red privada puede funcionar exactamente como se diseñó mientras el navegador, que nunca debió usarlo, sigue fallando. Lee la tabla de rutas sin cambiarla e incluye IPv6, porque una ruta IPv4 que funciona no dice nada de la otra familia.

Una ruta más específica puede ganar mientras la ruta predeterminada aún existe, y por eso la tabla debe leerse en lugar de suponerse. Los adaptadores virtuales competidores también pueden poseer tráfico que esperabas en otro sitio, sobre todo después de instalar y olvidar un segundo cliente VPN. No borres la ruta predeterminada como experimento; eso convierte un diagnóstico en una segunda caída.

Un solo sitio que falla entre los que funcionan es un problema de ese sitio, y también demuestra que el túnel transporta tráfico. Las paradas que solo aparecen en transferencias grandes apuntan al tamaño del paquete y no a la accesibilidad.

Cuando el servidor nunca reenvía nada

Si todo destino falla en dos dispositivos y dos redes de acceso, el túnel está levantado y la salida no reenvía. Ese emparejamiento es lo que separa un fallo del lado del servidor de un dispositivo mal configurado en un solo lugar. Envía al operador las preguntas de reenvío, NAT y ruta de retorno, no una captura del indicador.

Esas tres cubren la mayoría de causas del lado del servidor, y responderlas es cosa del operador. La página de solución de problemas de conectividad de OpenVPN recorre las mismas preguntas desde el lado del servidor, así que pásala con el tique. Una captura de un indicador verde no responde a ninguna.

Revisa el registro del cliente después del inicio de sesión por fallos al aplicar rutas, ajustes de DNS o el adaptador virtual. Los errores en esa etapa apuntan al dispositivo y no al servidor. Un error que nunca aparece en el registro es igual de informativo, porque mueve la sospecha al otro lado.

Comprueba una capa a la vez

En cuanto cambies algo, vuelve a conectarte y repite exactamente la aplicación que falló. Una sola página que carga demuestra menos que una ruta repetible a los recursos para los que se construyó el perfil. Dos comandos separan la resolución de la accesibilidad, y el segundo es específico del host. Ejecuta la línea curl en cualquier sitio y luego el comando de rutas que corresponda al host que tienes delante.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Si la petición numérica funciona y el nombre no, quédate en DNS. Si no funciona ninguna, compara la tabla de rutas con el valor predeterminado esperado del túnel y comprueba la familia que estás probando en realidad. Si la ruta es correcta y la petición sigue muriendo en la salida, la pregunta restante es del operador, y la evidencia que guardaste es el tique.