OpenVPN se conecta pero no pasa nada: encuentre la capa donde cae el paquete

OpenVPN dice conectado y no se mueve tráfico, una frase que cubre al menos cinco fallos no relacionados. Editar reglas del cortafuegos antes de saber qué capa falla multiplica lo desconocido y le deja un desastre al siguiente ingeniero. Trabaje mejor desde el proceso hacia fuera, porque cada paso de abajo o despeja una etapa o estrecha dónde muere el paquete. El orden importa aquí: una captura tomada antes de saber qué dirección está enlazada demostrará algo, pero no lo que usted necesita.

El socket está enlazado o no lo está

Un servicio que informa que está activo puede seguir enlazado a una dirección o un transporte que usted nunca pretendió. Consulte el propio socket: ss -lunp enumera los receptores UDP y ss -ltnp los TCP, y la columna que vale la pena leer es la dirección local, no el estado.

Una respuesta vacía suele significar una de tres cosas: el proceso salió tras arrancar, cargó otro archivo de configuración, o escucha en una dirección distinta de la que se marca.

ss -lunp | grep 1194
ss -ltnp | grep 1194

Una directiva local fija el receptor a una sola dirección, así que un cliente dirigido a otro lugar del mismo equipo es rechazado mientras el servicio desde fuera sigue pareciendo sano. Un nombre de instancia también puede apuntar a un archivo que usted nunca editó, lo que ocurre en equipos que ejecutan dos perfiles a la vez.

Capture el paquete exterior, no el túnel

Filtre en la interfaz física y el puerto real, con su propia interfaz sustituida: tcpdump -ni eth0 udp port 1194. Los paquetes salientes sin nada que regrese apuntan a lo que está aguas arriba: filtrado del proveedor, un dispositivo NAT o una dirección remota que no es la que usted cree. El silencio en ambas direcciones apunta al enrutamiento del cliente o a un cortafuegos local. Las respuestas que llegan sin avance del túnel apuntan al canal de control, es decir, a una discrepancia de clave o cifrado, no al filtrado.

Capture ambas direcciones y mantenga el archivo corto. Una captura larga entierra los tres segundos interesantes, y la respuesta casi siempre está en el primer intercambio.

Primero los contadores, traza solo cuando mienten

Empiece por los contadores, porque no cuestan nada. O bien nft list ruleset o bien iptables -L -n -v responde la única pregunta que importa aquí: ¿coincidió la regla? El orden decide el resultado, porque la primera coincidencia gana, por eso un DROP amplio antes de un ACCEPT posterior deja ese ACCEPT muerto y por eso añadir una regla tan pocas veces repara algo.

La propiedad también hace tropezar. El núcleo atribuye los paquetes generados localmente al proceso que abrió el socket, y OpenVPN normalmente se ejecuta como root, así que una regla ligada a un ID de usuario corriente nunca ve el tráfico del propio túnel. Compruebe el UID propietario antes de decidir que la regla está mal.

Solo cuando los contadores siguen ambiguos vale la pena el ruido de un registro, y aun así solo para una franja estrecha: una regla de iptables que limita la tasa y pone prefijo a sus líneas, o una regla de nftables con meta nftrace set 1 mientras nft monitor trace se ejecuta. Una traza nombra la cadena y la regla que aceptó o descartó el paquete. Retire ambas después y mantenga el registro de carga fuera.

Compruebe también el transporte. Un servicio de cortafuegos limitado a TCP no dice nada sobre un receptor UDP en ese número, así que una regla que se lee correctamente aún puede descartar cada paquete.

Enrutamiento y el camino de vuelta

Un paquete aceptado que aún desaparece necesita que se examine su camino de destino. ip route get informa la ruta elegida para una dirección, y el filtrado de ruta inversa puede descartar una respuesta que llega por una interfaz que la tabla principal nunca elegiría. El síntoma parece exactamente un descarte del cortafuegos, por eso esta comprobación va antes de otra regla NAT.

En una puerta de enlace, inspeccione el reenvío y la cadena forward en lugar de la cadena input. Luego confirme que el lado remoto sabe cómo alcanzar la dirección de origen, porque un camino de salida que funciona sin nada que vuelva es silencio en ambos casos.

Qué debe decir el registro

Para cada cambio, anote la etapa que probó, la evidencia que leyó y el valor del contador a ambos lados. Esa nota es lo que hace que "ahora funciona" sobreviva a la siguiente revisión.

Dos atajos mantienen la nota honesta. Un paquete que nunca salió del equipo no pudo ser descartado por una regla en otro lugar, por convincente que parezca la configuración del lado remoto. Un paquete que salió y volvió mueve la pregunta por encima de la capa de red, donde los contadores del cortafuegos ya no tienen nada que decirle.