OpenVPN funciona en casa pero no en una red: ¿UDP o TCP?

El mismo perfil conecta desde casa y se atasca en una red de hotel, campus o sucursal. Las credenciales no cambiaron, así que la variable interesante es la ruta: qué pasa con los paquetes antes de que OpenVPN los lea. Comparar cuatro causas candidatas en el orden en que se pueden probar supera a adivinar sobre certificados. Cada una deja un rastro distinto, y el rastro es lo que las separa.

Qué etapa falló dice qué comparación importa

El registro del cliente ya anota hasta dónde llegó. Una línea que dice que la negociación de clave TLS no ocurrió dentro del plazo significa que un primer paquete salió y no volvió nada usable, lo que apunta a la ruta. El rechazo de un certificado se ve muy distinto: llega una respuesta y luego un error de verificación concreto nombra la causa. Fíjese en la última línea antes del bucle de reintentos, porque ese es el valor que compara entre redes.

Capture mientras reintenta, no después. En el cliente, tcpdump -ni any udp port 1194 muestra si vuelve alguna respuesta. Repítalo en la interfaz WAN de un servidor que controle, lo que revela si esos paquetes llegan del todo al extremo remoto.

El tráfico de un solo lado es el resultado más útil disponible aquí, porque convierte una queja intermitente en una dirección donde investigar. Guarde los archivos de captura, porque el siguiente informe del mismo problema se cierra más fácil con pruebas que con una descripción.

Filtrado UDP frente a un puerto cerrado

Muchas redes de acceso consideran sospechoso el UDP sostenido, y algunos proveedores están de acuerdo. Un puerto cerrado produce el mismo silencio desde el lado del cliente. La diferencia es la selectividad: un filtro tiende a ser exigente sobre qué destinos o puertos descarta, mientras que un puerto cerrado rechaza todo lo dirigido a ese único puerto.

Un perfil TCP en el puerto 443 es el rodeo habitual, porque se parece a un flujo HTTPS normal y pasa la mayoría de portales cautivos y filtros de salida. Deben cumplirse dos condiciones. El servidor debe escuchar con proto tcp-server y el cliente debe coincidir con proto tcp-client, y el operador tiene que publicar ese extremo alternativo. Reescribir un perfil UDP que funciona para declarar TCP 443 no lleva a ninguna parte cuando al otro lado no escucha nadie.

Un puerto cerrado es un problema de configuración y no de censura. Un servidor detrás de un router doméstico necesita que se reenvíe su puerto UDP, y el cortafuegos del router debe permitirlo. Cuando el puerto nunca se permitió, todos los clientes fallan en la negociación sin importar las credenciales, y el fallo sigue al servidor en vez de a la red.

Los protocolos más antiguos salen mal parados en este eje. PPTP necesita TCP 1723 más GRE, y GRE es el protocolo IP 47 y no un puerto, así que ningún reenvío de puerto corriente lo expresa.

Cuando es el conmutador el que descarta paquetes

Un conmutador gestionado puede descartar el túnel a propósito. Algunos modelos HPE y Aruba ofrecen un control de protección contra inundaciones UDP, a veces etiquetado Prevent UDP Blat Attack, en su sección de seguridad avanzada. Una vez que ese control está activo, un servidor detrás del conmutador no responde nada y todos los clientes agotan el tiempo de la misma forma. Desactivarlo y guardar la configuración en curso es toda la reparación, pero solo después de establecer que el conmutador está realmente en la ruta.

Las pruebas contrarias son lo que separa un descarte del conmutador de un bloqueo del proveedor. Lea los contadores de la interfaz y el registro de protección contra inundaciones antes de abrir un tique con el proveedor. Los routeres domésticos con protección DoS o contra inundaciones fallan de la misma forma, y también cualquier dispositivo intermedio con un tiempo de inactividad UDP corto. Un handshake que nunca se completa sugiere un descarte, mientras que un túnel que muere tras minutos de silencio sugiere el tiempo de espera.

Anote cada dispositivo entre el cliente y el servidor antes de cambiar un perfil. Una corrección aplicada en la capa equivocada parece correcta hasta la siguiente red. Esa lista también dice al siguiente ingeniero dónde mirar sin repetir toda la investigación.

Un solapamiento de direcciones que parece un fallo de DNS

Una red de acceso numerada dentro de 10.0.0.0/8 puede solaparse con el grupo del túnel, y el resolutor suele vivir dentro de ese grupo. Cuando un portátil recibe una dirección como 10.184.178.50 con una máscara /8 en la Wi-Fi, todo destino 10.x es local por definición. Los paquetes para 10.4.0.1 van entonces a la LAN, el túnel sigue arriba y la resolución de nombres falla.

ip addr expone el solapamiento de un vistazo, y ip route get 10.4.0.1 muestra dónde se entregaría realmente el paquete. Como el síntoma visible es un fallo del resolutor, este caso a menudo sobrevive a varias rondas de cambios de DNS.

Renumere el grupo o mantenga esa red de acceso fuera del alcance. Ningún ajuste del lado del cliente se recupera de un solapamiento.

Decidir entre un TCP alternativo y una corrección de la ruta

Elija el TCP alternativo cuando no controle la ruta y los usuarios necesiten trabajar hoy, y acepte sus costes: TCP dentro de TCP se comporta mal en enlaces con pérdidas, y el alternativo necesita un oyente que usted opere. Elija la corrección de la ruta cuando el bloqueo esté en infraestructura que usted posee, porque una regla de cortafuegos es más barata que un segundo oyente. En cualquier caso, recorra las capas en orden: enlace, transporte externo, negociación, enrutamiento interno. La etapa que falló en esa red es el único hecho que importa.

Registre el resultado por red y no por usuario. El siguiente informe del mismo fallo empieza entonces en una etapa conocida en lugar de una teoría sobre certificados. Ese registro es también lo que justifica un segundo oyente permanente, si alguna vez hace falta.