La VPN conecta en casa pero da tiempo de espera en el Wi-Fi del hotel
Mismo portátil, misma cuenta, otra red. Lee el código de error como una etapa, comprueba el nombre y luego captura el paquete exterior antes de cambiar cualquier ajuste.
El portátil se une al Wi-Fi de casa, el cliente conecta en tres segundos, y el mismo perfil falla en el hotel una hora después. No se actualizó nada entre medias. Recorrer esto con un cliente delante consiste sobre todo en saber qué error pertenece a qué etapa, porque la información útil está en el código que imprime el cliente, no en el hecho de que haya fallado. Sigue los cuatro pasos de abajo en orden y sabrás si te rechazó un nombre, un paquete, un puerto o una política.
Lee el código de error como una etapa, no como un veredicto
El cliente alcanza tres hitos separados antes de que exista un túnel. Resuelve el nombre del servidor, obtiene una respuesta de algo en la red y negocia una asociación de seguridad. Cada hito tiene su propio mensaje de fallo, y Windows en particular es generoso con códigos distintos una vez sabes a qué etapa pertenecen.
| What the client says | Stage that failed | First thing to run |
|---|---|---|
| 868, name did not resolve | DNS, before any packet leaves for the server | Resolve-DnsName vpn.example.net |
| 721 or 806, remote computer did not respond | Outer protocol filtered, typically GRE or UDP | A capture on the local interface |
| 809, server not responding | A device in the path is dropping the outer flow | The same capture, from a second network |
| 789, security layer error | The security exchange started and was rejected | Certificate and proposal settings on both ends |
Dos de esos códigos significan que la red es inocente. Un 789 significa que los paquetes fluían y los dos extremos no se pusieron de acuerdo sobre la criptografía, que es un problema de configuración que puedes arreglar en casa. Un 868 significa que ningún paquete necesitó salir nunca, así que el diseño del túnel es irrelevante hasta que se resuelva el nombre. Clasificar el código en la etapa correcta ahorra más tiempo que cualquier captura, porque te dice cuál de los tres pasos siguientes puedes saltarte.
Sé prudente como corresponde si el cliente no es Windows. Los clientes de terceros reducen casi todo esto a "conexión fallida", y por eso los dos pasos siguientes no dependen en absoluto del mensaje.
Comprueba el nombre antes de culpar al túnel
Las redes de hoteles y aeropuertos interceptan DNS constantemente, y un resolutor que responde con una dirección de portal produce un fallo que parece exactamente un servidor muerto. Compara lo que dice el resolutor local con lo que dice uno público:
Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"Si las dos respuestas difieren, te están redirigiendo y el resto del diagnóstico es inútil hasta que eso se resuelva. Una dirección de portal en particular aceptará encantada la conexión TCP y luego se quedará colgada, y por eso puede parecer un bloqueo de cortafuegos cuando pruebas con un navegador.
Ahora confirma que la dirección a la que quieres llegar es la que se está usando. Algunos clientes guardan en caché la resolución anterior durante toda la vida del perfil, así que una reconexión después del cambio de DNS sigue yendo a la dirección antigua. Cierra el cliente por completo antes de volver a probar, en lugar de pulsar desconectar y conectar en la misma ventana.
Averigua qué paquete exterior desaparece
El túnel tiene un flujo exterior que pertenece por completo al camino entre tú y el servidor, y es ese flujo el que los equipos intermedios clasifican y descartan. Captúralo en el cliente y luego compara una red que funciona con la que falla. En Windows la captura integrada basta para un primer vistazo:
pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etlLo que quieres ver es si tus paquetes salen siquiera y si vuelve algo. Paquetes hacia fuera sin nada de vuelta significa que el camino o el extremo lejano los descarta; que no salga nada en absoluto significa que el cliente nunca llegó a enviar, lo que apunta a la resolución de nombres o a una política local de cortafuegos.
Repite la misma prueba en un punto de acceso del móvil. Es la comparación más informativa de la que dispones, porque quita del camino cada caja del hotel mientras mantiene idénticos el portátil, el cliente y las credenciales. Si el túnel sube en el punto de acceso, deja de mirar el servidor. Si también falla allí, tienes un problema de cliente o de cuenta que la red nunca estaba causando.
Cambia un transporte y vuelve a probar
Una vez sabes que el flujo exterior se descarta, la pregunta práctica es qué flujo permite la red. La mayoría de las redes restringidas permiten TCP 443 saliente porque no podrían funcionar de otro modo, así que mover el escucha allí es la respuesta habitual. En OpenVPN eso es un interruptor del lado del cliente hasta que se cambie el servidor:
openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4Los clientes IPsec tienen un control equivalente en sus propios paneles de ajustes, normalmente descrito como IPsec sobre TCP o atravesar NAT. Cambiarlo también es un diagnóstico: si el túnel sube sobre TCP y muere sobre UDP, has demostrado que la red filtra UDP, y también has encontrado el ajuste que necesitarás cada vez que visites ese sitio.
Resiste la tentación de desactivar funciones del router al primer intento. Apagar la inspección con estado o la protección contra inundaciones en una red de hotel no está a tu alcance de todos modos, y en tu propio equipo cambia una protección real por un solo portátil. Anota qué ajuste cambió el resultado, luego vuelve a ponerlo y busca un transporte que la red ya permita.
Verifica el mismo perfil en la segunda red
Antes de cerrar el tique, demuestra que el cambio sobrevivió a salir del edificio. Reconecta en la red original con los ajustes originales, captura los primeros treinta segundos y confirma que el cliente alcanza el mismo estado que alcanzó en el punto de acceso:
pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddressLa distinción que revela el último comando merece conservarse: el perfil puede informar de un túnel conectado mientras el enrutamiento de dentro es incorrecto, y eso produce "la VPN está activa pero no funciona nada", que es otro artículo. Si el tipo de túnel cambió después de tu edición, el perfil no es el que probaste.
Luego escribe el hallazgo donde mirará la siguiente persona. "El perfil corporativo necesita TCP 443 en este sitio; el hotel filtra UDP 500" es una frase sobre la que un colega puede actuar. "La VPN va mal en los hoteles" no lo es, y garantiza que la misma hora se vuelva a gastar el mes que viene.