OpenVPN serveriui, kuris nepaleidžiamas įkrovos metu, siūlomi du sprendimai: laukti adreso arba leisti paslaugai kartoti bandymą, kol prisirišimas pavyks. Abu sprendžia tą patį simptomą skirtingu gedimo elgesiu. Laukimas užkoduoja konkrečią išankstinę sąlygą ir garsiai nepavyksta, kai jos nėra; kartojimas slepia sąlygą ir toliau bando. Kuris priklauso jūsų unit, priklauso nuo to, ar tas adresas yra suprojektuota priklausomybė, ar laiko atsitiktinumas.

Abu geresni už fiksuotą miegą, kuris nieko nelaukia ir nepraneša, ko laukė.

Ko iš tikrųjų reikalauja parinktis local

local įvardija adresą, prie kurio daemonas prisiriša savo socket, o prisirišimas prie dar neegzistuojančio adreso iš karto nepavyksta su klaida apie prašomą adresą. Kai parinkties nėra, daemonas klausosi visų adresų, todėl tas pats profilis veikia mašinoje, kurios sąsaja dar nepakelta: jis klausosi visur, o ne vieno adreso, kurį nurodėte. Šis skirtumas yra visas gedimas, ir jis lieka nematomas iki perkrovimo.

Reikalavimas nėra tai, kad sąsaja būtų pakelta kokia nors bendra prasme. Adresas turi būti priskirtas tinkamai sąsajai prisirišimo momentu, ir tai turi būti pagrindinė sąsaja, o ne tunelis, kurį tas pats daemonas sukurtų vėliau. Patikrinimas, atliktas praėjus kelioms minutėms po prisijungimo, nieko neįrodo apie įkrovos seką.

Laukti adreso ar kartoti prisirišimą

Laukimas reiškia ExecStartPre, kuris klausinėja, kol adresas atsiras, su ribotu bandymų skaičiumi ir ne nuliniu išėjimu, kai laikas baigiasi. Kartojimas reiškia leisti pagrindiniam procesui nepavykti ir paprašyti paslaugų tvarkyklės paleisti jį iš naujo, pavyzdžiui Restart=on-failure su RestartSec=5. Pirmasis praneša apie trūkstamą išankstinę sąlygą kaip apie nepavykusį unit, o antrasis – kaip apie perkrovimų seką, kuri galiausiai sustoja; tai triukšmingiau žurnale, bet atlaiko adresą, kuris vėluoja dėl priežasčių, kurių negalite numatyti.

Teikite pirmenybę laukimui, kai adresas yra suprojektuota priklausomybė, ir kartojimui, kai adresas paprastai atsiranda, bet jo laikas kinta. Juos derinti pagrįsta: ribotas laukimas apima įprastą atvejį, o perkrovimo politika – išimtį. Nė vienas neturėtų veikti amžinai, nes unit, kuris be galo kartoja, slepia neteisingą konfigūraciją, o ne praneša apie ją.

Kodėl network-online.target nepakanka

network-online.target žada tai, ką aktyvi tinklo implementacija supranta kaip online, ir nieko daugiau. Su systemd-networkd systemd-networkd-wait-online nusprendžia, kada šis tikslas pasiekiamas, o jo numatytasis online supratimas gali būti patenkintas prieš atsirandant jūsų konkrečiam adresui. Pagal NetworkManager wait-online paslauga taiko savo taisykles. Rikiavimas po tikslo yra tvirtas pagrindas, o ne garantija, kad vienas adresas, DNS atsakymas ar nuotolinis partneris yra pasirengęs.

Ta pati logika atmeta įprastas alternatyvas. Darbalaukio automatinio paleidimo įrašas laukia naudotojo sesijos, kuri serveryje gali niekada neatsidaryti, o atidėta cron komanda prideda praėjusį laiką neįvardydama ištekliaus, kurio tikėjosi sulaukti. Abu gali mėnesiais atrodyti sėkmingi ir tada nepavykti per vienintelę įkrovą, kuri yra svarbi.

Patikrinkite prisirišimą po šaltos įkrovos

Tikrinkite tikra šalta įkrova, o ne paslaugos perkrovimu, nes perkrovimas paveldi adresą, kurį įkrovos seka turėjo sukurti. Po įkrovos ss -lntp arba ss -lunp rodo vietinį adresą, prie kurio kiekvienas klausytojas iš tikrųjų prisirišo, o journalctl -b -u openvpn-server@server rodo, ar pirmasis bandymas nepavyko. Palyginkite prisirištą adresą su esančiu profilyje, tada pakartokite palyginimą po tinklo prisijungimo iš naujo.

Jei profiliui niekada nereikėjo fiksuoto adreso, local pašalinimas yra teisėtas supaprastinimas, bet padarykite tai saugumo sprendimu, o ne trikčių šalinimo įpročiu.

Klausytojo išplėtimas keičia, kas gali jį pasiekti, todėl suderinkite tą pakeitimą su ugniasienės politika, kuri turėjo jį riboti. Paslauga, kuri patikimai paleidžiama kiekvienoje sąsajoje, neišsprendė pradinės problemos; ji perkėlė problemą į tinklo kraštą.

Susiję straipsniai