Zašto VPN jedinica kreće prije mreže i zatim umre

Podignite mašinu, prijavite se i saznajte da je tunel otišao gore i umro nekoliko sekundi kasnije. Profil je bio u redu, certifikat je bio u redu, a jedini preostali trag je journal iz tog podizanja. Obično se dogodila utrka: jedinica je krenula prije nego što je mašina imala adresu, a redoslijed koji je deklarisala nije značio ono na što liči. Sve ispod govori o tome kako tu utrku dokazati iz dokaza i ispravno je zatvoriti.

Cilj je mjesto susreta, a ne upravitelj

network-online.target nema pojma šta je mreža. To je koordinacijska točka koja skuplja onu uslugu koja treba odgoditi podizanje dok veza ne postane upotrebljiva, i prenosi definiciju na onog mrežnog menadžera koji posjeduje mašinu. Na većini radnih stanica i servera to znači uslugu čekanja koju isporučuje NetworkManager ili systemd-networkd. Ne uključite nijednu i cilj nema šta čekati, pa se dovrši u trenutku kada ga nešto povuče, što može biti mnogo prije nego što DHCP odgovori. Red o redoslijedu u vašoj jedinici bio je iskren i ipak beskorisan.

Prvo pitanje zato nije šta vaša jedinica deklariše. Nego da li nešto na ovoj mašini zaista obavlja čekanje.

Čitajte posljednje podizanje, a ne datoteku jedinice

Datoteke jedinica opisuju namjeru, a journal opisuje šta se dogodilo. Zatražite samo to podizanje, s monotonim vremenskim oznakama kako bi svaka poruka stajala na jednom satu. Zatim nađite dva retka: trenutak kada je jedinica tunela počela da se pokreće i trenutak kada se adresa pojavila ili je usluga čekanja završila. Poredajte ta dva broja i utrka je ili potvrđena ili isključena.

Prikaz zavisnosti to potvrđuje. Ako kritični lanac za jedinicu tunela ne sadrži uslugu čekanja, ništa na tom putu nije odgodilo podizanje i cilj nije obavio posao koji ste pretpostavili. Dva prikaza, jedan zaključak.

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

Dodajte čekanje, zatim ponovni pokušaj

Koristite drop-in umjesto uređivanja zapakovane jedinice, kako ažuriranje paketa ne bi tiho odbacilo promjenu. Dvije su direktive važne: jedinica mora biti poredana nakon cilja i mora povući cilj u istu transakciju. Samo poredanje ne priziva cilj; to čini želja.

Zapakovana jedinica OpenVPN klijenta već nosi oboje. Ručno napisane jedinice obično nose jedno ili nijedno, što vrijedi provjeriti prije nego što bilo šta dodate.

[Service]
Restart=on-failure
RestartSec=15

Zašto je fiksno spavanje zamka

Spavanje u ExecStartPre djeluje kao popravka redoslijeda, a ponaša se kao odgoda s dodatnim koracima. Usporava svako podizanje, uključujući ona koja su bila zdrava, i još gubi kada veza traje duže od broja koji ste odabrali.

Gore od toga, skriva da li usluga čekanja radi, pa se sljedeći neuspjeh predstavlja kao posve nov problem, a ne isti s drugačijim vremenom. Kratka odgoda ponovnog pokretanja je bolji instrument: ne košta ništa pri zdravom podizanju i pretvara izgubljenu utrku u još jedan pokušaj. Držite interval skromnim i pustite jedinicu da uspije. Ako se ponovo pokreće zauvijek, profil je pokvaren i nikakvo ponavljanje to neće promijeniti, pa čitajte journal umjesto da povećavate interval.

Kad je redoslijed ispravan, a imena i dalje padaju

Aktivna jedinica s rutom tunela znači da je redoslijed obavio svoj posao, a preostala greška je jedan sloj više. Uobičajeni oblik je postavka resolvera koju up skripta tunela primijeni prije nego što su veza ili resolver bili spremni da je zadrže. Uporedite stanje resolvera tokom neuspjeha sa stanjem nakon ponovnog pokretanja jedinice tunela.

Ako ponovno pokretanje popravi pretrage, imate defekt redoslijeda podizanja, a ne pogrešan DNS server, i to dvoje traži različite popravke. Zatim dokažite cijelu stvar hladnim podizanjem umjesto ponovnog pokretanja usluge, jer ponovno pokretanje radi na mreži koja je već gore i sakrit će upravo defekt koji gonite. Ponovite to s namjerno sporom vezom i smatrajte jedinicu koja radi samo kad je mreža brza još uvijek pokvarenom.