O listener de OpenVPN 2.5 en DD-WRT está morto? Le a configuración que xerou

Un listener morto en DD-WRT adoita significar que o daemon saíu mentres analizaba a súa configuración, non que unha regra da devasa bloqueara o porto. OpenVPN 2.5 endureceu varios valores por defecto nos que se apoiaban configuracións anteriores, e unha configuración xerada que funcionaba nunha versión anterior pode ser rexeitada antes de que o socket chegue a abrirse. O motivo está no rexistro do propio router e a entrada está no ficheiro xerado. Ler ambos nesa orde é máis rápido que calquera captura de paquetes.

O daemon non é a devasa

A distinción importa porque os dous fallos vense idénticos desde fóra: un cliente envía un handshake e non recibe nada. Un é un proceso que non se executa e o outro é un proceso que se executa e filtra.

Sepáraos con dúas comprobacións antes de cambiar nada, porque editar a devasa sobre un daemon morto só engade unha segunda variable.

Le a configuración que xerou DD-WRT

DD-WRT non lle entrega a OpenVPN o texto que escribiches na interface web. Escribe unha configuración xerada en /tmp/openvpn/openvpn.conf e arrinca o daemon con ese ficheiro, así que os campos da interface e calquera texto de Additional Config fusiónanse antes de que OpenVPN os vexa. Se depuras o formulario en lugar do ficheiro xerado, les unha intención e non a entrada real. Copia ese ficheiro a un lugar persistente antes de que un reinicio /tmp o borre.

Compara o ficheiro xerado co que pretendías, sobre todo onde a interface escribe unha directiva que nunca escolliches. Un despregable que emite unha opción obsoleta é invisible no formulario e fatal para o daemon.

Se o ficheiro xerado está baleiro ou falta, o daemon nin sequera chegou a arrincar e o problema está por riba de OpenVPN.

Que deixou de aceptar OpenVPN 2.5

OpenVPN 2.5 substituíu ncp-ciphers por data-ciphers, e elevou a versión mínima de TLS por defecto a 1.2. Tamén cambiou o tratamento da compresión, de xeito que se rexeita a un par que ofrece compresión salvo que a configuración o permita explicitamente, e marcou como obsoletos nomes de opción máis antigos como ns-cert-type en favor de remote-cert-tls. Cada un deses cambios converte unha configuración que antes funcionaba nun fallo de análise ou de negociación.

O modo de fallo depende da directiva. Unha opción descoñecida ou eliminada detén o daemon ao arrincar, ese é o teu listener morto. Un desaxuste de negociación deixa correr o daemon e rexeita os clientes, o que desde o lado do cliente parece un problema de devasa.

Le o primeiro erro do rexistro, non o último. A análise detense na primeira directiva incorrecta e todo o que segue é ruído do apagado.

Os requisitos previos específicos de Broadcom

Nas compilacións para Broadcom o dispositivo de túnel debe existir antes de que o daemon poida usalo. Comproba que o módulo tun estea cargado e que /dev/net/tun estea presente, porque un dispositivo ausente produce un fallo de arrinque que non ten nada que ver cos certificados. O mesmo vale para os scripts auxiliares que DD-WRT xera para rutas e DNS: se faltan ou non son executables, o daemon pode arrincar e aínda así non rematar a súa configuración.

Executa o daemon en primeiro plano con máis detalle sobre a configuración xerada cando necesites a mensaxe real. Unha execución en primeiro plano imprime o erro de análise que o script init tragou.

Despois restaura o servizo normal, porque un daemon en primeiro plano e o script init pelexarán polo porto.

Demostra que o listener existe antes de depurar clientes

Confirma o proceso e o socket por separado: unha orde para o daemon en execución e outra para un porto UDP vinculado ao enderezo esperado. Un proceso sen socket significa que aínda se está configurando ou vinculado á interface equivocada. A parella é unha proba útil xusto porque unha metade non pode ser certa sen a outra.

A depuración do lado do cliente só ten sentido despois de que exista o listener. Entón comproba que o cifrado e os axustes TLS do cliente coincidan coa lista data-ciphers do servidor e a súa versión mínima, e que o porto se reenvíe realmente ao router.

Garda a configuración xerada e a liña de rexistro que demostrou a corrección. A próxima actualización de firmware pode cambiar outra vez os valores por defecto, e ese rexistro é o que converte unha repetición nunha comprobación de cinco minutos.