¿El listener de OpenVPN 2.5 en DD-WRT está muerto? Lee la configuración que generó

Un listener muerto en DD-WRT suele significar que el demonio terminó mientras analizaba su configuración, no que una regla del cortafuegos bloqueara el puerto. OpenVPN 2.5 endureció varios valores predeterminados en los que se apoyaban configuraciones anteriores, y una configuración generada que funcionaba en una versión anterior puede rechazarse antes de que el socket llegue a abrirse. El motivo está en el registro del propio router y la entrada está en el archivo generado. Leer ambos en ese orden es más rápido que cualquier captura de paquetes.

El demonio no es el cortafuegos

La distinción importa porque los dos fallos se ven idénticos desde fuera: un cliente envía un handshake y no recibe nada. Uno es un proceso que no se ejecuta y el otro es un proceso que se ejecuta y filtra.

Sepáralos con dos comprobaciones antes de cambiar nada, porque editar el cortafuegos sobre un demonio muerto solo añade una segunda variable.

Lee la configuración que generó DD-WRT

DD-WRT no le entrega a OpenVPN el texto que escribiste en la interfaz web. Escribe una configuración generada en /tmp/openvpn/openvpn.conf y arranca el demonio con ese archivo, así que los campos de la interfaz y cualquier texto de Additional Config se fusionan antes de que OpenVPN los vea. Si depuras el formulario en lugar del archivo generado, lees una intención y no la entrada real. Copia ese archivo a un lugar persistente antes de que un reinicio /tmp lo borre.

Compara el archivo generado con lo que pretendías, sobre todo donde la interfaz escribe una directiva que nunca elegiste. Un desplegable que emite una opción obsoleta es invisible en el formulario y fatal para el demonio.

Si el archivo generado está vacío o falta, el demonio ni siquiera llegó a arrancar y el problema está por encima de OpenVPN.

Qué dejó de aceptar OpenVPN 2.5

OpenVPN 2.5 reemplazó ncp-ciphers por data-ciphers, y elevó la versión mínima de TLS predeterminada a 1.2. También cambió el tratamiento de la compresión, de modo que se rechaza a un par que ofrece compresión salvo que la configuración lo permita explícitamente, y marcó como obsoletos nombres de opción más antiguos como ns-cert-type en favor de remote-cert-tls. Cada uno de esos cambios convierte una configuración que antes funcionaba en un fallo de análisis o de negociación.

El modo de fallo depende de la directiva. Una opción desconocida o eliminada detiene el demonio al arrancar, ese es tu listener muerto. Un desajuste de negociación deja correr el demonio y rechaza a los clientes, lo que desde el lado del cliente parece un problema de cortafuegos.

Lee el primer error del registro, no el último. El análisis se detiene en la primera directiva incorrecta y todo lo que sigue es ruido del apagado.

Los requisitos previos específicos de Broadcom

En las compilaciones para Broadcom el dispositivo de túnel debe existir antes de que el demonio pueda usarlo. Comprueba que el módulo tun esté cargado y que /dev/net/tun esté presente, porque un dispositivo ausente produce un fallo de arranque que no tiene nada que ver con los certificados. Lo mismo vale para los scripts auxiliares que DD-WRT genera para rutas y DNS: si faltan o no son ejecutables, el demonio puede arrancar y aun así no terminar su configuración.

Ejecuta el demonio en primer plano con más detalle sobre la configuración generada cuando necesites el mensaje real. Una ejecución en primer plano imprime el error de análisis que el script init se tragó.

Después restaura el servicio normal, porque un demonio en primer plano y el script init se pelearán por el puerto.

Demuestra que el listener existe antes de depurar clientes

Confirma el proceso y el socket por separado: una orden para el demonio en ejecución y otra para un puerto UDP vinculado a la dirección esperada. Un proceso sin socket significa que aún está configurándose o vinculado a la interfaz equivocada. La pareja es una prueba útil justo porque una mitad no puede ser cierta sin la otra.

La depuración del lado del cliente solo tiene sentido después de que exista el listener. Entonces comprueba que el cifrado y los ajustes TLS del cliente coincidan con la lista data-ciphers del servidor y su versión mínima, y que el puerto se reenvíe realmente al router.

Guarda la configuración generada y la línea de registro que demostró la corrección. La próxima actualización de firmware puede cambiar otra vez los valores predeterminados, y ese registro es lo que convierte una repetición en una comprobación de cinco minutos.