OpenVPN: o bind local falla ao arrincar: esperar ou reintentar

Para un servidor OpenVPN que non arrinca, ofrécense dúas solucións: esperar o enderezo ou deixar que o servizo reintente ata que o enlace funcione. Ambas abordan o mesmo síntoma cun comportamento de fallo distinto. A espera codifica un requisito previo concreto e falla ruidosamente cando falta; o reintento oculta o requisito e segue intentándoo. Cal das dúas corresponde á túa unidade depende de se ese enderezo é unha dependencia deseñada ou unha casualidade de temporización.

Ambas son mellores ca un sono fixo, que nin espera nada nin informa do que esperaba.

Que esixe realmente a opción local

local nomea o enderezo ao que o daemon enlaza o seu socket, e enlazar a un enderezo que aínda non existe falla de inmediato cun erro sobre o enderezo solicitado. Cando a opción falta, o daemon escoita en todos os enderezos, por iso o mesmo perfil funciona nunha máquina cuxa interface aínda non subiu: escoita en todas partes en lugar do único enderezo que nomeaches. Esa diferenza é todo o fallo, e permanece invisible ata un reinicio.

O requisito non é que a interface estea activa nun sentido xeral. O enderezo debe estar asignado á interface correcta no momento do enlace, e debe ser a interface subxacente e non un túnel que o mesmo daemon crearía despois. Unha comprobación feita minutos despois de iniciar sesión non demostra nada sobre a secuencia de arrinque.

Esperar o enderezo ou reintentar o enlace

Esperar significa un ExecStartPre que consulta ata que aparece o enderezo, cun número limitado de intentos e unha saída distinta de cero cando se esgota o tempo. Reintentar significa deixar que o proceso principal falle e pedir ao xestor de servizos que o inicie de novo, por exemplo Restart=on-failure con RestartSec=5. O primeiro informa dun requisito ausente como unidade fallida, mentres que o segundo o informa como unha serie de reinicios que finalmente se detén, o cal é máis ruidoso no rexistro pero sobrevive a un enderezo que chega tarde por motivos que non podes predicir.

Preferi esperar cando o enderezo é unha dependencia deseñada, e preferi reintentar cando o enderezo adoita aparecer pero a súa temporización varía. Combinalas é razoable: unha espera limitada cobre o caso habitual e unha política de reinicio a excepción. O que ningunha debería facer é executarse para sempre, porque unha unidade que reintenta indefinidamente oculta unha mala configuración en lugar de informala.

Por que network-online.target non abonda

network-online.target promete o que a implementación de rede activa entende por en liña, e nada máis. Con systemd-networkd, systemd-networkd-wait-online decide cando se acada ese obxectivo, e a súa noción predeterminada de en liña pode satisfacerse antes de que exista o teu enderezo concreto. Baixo NetworkManager, o servizo wait-online aplica as súas propias regras. Ordenar despois do obxectivo é unha base sólida, non unha garantía de que un enderezo, unha resposta DNS ou un par remoto estea listo.

O mesmo razoamento descarta as alternativas habituais. Unha entrada de inicio automático de escritorio espera unha sesión de usuario que quizais nunca se abra nun servidor, e un comando cron atrasado engade tempo transcorrido sen nomear o recurso cuxa aparición esperaba. Ambas poden parecer exitosas durante meses e despois fallar no único arrinque que importa.

Comproba o enlace tras un arrinque en frío

Verifica cun arrinque en frío real en lugar dun reinicio do servizo, porque un reinicio herda un enderezo que a secuencia de arrinque tivo que crear. Tras o arrinque, ss -lntp ou ss -lunp mostra o enderezo local ao que cada oínte se enlazou realmente, e journalctl -b -u openvpn-server@server mostra se fallou o primeiro intento. Compara o enderezo enlazado co do perfil e despois repite a comparación tras unha reconexión de rede.

Se o perfil nunca necesitou un enderezo fixo, eliminar local é unha simplificación lexítima, pero faino unha decisión de seguridade en lugar dun hábito de diagnóstico.

Ampliar o oínte cambia quen pode chegar a el, así que combina ese cambio coa política de cortalumes que debería terse encargado de restrinxilo. Un servizo que arrinca de forma fiable en todas as interfaces non resolveu o problema orixinal; trasladou o problema á beira da rede.