Proč VPN jednotka startuje před sítí a potom umírá

Nabootujte stroj, přihlaste se a zjistěte, že tunel vstal a o pár sekund později zemřel. Profil byl v pořádku, certifikát byl v pořádku a jediná zbývající stopa je journal z tohoto bootu. Obvykle se odehrál závod: jednotka startovala dřív, než stroj měl adresu, a pořadí, které deklarovala, neznamenalo to, co vypadá. Všechno níže je o tom, jak ten závod dokázat z důkazů a správně ho uzavřít.

Cíl je místo setkání, ne správce

network-online.target netuší, co je to síť. Je to koordinační bod, který shromažďuje tu službu, jež má zpozdit start, dokud spojení není použitelné, a definici deleguje na toho správce sítě, který stroj vlastní. Na většině desktopů a serverů to znamená službu čekání, kterou dodává NetworkManager nebo systemd-networkd. Nezapnete-li ani jednu, cíl nemá na co čekat, a tak se dokončí ve chvíli, kdy ho něco přitáhne, což může být dávno předtím, než DHCP odpoví. Řádek s pořadím ve vaší jednotce byl poctivý, a přesto k ničemu.

První otázka tedy není, co vaše jednotka deklaruje. Ale jestli na tomto stroji něco to čekání skutečně dělá.

Čtěte poslední boot, ne soubor jednotky

Soubory jednotek popisují záměr a journal popisuje, co se stalo. Vyžádejte si jen ten boot, s monotónními časovými značkami, aby každá zpráva seděla na jedněch hodinách. Pak najděte dva řádky: okamžik, kdy jednotka tunelu začala startovat, a okamžik, kdy se objevila adresa nebo skončila služba čekání. Seřaďte ta dvě čísla a závod je buď potvrzen, nebo vyloučen.

Pohled na závislosti to potvrzuje. Pokud kritický řetězec pro jednotku tunelu neobsahuje službu čekání, nic na této cestě start nezpozdilo a cíl neudělal práci, kterou jste předpokládali. Dva pohledy, jeden závěr.

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

Přidejte čekání, pak opakování

Použijte drop-in místo úprav balíčkované jednotky, aby aktualizace balíčku změnu tiše nezahodila. Důležité jsou dvě direktivy: jednotka musí být seřazena za cílem a musí cíl přitáhnout do stejné transakce. Samotné pořadí cíl nepřivolá; to dělá touha.

Balíčkovaná jednotka klienta OpenVPN nese obojí už teď. Ručně psané jednotky obvykle nesou jedno, nebo nic, což stojí za kontrolu, než cokoli přidáte.

[Service]
Restart=on-failure
RestartSec=15

Proč je pevný spánek past

Spánek v ExecStartPre působí jako oprava pořadí a chová se jako zpoždění s kroky navíc. Zpomaluje každý boot, včetně těch zdravých, a přesto prohrává, když spojení trvá déle než číslo, které jste zvolili.

Horší je, že skrývá, jestli služba čekání funguje, takže se další selhání jeví jako zbrusu nový problém, a ne ten samý s jiným časováním. Krátké zpoždění restartu je lepší nástroj: při zdravém bootu nic nestojí a prohraný závod promění v další pokus. Držte interval skromný a nechte jednotku uspět. Pokud se restartuje věčně, profil je rozbitý a žádné opakování to nezmění, takže čtěte log místo zvyšování intervalu.

Když je pořadí správné a jména přesto selhávají

Aktivní jednotka s trasou tunelu znamená, že pořadí udělalo svou práci a zbývající závada je o vrstvu výš. Obvyklý tvar je nastavení resolveru, které up skript tunelu aplikuje dřív, než spojení nebo resolver byl připraven ho udržet. Porovnejte stav resolveru během selhání se stavem po restartu jednotky tunelu.

Pokud restart opraví vyhledávání, máte závadu pořadí startu, a ne špatný DNS server, a ty dvě potřebují různé opravy. Pak celou věc dokažte studeným bootem místo restartu služby, protože restart běží proti síti, která už je nahoře, a schová přesně tu závadu, kterou honíte. Zopakujte to s úmyslně pomalým spojením a jednotku, která funguje jen při rychlé síti, považujte za stále rozbitou.