OpenVPN: o bind local falha na inicialização — esperar ou tentar novamente

Para um servidor OpenVPN que não arranca, oferecem-se duas correções: esperar pelo endereço ou deixar o serviço tentar novamente até o bind ter sucesso. Ambas tratam o mesmo sintoma com comportamento de falha diferente. A espera codifica um pré-requisito concreto e falha ruidosamente quando ele falta; a repetição esconde o pré-requisito e continua a tentar. Qual delas pertence à sua unit depende de o endereço ser uma dependência projetada ou um acaso de temporização.

Ambas são melhores do que um sono fixo, que não espera por nada nem relata o que estava à espera.

O que a opção local realmente exige

local nomeia o endereço ao qual o daemon associa o seu socket, e associar a um endereço que ainda não existe falha imediatamente com um erro sobre o endereço pedido. Quando a opção está ausente, o daemon escuta em todos os endereços, e é por isso que o mesmo perfil funciona numa máquina cuja interface ainda não subiu: está a escutar em todo o lado em vez do único endereço que indicou. Essa diferença é toda a falha, e permanece invisível até um reinício.

O requisito não é que a interface esteja ativa num sentido geral. O endereço tem de estar atribuído à interface correta no momento do bind, e tem de ser a interface subjacente e não um túnel que o mesmo daemon criaria mais tarde. Uma verificação feita minutos depois do login não prova nada sobre a sequência de arranque.

Esperar pelo endereço ou repetir o bind

Esperar significa um ExecStartPre que inquire até o endereço aparecer, com um número limitado de tentativas e uma saída diferente de zero quando o tempo termina. Repetir significa deixar o processo principal falhar e pedir ao gestor de serviços que o reinicie, por exemplo Restart=on-failure com RestartSec=5. O primeiro relata um pré-requisito em falta como uma unit falhada, enquanto o segundo o relata como uma série de reinícios que acabam por parar, o que é mais ruidoso no registo mas sobrevive a um endereço que chega tarde por razões que não consegue prever.

Prefira a espera quando o endereço é uma dependência projetada, e a repetição quando o endereço normalmente aparece mas a temporização varia. Combiná-las é razoável: uma espera limitada cobre o caso comum e uma política de reinício a exceção. O que nenhuma deve fazer é correr para sempre, porque uma unit que repete indefinidamente esconde uma má configuração em vez de a relatar.

Porque network-online.target não basta

network-online.target promete o que a implementação de rede ativa entende por online, e nada mais. Com systemd-networkd, systemd-networkd-wait-online decide quando esse objetivo é atingido, e a sua noção predefinida de online pode estar satisfeita antes de o seu endereço específico existir. No NetworkManager, o serviço wait-online aplica as suas próprias regras. Ordenar depois do objetivo é uma base sólida, não uma garantia de que um endereço, uma resposta DNS ou um par remoto esteja pronto.

O mesmo raciocínio descarta as alternativas habituais. Uma entrada de arranque automático do ambiente de trabalho espera por uma sessão de utilizador que pode nunca abrir num servidor, e um comando cron atrasado acrescenta tempo decorrido sem nomear o recurso cujo aparecimento esperava. Ambas podem parecer bem-sucedidas durante meses e depois falhar no único arranque que importa.

Verifique o bind depois de um arranque a frio

Verifique com um arranque a frio real em vez de um reinício do serviço, porque um reinício herda um endereço que a sequência de arranque teve de criar. Após o arranque, ss -lntp ou ss -lunp mostra o endereço local ao qual cada ouvinte realmente se associou, e journalctl -b -u openvpn-server@server mostra se a primeira tentativa falhou. Compare o endereço associado com o do perfil e depois repita a comparação após uma reconexão de rede.

Se o perfil nunca precisou de um endereço fixo, remover local é uma simplificação legítima, mas torne-a uma decisão de segurança em vez de um hábito de diagnóstico.

Alargar o ouvinte muda quem lhe pode chegar, por isso associe essa alteração à política de firewall que deveria tê-lo restringido. Um serviço que arranca de forma fiável em todas as interfaces não resolveu o problema original; mudou o problema para a periferia da rede.