Por que unha unidade de VPN arrinca antes ca rede e logo morre

Arrince a máquina, inicie sesión e descubra que o túnel subiu e morreu uns segundos despois. O perfil estaba ben, o certificado estaba ben, e o único rastro que queda é o rexistro desa arrincada. O que adoita ocorrer é unha carreira: a unidade arrincou antes de que a máquina tivese un enderezo, e a orde que declaraba non significaba o que parece. Todo o que segue trata de demostrar esa carreira con probas e de pechala correctamente.

O obxectivo é un punto de encontro, non un xestor

network-online.target non ten nin idea do que é unha rede. É un punto de coordinación que reúne o servizo que debe atrasar a arrincada ata que a ligazón sexa utilizábel, e delega a definición no xestor de rede que sexa dono da máquina. Na maioría de escritorios e servidores iso significa un servizo de espera que fornece NetworkManager ou systemd-networkd. Non active ningún e o obxectivo non terá nada que agardar, así que se completa no momento en que algo o arrastre, o que pode ser moito antes de que DHCP responda. A liña de orde da súa unidade era honesta e aínda así inútil.

A primeira pregunta, xa que logo, non é que declara a súa unidade. É se algo nesta máquina fai de verdade a espera.

Lea a última arrincada en lugar do ficheiro da unidade

Os ficheiros de unidade describen a intención, e o rexistro describe o que ocorreu. Pida só esa arrincada, con marcas de tempo monótonas para que cada mensaxe se sitúe nun mesmo reloxo. Despois busque dúas liñas: o momento en que a unidade do túnel empezou a arrincar e o momento en que apareceu o enderezo ou rematou o servizo de espera. Ordene eses dous números e a carreira queda confirmada ou descartada.

A vista de dependencias corrobórao. Se unha cadea crítica para a unidade do túnel non contén ningún servizo de espera, nada nese camiño atrasou a arrincada, e o obxectivo non fixo o traballo que vostede supuña. Dúas vistas, unha conclusión.

systemctl list-units --type=service --state=running | grep wait-online
journalctl -b -o short-monotonic -u openvpn-client@office

Engada a espera, logo o reintento

Use un drop-in en lugar de editar unha unidade empaquetada, para que unha actualización do paquete non descarte o cambio en silencio. Importan dúas directivas: a unidade debe ir ordenada despois do obxectivo e debe atraer o obxectivo á mesma transacción. A orde por si soa non invoca o obxectivo; o desexo si.

A unidade empaquetada do cliente OpenVPN xa leva ambas. As unidades escritas a man adoitan levar unha ou ningunha, o que paga a pena comprobar antes de engadir nada.

[Service]
Restart=on-failure
RestartSec=15

Por que un sono fixo é unha trampa

Un sono en ExecStartPre sente como unha corrección de orde e compórtase como un atraso con pasos extra. Fai máis lenta cada arrincada, incluídas as que eran sanas, e aínda así perde cando a ligazón tarda máis ca o número que escolleu.

Peor aínda, oculta se o servizo de espera funciona, así que o seguinte fallo preséntase como un problema completamente novo en lugar do mesmo con outro momento. Un atraso curto de reinicio é o mellor instrumento: non custa nada nunha arrincada sana e converte unha carreira perdida noutro intento. Manteña o intervalo modesto e deixe que a unidade teña éxito. Se se reinicia para sempre, o perfil está roto e ningunha cantidade de reintentos o cambiará, así que lea o rexistro en lugar de subir o intervalo.

Cando a orde é correcta e os nomes aínda fallan

Unha unidade activa cunha ruta de túnel significa que a orde fixo o seu traballo e que o fallo restante está unha capa máis arriba. A forma habitual é un axuste de resolutor que aplica o script up do túnel antes de que a ligazón ou o resolutor estivesen listos para conservalo. Compare o estado do resolutor durante o fallo co estado despois de reiniciar a unidade do túnel.

Se o reinicio arranxa as consultas, ten un defecto de orde de arrincada e non un servidor DNS equivocado, e eses dous necesitan arranxos distintos. Despois demostre todo cunha arrincada en frío en lugar de reiniciar o servizo, porque reiniciar corre contra unha rede que xa está levantada e ocultará xustamente o defecto que persegue. Repítao coa ligazón deliberadamente lenta e trate unha unidade que só funciona cando a rede é rápida como aínda rota.