¿VPN bloqueada en una red solo web? Trabaje las capas

Una red de campus u hotel donde el navegador funciona y cada túnel muere no es un problema, son cuatro apilados. La ruta puede permitir solo TCP 443, puede exigir un proxy autenticado, puede inspeccionar el saludo y puede simplemente prohibir el acceso remoto por política. Trabajarlos en orden evita que compre un cliente nuevo para arreglar una regla de red. El manual siguiente dura unos diez minutos y termina con una respuesta escrita sobre qué capa le rechazó.

Demuestre qué capa rechaza la conexión

No empiece por el cliente VPN. Empiece con una petición HTTPS simple al mismo host y lea las fases de tiempo, porque la fase que falla le dice qué dispositivo es el responsable:

curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect} code=%{http_code}\n' \
  --max-time 8 https://vpn.example.net/

Sin respuesta y sin tiempo connect significa que TCP nunca se completó, así que hay un cortafuegos, un requisito de proxy o un destino equivocado. Un tiempo connect sin tiempo tls significa que algo en medio aceptó la conexión y luego detuvo el saludo, y así se ve un proxy inspector desde el lado del cliente.

Ahora inspeccione el certificado que recibe de verdad. Es la forma más rápida de averiguar si habla con el servidor o con una caja intermedia que volvió a firmar la sesión:

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Lea la línea del emisor. Su propia CA significa que llegó al servicio; un emisor corporativo o de dispositivo significa que un filtro terminó la conexión y decide qué pasa después. Registre ambas salidas con una marca de tiempo, porque la misma prueba una hora después en la red de invitados puede dar otra respuesta.

Un cliente consciente del proxy cambia el primer paquete, no la política

Si la red exige CONNECT a través de un proxy autenticado, hay que decírselo al cliente VPN, o intentará abrir un socket a una dirección que no puede enrutar. Pruebe el proxy por separado del cliente, para que un fallo tenga una sola explicación:

https_proxy=http://proxy.example.edu:3128 curl -v -o /dev/null https://vpn.example.net/
sudo openvpn --config /etc/openvpn/corp.conf --proto tcp-client \
  --remote vpn.example.net 443 --verb 4

El primer comando demuestra que el proxy llevará el destino. El segundo pide al cliente usar TCP en el 443, el único transporte que la mayoría de rutas solo web reenviarán. Si el primer comando funciona y el segundo sigue fallando, el proxy no es el obstáculo.

Algunos clientes leen el proxy del sistema operativo en lugar de una anulación, y algunos no leen ninguno. Consulte la documentación de la aplicación antes de suponer que se aplica un ajuste global. Un cliente que resuelve el extremo con un resolutor que el proxy no sirve también fallará aquí, y por eso un cambio de DNS puede parecer una solución cuando solo es un desvío.

Fíjese también en el patrón de redirección mientras está en ello. Una red filtrada puede responder al nombre de detección de un proveedor con algo propio, lo que cambia qué perfil de proxy elige el cliente. No construya un proceso en torno a esa rareza. Varía por sitio, cambia sin aviso y no es algo que pueda soportar para nadie más.

El puerto 443 es alcanzable, no permitido

Envolver un túnel en TLS sobre el 443 resuelve la alcanzabilidad y nada más. Un filtro que comprueba el puerto lo dejará pasar; un filtro que toma la huella del saludo no, y el saludo cifrado del cliente solo oculta el nombre del servidor cuando ambos extremos lo soportan. Ejecute la prueba y averigüe tras qué tipo de filtro está en lugar de esperar.

También hay un coste de rendimiento que la gente descubre después. Un transporte fiable dentro de otro transporte fiable amplifica la pérdida, porque la pila interior retransmite segmentos que la pila exterior ya retransmitió. En un enlace limpio nadie lo nota. En una red inalámbrica de campus congestionada el túnel se vuelve inutilizable justo cuando lo necesita, y el gráfico parece pérdida de paquetes aunque nada se descarte a propósito.

UDP suele ser la primera víctima, y conviene confirmarlo en lugar de deducirlo. Si WireGuard o el OpenVPN por defecto nunca completa un saludo mientras TCP 443 funciona, la red está descartando UDP, y ninguna regeneración de claves lo cambiará:

sudo wg show
dig +short vpn.example.net
dig +short vpn.example.net @1.1.1.1

Una marca de tiempo de saludo vacía junto a un par que ayer funcionaba es la respuesta de UDP. Las dos consultas DNS responden otra pregunta: si el resolutor local y uno público no coinciden sobre la dirección del extremo, le están redirigiendo y el argumento del transporte es el equivocado.

Verifique qué salió realmente de la máquina

Los registros del cliente describen qué cree el cliente. Una captura describe qué vio la red, y la diferencia entre ambas es donde se resuelven la mayoría de estos casos:

sudo tcpdump -ni any -c 20 'tcp port 443 and host 203.0.113.10'
sudo ss -tunp | grep -E ':(443|1194|51820)\b'

Si ve paquetes SYN y ningún SYN-ACK, el bloqueo está aguas arriba y el cliente es inocente. Si ve un saludo completado hacia una dirección que no es la del servidor, habla con un proxy o un interceptor. Si no ve nada, compruebe que capturó en la interfaz correcta antes de concluir nada.

El listado de sockets atrapa un caso más sutil: un segundo túnel que ya tiene la ruta por defecto. Dos clientes peleando por la tabla de rutas producen fallos intermitentes que parecen exactamente una red bloqueada, y la captura mostrará tráfico saliendo por una interfaz que no esperaba.

Marcha atrás y la nota que vale la pena guardar

Deshaga los cambios en el orden inverso al que los hizo. Quite las variables de proxy, detenga el cliente que inició a mano y elimine cualquier anulación de ruta o resolutor que haya añadido:

unset https_proxy http_proxy
sudo systemctl stop openvpn-client@corp
sudo ip route show default

Dejar un cliente iniciado a mano en marcha es como un portátil acaba con una red rota en la siguiente visita a la oficina. Las variables de proxy dejadas en un perfil de shell rompen herramientas no relacionadas semanas después, y quien las depura no relacionará los dos sucesos.

Luego escriba cuatro líneas: la red, la marca de tiempo, la fase que falló y el emisor que vio. Una ruta que funciona en un campus y falla en el siguiente es normal, y la siguiente persona necesita saber si la diferencia fue el proxy, el resolutor o el filtro. Si la respuesta es que la red prohíbe el acceso remoto, pare ahí y pida al administrador la ruta soportada en lugar de llevar un rodeo a una política que no ha leído.