O listener do OpenVPN 2.5 no DD-WRT morreu? Leia a configuração que ele gerou

Um listener morto no DD-WRT normalmente significa que o daemon saiu enquanto analisava a sua configuração, não que uma regra da firewall bloqueou a porta. OpenVPN 2.5 apertou vários valores predefinidos com que contavam as configurações mais antigas, e uma configuração gerada que funcionava numa versão anterior pode ser rejeitada antes de o socket chegar a abrir. A razão está no registo do próprio router e a entrada está no ficheiro gerado. Ler ambos nessa ordem é mais rápido do que qualquer captura de pacotes.

O daemon não é a firewall

A distinção importa porque as duas falhas parecem idênticas de fora: um cliente envia um handshake e não recebe nada. Uma é um processo que não está a correr, a outra é um processo que está a correr e a filtrar.

Separe-as com duas verificações antes de mudar seja o que for, porque editar a firewall num daemon morto só acrescenta uma segunda variável.

Leia a configuração que o DD-WRT gerou

O DD-WRT não entrega ao OpenVPN o texto que escreveu na interface web. Escreve uma configuração gerada em /tmp/openvpn/openvpn.conf e arranca o daemon com esse ficheiro, pelo que os campos da interface e qualquer texto em Additional Config são fundidos antes de o OpenVPN os ver. Se depurar o formulário em vez do ficheiro gerado, está a ler uma intenção e não a entrada real. Copie esse ficheiro para um local persistente antes de um reinício /tmp o apagar.

Compare o ficheiro gerado com o que pretendia, sobretudo onde a interface escreve uma diretiva que nunca escolheu. Um menu pendente que emite uma opção obsoleta é invisível no formulário e fatal para o daemon.

Se o ficheiro gerado estiver vazio ou faltar, o daemon nem chegou a arrancar, e o problema está a montante do OpenVPN.

O que o OpenVPN 2.5 deixou de aceitar

O OpenVPN 2.5 substituiu ncp-ciphers por data-ciphers, e subiu a versão mínima de TLS predefinida para 1.2. Também alterou o tratamento da compressão, pelo que um par que oferece compressão é recusado a menos que a configuração o permita explicitamente, e marcou como obsoletos nomes de opção mais antigos como ns-cert-type em favor de remote-cert-tls. Cada uma dessas alterações transforma uma configuração que funcionava numa falha de análise ou de negociação.

O modo de falha depende da diretiva. Uma opção desconhecida ou removida pára o daemon no arranque, é o seu listener morto. Um desalinhamento de negociação deixa o daemon correr e recusa clientes, o que do lado do cliente parece um problema de firewall.

Leia o primeiro erro do registo, não o último. A análise pára na primeira diretiva errada e tudo o que vem depois é ruído do encerramento.

Os pré-requisitos específicos do Broadcom

Nas versões para Broadcom o dispositivo de túnel tem de existir antes de o daemon o poder usar. Verifique que o módulo tun está carregado e que /dev/net/tun está presente, porque um dispositivo em falta produz uma falha de arranque que nada tem a ver com certificados. O mesmo se aplica aos scripts auxiliares que o DD-WRT gera para rotas e DNS: se faltarem ou não forem executáveis, o daemon pode arrancar e mesmo assim não concluir a configuração.

Execute o daemon em primeiro plano com mais detalhe sobre a configuração gerada quando precisar da mensagem real. Uma execução em primeiro plano imprime o erro de análise que o script init engoliu.

Depois restaure o serviço normal, porque um daemon em primeiro plano e o script init vão lutar pela porta.

Prove que o listener existe antes de depurar clientes

Confirme o processo e o socket em separado: um comando para o daemon em execução, outro para uma porta UDP ligada ao endereço esperado. Um processo sem socket significa que ainda está em configuração ou ligado à interface errada. O par é um teste útil precisamente porque uma metade não pode ser verdadeira sem a outra.

A depuração do lado do cliente só faz sentido depois de o listener existir. Verifique então se a cifra e as definições TLS do cliente correspondem à lista data-ciphers do servidor e à sua versão mínima, e se a porta é realmente reencaminhada para o router.

Guarde a configuração gerada e a linha de registo que provou a correção. A próxima atualização de firmware pode voltar a alterar os valores predefinidos, e esse registo é o que transforma uma repetição numa verificação de cinco minutos.