Waarom een VPN-unit start voordat het netwerk er is en daarna sterft

Start de machine, log in en ontdek dat de tunnel omhoogkwam en een paar seconden later stierf. Het profiel was in orde, het certificaat was in orde, en het enige overgebleven spoor is het journaal van die boot. Wat er meestal gebeurde, is een race: de unit startte voordat de machine een adres had, en de volgorde die hij declareerde betekende niet wat het lijkt. Alles hieronder gaat over het bewijzen van die race uit bewijs en het netjes sluiten ervan.

Het doel is een ontmoetingspunt, geen beheerder

network-online.target heeft geen idee wat een netwerk is. Het is een coördinatiepunt dat de dienst verzamelt die de start hoort uit te stellen tot de verbinding bruikbaar is, en het delegeert de definitie aan de netwerkbeheerder die de machine bezit. Op de meeste desktops en servers betekent dat een wachtdienst die door NetworkManager of door systemd-networkd wordt geleverd. Activeer je geen van beide, dan heeft het doel niets om op te wachten, dus het voltooit op het moment dat iets het erbij trekt, wat lang voor het DHCP-antwoord kan zijn. De volgorderegel in je unit was eerlijk en toch nutteloos.

De eerste vraag is dus niet wat je unit declareert. Het is of er op deze machine werkelijk iets het wachten doet.

Lees de laatste boot in plaats van het unitbestand

Unitbestanden beschrijven de bedoeling, en het journaal beschrijft wat er gebeurde. Vraag alleen die boot op, met monotone tijdstempels zodat elk bericht op één klok zit. Zoek dan twee regels: het moment waarop de tunnelunit begon te starten, en het moment waarop het adres verscheen of de wachtdienst klaar was. Sorteer die twee getallen en de race is ofwel bevestigd ofwel uitgesloten.

De afhankelijkheidsweergave bevestigt het. Als een kritieke keten voor de tunnelunit geen wachtdienst bevat, heeft niets op dat pad de start uitgesteld, en het doel deed niet het werk dat je aannam. Twee weergaven, één conclusie.

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

Voeg het wachten toe, dan de nieuwe poging

Gebruik een drop-in in plaats van een verpakte unit te bewerken, zodat een pakketupdate de wijziging niet stilzwijgend weggooit. Twee richtlijnen tellen: de unit moet na het doel geordend zijn, en hij moet het doel in dezelfde transactie trekken. Orde alleen roept het doel niet op; de wens doet dat.

De verpakte unit van de OpenVPN-client draagt beide al. Handgeschreven units dragen meestal één of geen, wat de moeite waard is om te controleren voordat je iets toevoegt.

[Service]
Restart=on-failure
RestartSec=15

Waarom een vaste slaap een val is

Een slaap in ExecStartPre voelt als een volgordereparatie en gedraagt zich als een vertraging met extra stappen. Het vertraagt elke boot, ook de gezonde, en het verliest nog steeds wanneer de verbinding langer duurt dan het getal dat je koos.

Erger nog, het verbergt of de wachtdienst werkt, zodat de volgende fout als een gloednieuw probleem verschijnt in plaats van als hetzelfde met andere timing. Een korte herstartvertraging is het betere instrument: het kost niets bij een gezonde boot en verandert een verloren race in nog een poging. Houd het interval bescheiden en laat de unit slagen. Als hij voor altijd herstart, is het profiel kapot en geen enkele hoeveelheid nieuwe pogingen verandert dat, dus lees de log in plaats van het interval te verhogen.

Wanneer de volgorde klopt en namen toch falen

Een actieve unit met een tunnelroute betekent dat de volgorde zijn werk deed en dat de resterende fout een laag hoger zit. De gebruikelijke vorm is een resolver-instelling die het up-script van de tunnel toepast voordat de verbinding of de resolver klaar was om die vast te houden. Vergelijk de toestand van de resolver tijdens de fout met de toestand na een herstart van de tunnelunit.

Als de herstart opzoekingen repareert, heb je een startvolgordefout en geen verkeerde DNS-server, en die twee hebben verschillende reparaties nodig. Bewijs daarna het geheel met een koude boot in plaats van een dienstherstart, want een herstart draait tegen een netwerk dat al omhoog is en zal precies de fout verbergen die je jaagt. Herhaal het met de verbinding opzettelijk traag, en beschouw een unit die alleen werkt als het netwerk snel is als nog steeds kapot.