Waarom 'n VPN-eenheid voor die netwerk begin en dan doodgaan

Begin die masjien, teken in, en verneem dat die tonnel opgekom het en 'n paar sekondes later dood is. Die profiel was reg, die sertifikaat was reg, en die enigste spoor wat oorbly, is die joernaal van daardie opstart. Wat gewoonlik gebeur het, is 'n wedloop: die eenheid het begin voordat die masjien 'n adres gehad het, en die ordening wat dit verklaar het, het nie beteken wat dit lyk nie. Alles hieronder gaan daaroor om daardie wedloop uit bewyse te bewys en behoorlik toe te maak.

Die teiken is 'n ontmoetingspunt, nie 'n bestuurder nie

network-online.target het geen idee wat 'n netwerk is nie. Dit is 'n koördinasiepunt wat enige diens versamel wat die opstart behoort te vertraag totdat die skakel bruikbaar is, en dit delegeer die definisie aan watter netwerkbestuurder ook al die masjien besit. Op die meeste rekenaars en bedieners beteken dit 'n wag-aanlyn-diens wat deur NetworkManager of deur systemd-networkd verskaf word. Aktiveer nie een nie en die teiken het niks om voor te wag nie, dus voltooi dit die oomblik wanneer iets dit intrek, wat heelwat voor DHCP antwoord kan wees. Die ordeningsreël in jou eenheid was eerlik en steeds nutteloos.

Die eerste vraag is dus nie wat jou eenheid verklaar nie. Dit is of enigiets op hierdie masjien werklik die wag doen.

Lees die laaste opstart eerder as die eenheidlêer

Eenheidlêers beskryf bedoeling, en die joernaal beskryf wat gebeur het. Vra net vir daardie opstart, met monotone tydstempels sodat elke boodskap op een klok sit. Soek dan twee reëls: die oomblik toe die tonneleenheid begin begin het, en die oomblik toe die adres verskyn het of die wag-aanlyn-diens klaar was. Orden daardie twee getalle en die wedloop is óf bevestig óf uitgesluit.

Die afhanklikheidsbeeld bevestig dit. As 'n kritieke ketting vir die tonneleenheid geen wag-aanlyn-diens bevat nie, het niks in daardie pad die opstart vertraag nie, en die teiken het nie die werk gedoen wat jy aangeneem het nie. Twee sienings, een gevolgtrekking.

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

Voeg die wag by, dan die herpoging

Gebruik 'n drop-in eerder as om 'n verpakte eenheid te wysig, sodat 'n pakketopdatering die verandering nie stilweg wegvee nie. Twee riglyne maak saak: die eenheid moet ná die teiken georden wees, en dit moet die teiken in dieselfde transaksie intrek. Ordening alleen roep nie die teiken op nie; die begeerte daarna wel.

Die verpakte OpenVPN-kliënteenheid dra albei reeds. Handgeskrewe eenhede dra gewoonlik een of nie een nie, wat die moeite werd is om na te gaan voordat jy enigiets byvoeg.

[Service]
Restart=on-failure
RestartSec=15

Waarom 'n vaste slaap 'n lokval is

'n Slaap in ExecStartPre voel soos 'n ordeningsherstel en gedra hom soos 'n vertraging met ekstra stappe. Dit vertraag elke opstart, insluitend dié wat gesond was, en dit verloor steeds wanneer die skakel langer neem as die getal wat jy gekies het.

Erger nog, dit verberg of die wag-aanlyn-diens werk, so die volgende fout kom voor as 'n splinternuwe probleem eerder as dieselfde een met ander tydsberekening. 'n Kort herbegin-vertraging is die beter instrument: dit kos niks op 'n gesonde opstart nie en omskep 'n verlore wedloop in nog 'n poging. Hou die interval beskeie en laat die eenheid slaag. As dit vir ewig herbegin, is die profiel stukkend en geen hoeveelheid herprobeer sal dit verander nie, so lees die log eerder as om die interval te verhoog.

Wanneer die orde reg is en name steeds misluk

'n Aktiewe eenheid met 'n tonnelroete beteken ordening het sy werk gedoen en die oorblywende fout sit een laag hoër. Die gewone vorm is 'n oplosserinstelling wat deur die tonnel se up-skrip toegepas is voordat die skakel of die oplosser gereed was om dit te hou. Vergelyk die oplosser se toestand tydens die fout met die toestand ná 'n herbegin van die tonneleenheid.

As die herbegin opsoeke regmaak, het jy 'n opstartordeningsdefek eerder as 'n verkeerde DNS-bediener, en dié twee het verskillende oplossings nodig. Bewys dan die hele ding met 'n koue opstart eerder as 'n diensherbegin, want herbegin werk teen 'n netwerk wat al op is en sal juis die defek verberg wat jy jaag. Herhaal dit met die skakel doelbewus stadig, en beskou 'n eenheid wat net werk wanneer die netwerk vinnig is as steeds stukkend.