Zakaj se VPN enota zažene pred omrežjem in nato umre

Zaženite stroj, prijavite se in ugotovite, da je tunel vstal in nekaj sekund kasneje umrl. Profil je bil v redu, potrdilo je bilo v redu, in edina preostala sled je dnevnik te zagonske seje. Kar se običajno zgodi, je tekma: enota se je zagnala, preden je imel stroj naslov, in vrstni red, ki ga je deklarirala, ni pomenil tega, kar se zdi. Vse spodaj govori o tem, kako to tekmo dokazati z dokazi in jo pravilno zapreti.

Cilj je zbirališče, ne upravitelj

network-online.target nima pojma, kaj je omrežje. To je koordinacijska točka, ki zbere storitev, ki naj bi odložila zagon, dokler povezava ni uporabna, in definicijo prenese na tistega upravitelja omrežja, ki je lastnik stroja. Na večini namizij in strežnikov to pomeni storitev čakanja, ki jo zagotavlja NetworkManager ali systemd-networkd. Če ne omogočite nobene, cilj nima na kaj čakati, zato se zaključi v trenutku, ko ga nekaj potegne noter, kar je lahko veliko pred odgovorom DHCP. Vrstica z vrstnim redom v vaši enoti je bila poštena in kljub temu neuporabna.

Prvo vprašanje torej ni, kaj deklarira vaša enota. Temveč ali na tem stroju nekaj resnično opravlja čakanje.

Preberite zadnji zagon, ne datoteko enote

Datoteke enot opisujejo namen, dnevnik pa opisuje, kaj se je zgodilo. Zahtevajte samo ta zagon, z monotonimi časovnimi žigi, da vsako sporočilo sedi na eni uri. Nato poiščite dve vrstici: trenutek, ko se je enota tunela začela zaganjati, in trenutek, ko se je pojavil naslov ali končala storitev čakanja. Razvrstite ti dve števili in tekma je bodisi potrjena bodisi izključena.

Pogled odvisnosti to potrjuje. Če kritična veriga za enoto tunela ne vsebuje storitve čakanja, nič na tej poti ni odložilo zagona, in cilj ni opravil dela, ki ste ga predpostavili. Dva pogleda, en sklep.

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

Dodajte čakanje, nato ponovni poskus

Uporabite drop-in namesto urejanja pakirane enote, da posodobitev paketa spremembe ne zavrže tiho. Pomembni sta dve direktivi: enota mora biti razvrščena za ciljem in mora cilj potegniti v isto transakcijo. Sam vrstni red cilja ne prikliče; to stori želja.

Pakirana enota odjemalca OpenVPN že nosi oboje. Ročno napisane enote običajno nosijo eno ali nobene, kar velja preveriti, preden kar koli dodate.

[Service]
Restart=on-failure
RestartSec=15

Zakaj je fiksno spanje past

Spanje v ExecStartPre se zdi kot popravek vrstnega reda in se obnaša kot zamuda z dodatnimi koraki. Upočasni vsak zagon, tudi tiste, ki so bili zdravi, in še vedno izgubi, ko povezava traja dlje od števila, ki ste ga izbrali.

Še slabše, skriva, ali storitev čakanja deluje, zato se naslednja napaka pokaže kot povsem nova težava in ne ista z drugim časom. Kratka zamuda ponovnega zagona je boljše orodje: pri zdravem zagonu ne stane nič in izgubljeno tekmo spremeni v še en poskus. Interval naj bo skromen in pustite enoti, da uspe. Če se ponovno zažene za vedno, je profil pokvarjen in nobena količina poskusov tega ne bo spremenila, zato berite dnevnik, namesto da dvigujete interval.

Ko je vrstni red pravilen in imena še vedno odpovedo

Dejavna enota s potjo tunela pomeni, da je vrstni red opravil svoje delo in da preostala napaka sedi eno plast višje. Običajna oblika je nastavitev razreševalnika, ki jo up-skript tunela uporabi, preden so bile povezava ali razreševalnik pripravljeni, da jo obdržijo. Primerjajte stanje razreševalnika med napako s stanjem po ponovnem zagonu enote tunela.

Če ponovni zagon popravi iskanja, imate napako vrstnega reda zagona in ne napačnega strežnika DNS, in ta dva potrebujeta različna popravka. Nato vse skupaj dokažite s hladnim zagonom namesto s ponovnim zagonom storitve, ker ponovni zagon teče proti omrežju, ki je že gor, in bo skril natanko tisto napako, ki jo lovite. Ponovite z namerno počasno povezavo in enoto, ki deluje le, ko je omrežje hitro, obravnavajte kot še vedno pokvarjeno.