OpenVPN: lokální bind při startu selhává — čekat, nebo zkoušet znovu

Pro server OpenVPN, který se při startu nespustí, se nabízejí dvě opravy: počkat na adresu, nebo nechat službu opakovat pokus, dokud se navázání nepovede. Obě řeší stejný symptom s jiným chováním při selhání. Čekání zakódovává konkrétní předpoklad a hlasitě selže, když chybí; opakování předpoklad skrývá a dál zkouší. Které z nich patří do vaší jednotky, závisí na tom, zda je adresa navrženou závislostí, nebo náhodou časování.

Obě jsou lepší než pevné uspání, které na nic nečeká a ani nehlásí, na co čekalo.

Co volba local skutečně vyžaduje

local pojmenovává adresu, na kterou démon váže svůj socket, a navázání na adresu, která dosud neexistuje, okamžitě selže s chybou o požadované adrese. Když volba chybí, démon naslouchá na všech adresách, a proto stejný profil funguje na stroji, jehož rozhraní ještě není nahoru: naslouchá všude místo na jediné adrese, kterou jste uvedli. Ten rozdíl je celé selhání a zůstává neviditelný až do restartu.

Požadavek není, aby rozhraní bylo nahoru v nějakém obecném smyslu. Adresa musí být v okamžiku navázání přiřazena správnému rozhraní a musí to být podkladové rozhraní, nikoli tunel, který by stejný démon vytvořil později. Kontrola provedená minuty po přihlášení nic nedokazuje o průběhu startu.

Čekat na adresu, nebo opakovat navázání

Čekání znamená ExecStartPre, který se dotazuje, dokud se adresa neobjeví, s omezeným počtem pokusů a nenulovým návratovým kódem, když čas vyprší. Opakování znamená nechat hlavní proces selhat a požádat správce služeb, aby jej znovu spustil, například Restart=on-failure s RestartSec=5. První hlásí chybějící předpoklad jako selhanou jednotku, druhé jej hlásí jako sérii restartů, která nakonec přestane; to je v žurnálu hlučnější, ale přežije adresu, která dorazí pozdě z důvodů, které nedokážete předvídat.

Dejte přednost čekání, když je adresa navrženou závislostí, a opakování, když se adresa obvykle objeví, ale její časování kolísá. Kombinovat je rozumné: omezené čekání pokrývá běžný případ a politika restartu výjimku. Ani jedno by nemělo běžet navěky, protože jednotka, která opakuje donekonečna, skrývá chybnou konfiguraci místo toho, aby ji ohlásila.

Proč network-online.target nestačí

network-online.target slibuje to, co aktivní síťová implementace míní slovem online, a nic víc. Se systemd-networkd rozhoduje systemd-networkd-wait-online, kdy je tohoto cíle dosaženo, a jeho výchozí pojetí online může být splněno dřív, než vaše konkrétní adresa existuje. Pod NetworkManagerem uplatňuje služba wait-online vlastní pravidla. Řazení za cílem je rozumný základ, ne záruka, že jedna adresa, odpověď DNS nebo vzdálený protějšek je připraven.

Stejná úvaha vylučuje obvyklé alternativy. Záznam automatického spuštění na ploše čeká na uživatelskou relaci, která se na serveru možná nikdy neotevře, a odložený příkaz cron přidává uplynulý čas, aniž by pojmenoval zdroj, jehož objevení očekával. Obě mohou měsíce vypadat úspěšně a pak selhat při jediném startu, na kterém záleží.

Zkontrolujte navázání po studeném startu

Ověřujte skutečným studeným startem, ne restartem služby, protože restart dědí adresu, kterou musel vytvořit průběh startu. Po startu ss -lntp nebo ss -lunp ukáže lokální adresu, na kterou se každý posluchač skutečně navázal, a journalctl -b -u openvpn-server@server ukáže, zda první pokus selhal. Porovnejte navázanou adresu s adresou v profilu a pak porovnání zopakujte po opětovném připojení k síti.

Jestliže profil nikdy nepotřeboval pevnou adresu, odstranění local je legitimní zjednodušení, ale udělejte z něj bezpečnostní rozhodnutí, ne diagnostický zvyk.

Rozšíření posluchače mění, kdo se k němu dostane, proto tuto změnu spojte s politikou firewallu, která ho měla omezovat. Služba, která spolehlivě startuje na každém rozhraní, původní problém nevyřešila; přesunula ho na okraj sítě.