Zlyhanie lokálneho zviazania OpenVPN pri štarte: čakať, alebo skúšať znova

Pre server OpenVPN, ktorý sa pri štarte nespustí, sa ponúkajú dve riešenia: počkať na adresu, alebo nechať službu skúšať znova, kým zviazanie neprejde. Obe riešia rovnaký príznak, ale pri zlyhaní sa správajú odlišne. Čakanie zakóduje konkrétny predpoklad a pri jeho absencii hlasno zlyhá; opakovanie predpoklad skrýva a skúša ďalej. Ktoré z nich patrí do vášho unitu, závisí od toho, či je tá adresa navrhnutou závislosťou, alebo len náhodou časovania.

Obe sú lepšie než pevne nastavené čakanie, ktoré na nič nečaká a ani neoznámi, na čo čakalo.

Čo vlastne vyžaduje voľba local

local určuje adresu, na ktorú démon pripája svoj socket, a pripájanie na adresu, ktorá ešte neexistuje, okamžite zlyhá s chybou o požadovanej adrese. Ak voľba chýba, démon počúva na všetkých adresách, a preto ten istý profil funguje aj na stroji, ktorého rozhranie ešte nie je aktívne: počúva všade namiesto jednej adresy, ktorú ste určili. Tento rozdiel je celou príčinou zlyhania a zostáva neviditeľný až do reštartu.

Požiadavka nie je, aby bolo rozhranie nejako všeobecne aktívne. Adresa musí byť priradená správnemu rozhraniu v okamihu zviazania a musí ísť o podkladové rozhranie, nie o tunel, ktorý by ten istý démon vytvoril neskôr. Kontrola spustená pár minút po prihlásení nehovorí o štartovacej sekvencii nič.

Čakanie na adresu verzus opakovanie zviazania

Čakanie znamená ExecStartPre, ktorý sa dopytuje, kým sa adresa neobjaví, s obmedzeným počtom pokusov a nenulovým návratovým kódom, keď čas vyprší. Opakovanie znamená nechať hlavný proces zlyhať a požiadať správcu služieb, aby ho spustil znova, napríklad Restart=on-failure s RestartSec=5. Prvé hlási chýbajúci predpoklad ako zlyhaný unit, kým druhé ho hlási ako sériu reštartov, ktorá sa napokon zastaví; v journale je to hlučnejšie, ale prežije adresu, ktorá dorazí neskoro z dôvodov, ktoré neviete predvídať.

Uprednostnite čakanie, ak je adresa navrhnutou závislosťou, a opakovanie, ak sa adresa zvyčajne objaví, ale jej načasovanie sa mení. Kombinácia oboch je rozumná: obmedzené čakanie pokrýva bežný prípad a politika reštartu pokrýva výnimky. Ani jedno by však nemalo bežať donekonečna, pretože unit, ktorý opakuje pokusy neobmedzene, skrýva chybnú konfiguráciu namiesto toho, aby ju hlásil.

Prečo network-online.target nestačí

network-online.target sľubuje presne to, čo aktívna implementácia siete považuje za online, a nič viac. Pri systemd-networkd rozhoduje o dosiahnutí tohto cieľa systemd-networkd-wait-online a jeho predvolené chápanie stavu online môže byť splnené skôr, než vaša konkrétna adresa existuje. Pod NetworkManager uplatňuje služba wait-online vlastné pravidlá. Zoradenie za cieľom je rozumný základ, nie záruka, že jedna adresa, odpoveď DNS alebo vzdialený peer je pripravený.

Rovnaká úvaha vylučuje obvyklé alternatívy. Položka automatického spustenia na ploche čaká na používateľskú reláciu, ktorá sa na serveri nemusí nikdy otvoriť, a oneskorený príkaz cron pridáva uplynutý čas bez toho, aby pomenoval zdroj, o ktorom dúfal, že sa objaví. Obe môžu mesiace vyzerať úspešne a potom zlyhajú pri jedinom štarte, na ktorom záleží.

Skontrolujte zviazanie po studenom štarte

Overte to skutočným studeným štartom, nie reštartom služby, pretože reštart zdedí adresu, ktorú musela vytvoriť štartovacia sekvencia. Po štarte ss -lntp alebo ss -lunp ukáže lokálnu adresu, na ktorú sa každý prijímač skutočne zviazal, a journalctl -b -u openvpn-server@server ukáže, či prvý pokus zlyhal. Porovnajte zviazanú adresu s adresou v profile a potom porovnanie zopakujte po opätovnom pripojení siete.

Ak profil nikdy nepotreboval pevnú adresu, odstránenie local je legitímne zjednodušenie, ale urobte z toho bezpečnostné rozhodnutie, nie diagnostický zvyk.

Rozšírenie počúvacieho socketu mení, kto sa k nemu dostane, preto túto zmenu spojte s pravidlami firewallu, ktoré ho mali obmedzovať. Služba, ktorá sa spoľahlivo spustí na každom rozhraní, pôvodný problém nevyriešila; len ho presunula na okraj siete.