¿OpenVPN en el 443 sigue bloqueado? Mira qué inspecciona la red

El túnel se conecta desde una línea doméstica y se atasca en una red de hotel u oficina, y mover el servidor al puerto 443 no cambió nada. Ese resultado es lo bastante común para tener una forma: el puerto era la parte fácil, y el resto de la decisión pertenece a todo lo que se sienta entre el cliente y el servidor. Dos preguntas resuelven la mayoría de los casos, y ninguna de ellas trata de cifrados. ¿Acepta la red un saludo TLS hacia esa dirección, y mantiene el cliente una ruta hacia su propio envoltorio mientras el túnel está levantado?

El saludo revela más que el número

Un escucha VPN nativo en TCP 443 habla su propio protocolo desde el primer paquete. Un ClientHello tiene un campo de versión, un valor aleatorio y una lista de extensiones, y un dispositivo que lee unos cientos de bytes puede notar la diferencia sin descifrar nada. Los números de puerto son baratos de satisfacer, y la forma del protocolo es lo que el filtro comprueba de verdad. Las reglas suelen escribirse también por protocolo, así que una política que inspecciona TLS no dice nada sobre UDP.

Un proxy transparente que exige una sesión TLS válida corta la conexión durante el establecimiento, a menudo después de que el saludo TCP se complete. Ese detalle importa más adelante, porque significa que el registro del cliente se detiene tras establecerse el socket.

Envolver el flujo crea dos puntos de fallo

Un envoltorio TLS como stunnel restaura la forma esperada: el cliente se conecta a un escucha local, el envoltorio abre una sesión TLS real hacia el servidor en el 443, y un segundo envoltorio en el servidor reenvía los bytes descifrados al demonio VPN. La sesión exterior ahora parece cualquier otra conexión HTTPS. El demonio VPN del servidor debería escuchar solo en loopback, porque nada fuera del envoltorio necesita alcanzarlo.

Tres cosas separadas deben alinearse para ese diseño. El perfil del cliente apunta al escucha local, el certificado del servidor coincide con el nombre que el cliente verifica, y el reenvío del lado del servidor apunta al puerto que el demonio usa de verdad. Falla cualquiera de ellas y la conexión muere antes de llegar a la capa VPN. Entonces una discrepancia de certificado aparece como error del envoltorio y no como error de VPN, y por eso vale la pena leer ambos registros uno al lado del otro.

La ruta hacia el envoltorio es la trampa

Cuando el túnel sube, la ruta por defecto apunta hacia él, y la sesión TLS exterior necesita un camino que no entre en el túnel que transporta. Un cliente VPN normal protege la dirección a la que marca; un cliente envuelto marca su propio loopback, así que la dirección de destino del envoltorio es invisible para esa protección.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Las direcciones exactas las rellenas tú, y la ruta debe existir durante toda la vida de la conexión, no solo al arrancar. Un pequeño script envoltorio que añade la ruta antes del cliente y la quita después es más fiable que un comando recordado.

En Android, el equivalente de esa excepción es un ajuste por aplicación: excluye la aplicación envoltorio del túnel para que su propio tráfico salga por la conexión móvil. Sin la exclusión, el envoltorio se enruta dentro del túnel que intenta construir, y el bucle de reconexión parece un problema del servidor.

Lee los tiempos antes de cambiar nada

Una sesión que muere tras el mismo intervalo cada vez es una firma de política y no un fallo criptográfico, y los límites de flujo de larga duración producen exactamente ese patrón. Una conexión que se reinicia justo después del saludo sugiere un proxy al que no le gustó la cadena de certificados.

Compara el emisor del certificado de un sitio HTTPS normal desde las dos redes. Si el emisor difiere en la red restringida, algo está terminando TLS en medio, y ningún envoltorio sobrevivirá a esa interceptación sin cambios. La misma comparación te dice si el bloqueo apunta al nombre de tu servidor o a cada sesión TLS en esa dirección.

Apunta el comportamiento observado: cuánto duró la sesión, si el socket se abrió, si el envoltorio registró un saludo. Cada uno de esos datos estrecha la siguiente prueba.

Prueba una variable cada vez

Comprueba primero UDP, porque algunas redes lo descartan por completo y un fallo de UDP no dice nada sobre el 443. Luego prueba TCP 443 sin el envoltorio, y después el envoltorio en el 443. Lee el registro del cliente en cada paso y detente en cuanto cambie el comportamiento.

Cambia un elemento por intento. Un puerto nuevo, un envoltorio nuevo y un cifrado nuevo en la misma tanda te dejan sin poder decir cuál de los tres importó.