Per què una unitat VPN arrenca abans que la xarxa i després mor

Engegueu la màquina, inicieu sessió i descobriu que el túnel va pujar i va morir uns segons després. El perfil estava bé, el certificat estava bé, i l'únic rastre que queda és el registre d'aquella arrencada. El que sol passar és una cursa: la unitat va arrencar abans que la màquina tingués una adreça, i l'ordre que declarava no volia dir el que sembla. Tot el que hi ha a continuació tracta de demostrar aquesta cursa amb proves i tancar-la correctament.

L'objectiu és un punt de trobada, no un gestor

network-online.target no té ni idea de què és una xarxa. És un punt de coordinació que recull el servei que ha de retardar l'arrencada fins que l'enllaç sigui utilitzable, i delega la definició al gestor de xarxa que sigui propietari de la màquina. A la majoria d'escriptoris i servidors això vol dir un servei d'espera subministrat per NetworkManager o per systemd-networkd. No activeu cap dels dos i l'objectiu no tindrà res per esperar, així que es completa en el moment que alguna cosa el cridi, cosa que pot passar molt abans que DHCP respongui. La línia d'ordenació de la vostra unitat era honesta i tot i així inútil.

La primera pregunta, doncs, no és què declara la vostra unitat. És si hi ha res en aquesta màquina que faci de debò l'espera.

Llegiu l'última arrencada en lloc del fitxer de la unitat

Els fitxers de unitat descriuen la intenció, i el registre descriu què va passar. Demaneu només aquella arrencada, amb marques de temps monòtones perquè cada missatge estigui en un sol rellotge. Després trobeu dues línies: el moment en què la unitat del túnel va començar a arrencar i el moment en què va aparèixer l'adreça o va acabar el servei d'espera. Ordeneu aquests dos números i la cursa queda confirmada o descartada.

La vista de dependències ho corrobora. Si una cadena crítica per a la unitat del túnel no conté cap servei d'espera, res en aquest camí no va retardar l'arrencada, i l'objectiu no va fer la feina que suposàveu. Dues vistes, una conclusió.

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

Afegiu l'espera, després el reintent

Feu servir un drop-in en lloc d'editar una unitat empaquetada, perquè una actualització del paquet no descarti el canvi en silenci. Dues directives importen: la unitat ha d'anar ordenada després de l'objectiu i ha d'atreure l'objectiu a la mateixa transacció. L'ordenació sola no invoca l'objectiu; el desig sí.

La unitat empaquetada del client OpenVPN ja porta les dues. Les unitats escrites a mà solen portar-ne una o cap, cosa que val la pena comprovar abans d'afegir-hi res.

[Service]
Restart=on-failure
RestartSec=15

Per què una dormida fixa és un parany

Una dormida a ExecStartPre sembla una correcció d'ordenació i es comporta com un retard amb passos extra. Alenteix cada arrencada, incloses les que eren sanes, i encara perd quan l'enllaç triga més que el número que heu triat.

Pitjor encara, amaga si el servei d'espera funciona, així que la propera fallada es presenta com un problema nou de trinca en lloc del mateix amb un altre moment. Un retard curt de reinici és el millor instrument: no costa res en una arrencada sana i converteix una cursa perduda en un altre intent. Manteniu l'interval modest i deixeu que la unitat tingui èxit. Si es reinicia per sempre, el perfil està trencat i cap quantitat de reintents ho canviarà, així que llegiu el registre en lloc d'apujar l'interval.

Quan l'ordre és correcte i els noms encara fallen

Una unitat activa amb una ruta de túnel vol dir que l'ordenació va fer la seva feina i que la resta de la falla és una capa més amunt. La forma habitual és un paràmetre de resolutor aplicat per l'script up del túnel abans que l'enllaç o el resolutor estiguessin a punt per conservar-lo. Compareu l'estat del resolutor durant la fallada amb l'estat després de reiniciar la unitat del túnel.

Si el reinici arregla les consultes, teniu un defecte d'ordenació d'arrencada i no un servidor DNS equivocat, i aquests dos necessiten arranjaments diferents. Després demostreu-ho tot amb una arrencada en fred en lloc de reiniciar el servei, perquè reiniciar funciona sobre una xarxa que ja està engegada i amagarà exactament el defecte que perseguiu. Repetiu-ho amb l'enllaç deliberadament lent i tracteu una unitat que només funciona quan la xarxa és ràpida com a encara trencada.