UDP no siempre es más rápido: elegir el transporte de OpenVPN

Todas las guías dicen que UDP supera a TCP para OpenVPN, y ese consejo es un valor predeterminado, no una medición. El transporte cambia cómo se entregan los paquetes y qué ocurre cuando la ruta los descarta, no cómo se cifra el túnel. Detrás de un portal cautivo o un proxy que solo permite el puerto 443, la opción más lenta es la que se conecta siquiera. Lo que sigue separa lo que hace el protocolo de lo que permite tu red de acceso.

Qué cambia realmente el transporte

TCP entrega un flujo de bytes fiable y ordenado y retransmite todo lo que se pierde, como especifica la RFC 9293. UDP entrega datagramas a la red, y OpenVPN ejecuta su propia capa de fiabilidad sobre ese socket. Encapsular TCP dentro de TCP apila dos bucles de recuperación, así que un solo segmento perdido puede retener el flujo interno hasta que llega la retransmisión exterior. Esa interacción es el argumento real a favor de UDP, y aparece como latencia en lugar de como caudal.

El efecto crece con las pérdidas y el tiempo de ida y vuelta. En una ruta local limpia ambos transportes se sienten idénticos, por eso una prueba de laboratorio rara vez reproduce la queja. En un enlace móvil congestionado la diferencia se nota en sesiones interactivas mucho antes de que una transferencia grande advierta nada.

Nada de esto toca la confidencialidad ni la integridad. El handshake TLS y el cifrado del canal de datos son los mismos para ambos transportes, así que cambiar no puede salvar una suite de cifrado débil.

Dónde se gana TCP su sitio

Las redes de acceso son la razón habitual para elegir TCP. Un hotel, un aeropuerto o una red de invitados pueden permitir el 443 saliente y descartar todo lo demás, y un oyente TCP en ese puerto es el único perfil que funciona. Eso es accesibilidad, no rendimiento, y es una razón suficientemente buena por sí sola.

TCP también ayuda cuando la ruta es estable pero los equipos intermedios son hostiles. Algunas redes reinician flujos UDP de larga duración mientras toleran sesiones TCP que parecen tráfico web normal. Que ese parecido tenga éxito es una propiedad de la red concreta, y ninguna guía puede prometerlo para todas. Prueba dentro de la red que falla antes de culpar al protocolo.

Un inicio de sesión rechazado no es un problema de transporte. Desactivar la verificación del certificado para forzar una conexión es otro cambio con un resultado mucho peor.

Tener un perfil TCP listo es el compromiso práctico. La mayoría de los clientes guardan ambos y te dejan cambiar cuando una red rechaza la ruta UDP, lo que no cuesta nada hasta que lo necesitas. Lo que no deberías hacer es distribuir dos perfiles apuntando a puntos finales distintos, porque entonces tu comparación mide los servidores.

Comprueba qué oyente tienes realmente

Antes de comparar el rendimiento, confirma que ambos extremos coinciden en el transporte y el puerto. Cambiar proto udp por proto tcp en un archivo de cliente no crea un oyente en el servidor. El servidor debe estar configurado para ese protocolo, y el perfil debe coincidir con él.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep imprime lo que se le dijo al servidor que usara, mientras que los dos listados de sockets muestran a qué está vinculado. Un oyente UDP solo aparece en el primer listado y un oyente TCP solo en el segundo, así que una línea ausente es la forma más rápida de encontrar un perfil que nunca se aplicó. Compara también el puerto, porque un perfil TCP en 1194 se comporta de forma distinta a uno en 443 en la mayoría de las redes de acceso. Reinicia el servicio después del cambio y lee la línea del registro que informa del enlace.

La confirmación del lado del cliente es barata: ejecuta la conexión con --verb 4 y lee la línea de transporte del registro. Si el cliente dice UDP mientras el servidor escucha en TCP, el handshake nunca comienza y ningún ajuste ayudará.

Compara la carga de trabajo, no la etiqueta del transporte

Una comparación justa mantiene todo constante salvo el transporte. El mismo dispositivo, la misma red de acceso, el mismo host de destino, la misma aplicación e, idealmente, el mismo servidor. Si los dos perfiles apuntan a hosts distintos, también estás midiendo esos hosts.

Registra tres resultados por ejecución: si el túnel se establece, si se mantiene y si la tarea se completa. Las solicitudes pequeñas que funcionan mientras las transferencias grandes se atascan apuntan al tamaño de paquete y al MTU, no al transporte. Las reconexiones repetidas apuntan a la ruta o a un tiempo de espera de un equipo intermedio.

Conserva el perfil que funciona en las condiciones que realmente encuentras y guarda el otro. La elección pertenece a la red, no a la persona, y por eso cualquier respuesta predeterminada única falla en algún lugar.