Prečo VPN jednotka štartuje pred sieťou a potom zomiera

Nabootujte stroj, prihláste sa a zistite, že tunel vstal a o pár sekúnd zomrel. Profil bol v poriadku, certifikát bol v poriadku a jediná zostávajúca stopa je journal z tohto bootu. Zvyčajne sa odohral pretek: jednotka štartovala skôr, než stroj mal adresu, a poradie, ktoré deklarovala, neznamenalo to, ako vyzerá. Všetko nižšie je o tom, ako ten pretek dokázať z dôkazov a správne ho uzavrieť.

Cieľ je miesto stretnutia, nie správca

network-online.target netuší, čo je sieť. Je to koordinačný bod, ktorý zhromažďuje tú službu, ktorá má oddialiť štart, kým spojenie nebude použiteľné, a definíciu deleguje na toho správcu siete, ktorý stroj vlastní. Na väčšine desktopov a serverov to znamená službu čakania, ktorú dodáva NetworkManager alebo systemd-networkd. Ak nezapnete ani jednu, cieľ nemá na čo čakať, a tak sa dokončí vo chvíli, keď ho niečo pritiahne, čo môže byť dávno predtým, než DHCP odpovie. Riadok s poradím vo vašej jednotke bol úprimný a napriek tomu zbytočný.

Prvá otázka teda nie je, čo vaša jednotka deklaruje. Ale či na tomto stroji niečo to čakanie skutočne robí.

Čítajte posledný boot, nie súbor jednotky

Súbory jednotiek opisujú zámer a journal opisuje, čo sa stalo. Vyžiadajte si len ten boot, s monotónnymi časovými značkami, aby každá správa sedela na jedných hodinách. Potom nájdite dva riadky: okamih, keď jednotka tunela začala štartovať, a okamih, keď sa objavila adresa alebo skončila služba čakania. Zoraďte tie dve čísla a pretek je buď potvrdený, alebo vylúčený.

Pohľad na závislosti to potvrdzuje. Ak kritická reťaz pre jednotku tunela neobsahuje službu čakania, nič na tejto ceste štart neoddialilo a cieľ neurobil prácu, ktorú ste predpokladali. Dva pohľady, jeden záver.

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

Pridajte čakanie, potom opakovanie

Použite drop-in namiesto úpravy zabalenej jednotky, aby aktualizácia balíka zmenu ticho neodhodila. Dôležité sú dve direktívy: jednotka musí byť zoradená za cieľom a musí cieľ pritiahnuť do tej istej transakcie. Samotné poradie cieľ nevyvolá; robí to túžba.

Zabalená jednotka klienta OpenVPN už nesie obe. Ručne písané jednotky zvyčajne nesú jednu alebo nič, čo stojí za kontrolu, kým niečo pridáte.

[Service]
Restart=on-failure
RestartSec=15

Prečo je pevný spánok pasca

Spánok v ExecStartPre pôsobí ako oprava poradia a správa sa ako oneskorenie s krokmi navyše. Spomaľuje každý boot, vrátane tých zdravých, a napriek tomu prehráva, keď spojenie trvá dlhšie ako číslo, ktoré ste zvolili.

Horšie je, že skrýva, či služba čakania funguje, takže ďalšie zlyhanie sa javí ako úplne nový problém a nie ten istý s iným časovaním. Krátke oneskorenie reštartu je lepší nástroj: pri zdravom boote nič nestojí a prehraný pretek premení na ďalší pokus. Držte interval skromný a nechajte jednotku uspieť. Ak sa reštartuje večne, profil je rozbitý a žiadne opakovanie to nezmení, takže čítajte log namiesto zvyšovania intervalu.

Keď je poradie správne a mená napriek tomu zlyhávajú

Aktívna jednotka s trasou tunela znamená, že poradie urobilo svoju prácu a zostávajúca chyba je o vrstvu vyššie. Zvyčajný tvar je nastavenie resolvera, ktoré up skript tunela použije skôr, než bolo spojenie alebo resolver pripravené ho udržať. Porovnajte stav resolvera počas zlyhania so stavom po reštarte jednotky tunela.

Ak reštart opraví vyhľadávanie, máte chybu poradia štartu a nie nesprávny DNS server, a tie dve potrebujú rôzne opravy. Potom celú vec dokážte studeným bootom namiesto reštartu služby, pretože reštart beží proti sieti, ktorá už je hore, a skryje presne tú chybu, ktorú prenasledujete. Zopakujte to s úmyselne pomalým spojením a jednotku, ktorá funguje len pri rýchlej sieti, považujte za stále rozbitú.