¿Ayuda de verdad el TCP 443? Solo si el servidor escucha ahí
Un perfil TCP es una alternativa, no un disfraz. Compruebe que el servidor escucha en ese puerto y luego valore el coste del TCP doble frente a la imposibilidad de conectar.
El TCP 443 es una alternativa con una condición previa, no un disfraz que cuela un túnel por cualquier filtro. Ayuda cuando el operador ya publica un escucha TCP en ese puerto y la ruta tolera una conexión que permanece abierta durante horas. Falla, normalmente como tiempo de espera, cuando falta una de las dos cosas, y el tiempo de espera rara vez dice cuál. Decidir si cambiar exige tres preguntas, y solo una de ellas trata del número de puerto.
Un número de puerto no es una promesa de transporte
Un puerto nombra un extremo; el TCP lo convierte en un flujo ordenado de bytes; OpenVPN decide qué viaja dentro de ese flujo. Un servidor web en el mismo número usa una disposición de aplicación completamente distinta, así que compartir el puerto 443 hace que los dos se parezcan para un filtro y nada más. El número es una pista que lee un filtro, no una propiedad que cambie lo que contienen los paquetes. Tratarlos como lo mismo porque comparten un puerto es el error que hay detrás de la mayor parte de la confusión.
Los equipos intermedios rara vez toman una decisión simple de permitir o denegar sobre un puerto. Muchos inspeccionan los primeros bytes, algunos fijan un destino y algunos reinician conexiones que permanecen abiertas demasiado tiempo. Por eso el mismo perfil puede funcionar desde una red y agotarse desde otra, y por eso vale la pena probar la alternativa como una opción soportada en lugar de confiar en ella como una promesa. Cuando un filtro examina el tráfico, el número de puerto es solo lo primero que mira.
Confirme el escucha antes de tocar el perfil
El servidor tiene que estar configurado para TCP en el puerto, y el perfil del cliente tiene que pedir el mismo transporte. Reescribir un perfil UDP para que pida TCP no crea el escucha, y el tiempo de espera resultante no se distingue de un cortafuegos que descarta el puerto. Descargue el perfil TCP propio del operador cuando exista, porque algunos servicios publican un extremo y unos ajustes de identidad separados para cada transporte. Editar a mano va bien para una prueba controlada y es una mala forma de adivinar la configuración que pretendía el proveedor.
Los dos lados de esa correspondencia aparecen en la configuración, y las opciones de enlace del proyecto OpenVPN documentan las dos formas. El par mínimo tiene este aspecto:
# server: accept TCP on this port
proto tcp-server
port 443
# client: request the same transport
proto tcp
remote vpn.example.com 443Tres condiciones deciden si la alternativa compensa
La primera condición es que el operador ofrezca el transporte siquiera; sin eso, nada más importa. La segunda es que la ruta mantenga viva una sesión de larga duración, ya que algunas redes reinician conexiones que permanecen abiertas en vez de bloquear el puerto de plano. La tercera es si la alternativa es una excepción deliberada o un apaño que oculta una avería que no ha corregido.
Cada condición tiene una comprobación barata. Un fallo en cualquiera de ellas se ve igual desde el cliente:
| Condition | How to check it | What a failure decides |
|---|---|---|
| The server offers TCP | The operator's profile list, or a listening-socket check on the server | No client-side edit can help |
| The path keeps long sessions | A test connection left open for an hour | Reconnects will look like server faults |
| The fallback is deliberate | A change record naming the UDP fault | The underlying fault stays invisible |
Antes de comparar transportes, complete cualquier inicio de sesión en un portal cautivo. Una red que no ha admitido su dispositivo bloquea ambos transportes, y entonces la comparación mide el portal y no el túnel. Inicie sesión, confirme que la navegación normal funciona y solo después empiece la prueba.
El coste que acepta: TCP dentro de TCP
El TCP retransmite los segmentos perdidos y conserva su orden. Cuando una aplicación que también usa TCP corre dentro de un túnel TCP, dos capas de recuperación reaccionan a la misma pérdida, y esa interacción es lo que hace que el túnel se sienta lento en una ruta con pérdidas. El síntoma es retardo y jitter más que un fallo limpio, lo que facilita culpar al extremo lejano. Mida desde el cliente con ambos transportes antes de sacar conclusiones.
El UDP evita ese anidamiento, y es la razón principal por la que los operadores lo prefieren y ofrecen TCP solo como alternativa. Una conexión TCP estable sigue siendo más útil que una UDP inalcanzable, así que la comparación es entre dos costes reales y no entre una opción buena y una mala. Mantenga el dispositivo y la red de acceso sin cambios mientras compara, o el resultado describirá la variable equivocada.
Algunas funciones del cliente están documentadas solo para un transporte, así que un perfil alternativo puede dejar caer en silencio un comportamiento del que dependía. Lea el requisito de transporte de la opción antes de tratar el perfil TCP como un simple cambio.
Averías que otro transporte no toca
Un certificado caducado sigue necesitando una comprobación del reloj o una renovación, y una cuenta rechazada sigue necesitando las credenciales correctas. Mantenga las comprobaciones de identidad del servidor que entregó el operador, porque un número de puerto familiar no autentica a nadie. Un puerto que responde solo dice que algo está escuchando.
Si el túnel sube y los destinos siguen fallando, el problema restante es el enrutamiento o la resolución de nombres después de la conexión, no el transporte. Siga ese camino en vez de dar vueltas por los puertos, que es como se pierde una tarde. El perfil le dice qué transporte probar; nunca le dice por qué falló la ruta UDP.