Neuspešna lokalna vezava OpenVPN ob zagonu: čakanje ali ponovni poskus

Za strežnik OpenVPN, ki se ob zagonu ne zažene, se ponujata dve rešitvi: počakati na naslov ali pustiti storitvi, da poskuša znova, dokler vezava ne uspe. Obe naslavljata isto težavo, a se ob neuspehu obnašata različno. Čakanje vključuje določen predpogoj in ob njegovi odsotnosti glasno odpove; ponovni poskusi predpogoj skrijejo in vztrajajo. Katera od obeh sodi v vašo enoto, je odvisno od tega, ali je ta naslov načrtovana odvisnost ali le naključje časovnega usklajevanja.

Obe sta boljši od fiksnega spanja, ki na nič ne počaka in tudi ne pove, na kaj je čakalo.

Kaj pravzaprav zahteva možnost local

local določa naslov, na katerega demonski proces veže svojo vtičnico, in vezava na naslov, ki še ne obstaja, takoj odpove z napako o zahtevanem naslovu. Ko možnosti ni, proces posluša na vseh naslovih, zato ista konfiguracija deluje tudi na stroju, katerega vmesnik še ni vzpostavljen: posluša povsod namesto na enem naslovu, ki ste ga navedli. Ta razlika je celotna odpoved in ostane nevidna do ponovnega zagona.

Zahteva ni, da je vmesnik na nek splošen način vzpostavljen. Naslov mora biti ob vezavi dodeljen pravemu vmesniku in mora iti za spodnji vmesnik, ne za tunel, ki bi ga isti proces ustvaril pozneje. Preverjanje, izvedeno nekaj minut po prijavi, o zagonskem zaporedju ne pove ničesar.

Čakanje na naslov proti ponovnemu poskusu vezave

Čakanje pomeni ExecStartPre, ki poizveduje, dokler se naslov ne pojavi, z omejenim številom poskusov in neničelnim izhodom, ko čas poteče. Ponovni poskus pomeni, da glavnemu procesu dovolimo, da odpove, in upravitelja storitev prosimo, naj ga znova zažene, na primer Restart=on-failure z RestartSec=5. Prvo sporoči manjkajoči predpogoj kot neuspešno enoto, drugo pa kot vrsto ponovnih zagonov, ki se sčasoma ustavi; v dnevniku je to glasnejše, a prenese naslov, ki prispe pozno iz razlogov, ki jih ne morete predvideti.

Čakanje raje izberite, kadar je naslov načrtovana odvisnost, ponovne poskuse pa, kadar se naslov običajno pojavi, a se njegov čas spreminja. Kombinacija obeh je smiselna: omejeno čakanje pokrije običajen primer, pravilo za ponovni zagon pa izjeme. Nobeno od njiju ne sme teči v nedogled, ker enota, ki poskuša neomejeno, skriva napačno konfiguracijo, namesto da bi jo sporočila.

Zakaj network-online.target ni dovolj

network-online.target obljublja natanko to, kar dejavna izvedba omrežja razume pod pojmom online, in nič več. Pri systemd-networkd o tem, kdaj je cilj dosežen, odloča systemd-networkd-wait-online, in njegova privzeta predstava o stanju online je lahko izpolnjena, preden vaš naslov obstaja. Pod NetworkManager velja storitev wait-online po svojih pravilih. Uvrščanje za ciljem je dober temelj, ne pa zagotovilo, da so en naslov, odgovor DNS ali oddaljeni souporabnik pripravljeni.

Ista logika izloči običajne alternative. Vnos za samodejni zagon na namizju čaka na uporabniško sejo, ki se na strežniku morda nikoli ne odpre, odloženi ukaz cron pa doda pretečeni čas, ne da bi poimenoval vir, za katerega je upal, da se bo pojavil. Oba sta lahko mesece videti uspešna in nato odpovesta ob edinem zagonu, ki je pomemben.

Preverite vezavo po hladnem zagonu

Preverite s pravim hladnim zagonom, ne s ponovnim zagonom storitve, ker ponovni zagon podeduje naslov, ki ga je moralo ustvariti zagonsko zaporedje. Po zagonu ss -lntp ali ss -lunp pokaže lokalni naslov, na katerega se je vsak poslušalec dejansko vezal, journalctl -b -u openvpn-server@server pa pokaže, ali je prvi poskus odpovedal. Primerjajte vezani naslov z naslovom v konfiguraciji in primerjavo ponovite po ponovni povezavi omrežja.

Če konfiguracija nikoli ni potrebovala stalnega naslova, je odstranitev local legitimna poenostavitev, a naj bo varnostna odločitev in ne diagnostična navada.

Širitev poslušalca spremeni, kdo ga lahko doseže, zato to spremembo povežite s pravilom požarnega zidu, ki bi ga moralo omejevati. Storitev, ki se zanesljivo zažene na vsakem vmesniku, prvotne težave ni rešila; težavo je prestavila na rob omrežja.