proto udp o tcp-client: ¿cuál escucha tu servidor?

Un perfil que funcionaba el mes pasado ahora se agota y alguien propone cambiar proto udp por proto tcp-client. A veces es el paso correcto, y a veces produce un cliente que se conecta a un puerto donde nada escucha, porque el servidor nunca se configuró para el otro transporte. La directiva describe cómo habla tu extremo; no puede crear un oyente en el extremo opuesto. Lee el perfil y el servidor juntos antes de cambiar cualquiera de los dos.

Lee el transporte que usa la conexión seleccionada

Un perfil puede llevar varias entradas remote, y cada una puede indicar su propio transporte. El cliente las recorre en orden, así que la línea que ves primero no es necesariamente la que se aplica.

Encuentra la entrada que realmente se está probando y luego lee su transporte. El orden importa, porque el cliente no pasa a la siguiente en silencio. Algunas compilaciones prueban la entrada siguiente solo tras un tiempo de espera, así que una alternativa que funciona al final del archivo se alcanza unos segundos más tarde de lo que esperas. Vigila en el registro qué extremo se está intentando en lugar de suponer que ganó la primera línea.

Si el archivo tiene una línea proto cerca de arriba y varias entradas remote debajo, esa línea es el valor predeterminado para cualquier remote que no la anule. Una edición local del valor predeterminado no hace nada por una entrada remote que indica su propio transporte.

grep -nE '^(remote|proto)\b' client.ovpn

UDP y TCP no son un ajuste de velocidad

UDP envía datagramas sin construir un flujo ordenado, así que el tráfico propio del túnel no se envuelve dentro de un segundo transporte fiable. TCP te da un camino a través de redes que descartan o bloquean UDP, a cambio de una retransmisión anidada que puede hacer que un enlace con pérdidas se sienta peor.

Es un intercambio de alcanzabilidad, no una clasificación universal. La elección correcta es la que permite la red frente al cliente. Un camino que descarta UDP en el puerto VPN nunca negociará, por bien escrito que esté el perfil. Prueba el camino y luego elige el transporte.

Elegir entre ellos solo por una medición es un error, porque la respuesta depende de lo que permita la red que tienes delante. Un hotel o un proxy corporativo puede permitir TCP de salida en el 443 y nada más, y por eso los proveedores ofrecen esa variante. Sigue siendo una conexión OpenVPN en ese puerto, no una sesión HTTPS, aunque el número de puerto sea el conocido.

Qué significa realmente tcp-client

La directiva del lado del cliente nombra el extremo que inicia una conexión TCP. El lado del servidor usa su propia forma de escuchar, y copiar la palabra del cliente en una configuración de servidor produce un oyente que espera que lo llamen, no uno que acepta.

Coincidir significa que ambos extremos acuerdan el transporte, no que compartan la misma cadena.

grep -nE '^proto\b' /etc/openvpn/server/server.conf
ss -lntp | grep openvpn

Pregunta al servidor qué escucha antes de suponer que el perfil está mal. Un oyente UDP no aparece en un listado de sockets TCP, y lo contrario también es cierto, así que mira la vista específica del protocolo en lugar de una genérica.

Cuando el perfil se importa pero nunca conecta

Un perfil importado que se agota de inmediato suele fallar antes de cualquier autenticación. El paquete va a un puerto sin oyente, o la red lo descarta en silencio.

Prueba el camino de la forma más simple posible: conéctate al mismo host y puerto con el transporte que afirma el perfil, desde la misma red que el cliente que falla.

Si una prueba UDP no obtiene nada y una prueba TCP conecta, el servidor ofrece el otro transporte y el perfil simplemente está desactualizado. Si ninguna responde, el problema está por encima de la elección de transporte y ninguna edición del perfil lo arreglará. Distinguir esos dos casos lleva un minuto y ahorra una hora de depuración de certificados que nunca fue relevante.

Anota el transporte que funciona

Cuando una combinación funcione, anótala con el servidor, el puerto y el protocolo, e indica desde qué red se probó.

De lo contrario, la siguiente persona que se tope con un tiempo de espera repetirá el mismo experimento en la otra dirección y quizá cambie un servidor que estaba bien.

Si el proveedor publica ambas variantes, conserva los dos archivos y etiquétalos según la red a la que van bien. Dos perfiles con nombres claros evitan la mezcla accidental de un transporte de cliente con un oyente de servidor que nunca se configuró para él.