OpenVPN įspėjimas dėl kelių --up scenarijų: vykdomas tik vienas

Įspėjimas dėl kelių scenarijų skamba kaip planavimo skundas, todėl akivaizdus sprendimas yra perrinkti eilutes, kol jis išnyks. Bet tai ne planavimo skundas. Vėlesnis --up apibrėžimas pakeičia komandą, jau saugomą tam etapui, ir analizatorius taip sako, vadinasi, iš dviejų jūsų scenarijų kada nors veikė lygiai vienas. Kitas jo gale eilėje nelaukia; jis dingo.

Todėl įspėjimas vertas dėmesio, nors ir ne mirtinas: jis numato DNS atnaujinimą ar maršruto pakeitimą, kuris tyliai nustojo vykti.

Įspėjimas ne apie tvarką

OpenVPN saugo vieną naudotojo scenarijaus komandą up etapui. Kai analizatorius sutinka kitą apibrėžimą, iš profilio, įtraukto failo ar komandinės eilutės, jis pakeičia tai, ką jau turėjo, ir pateikia įspėjimą. Niekas nesujungiama, niekas nevykdoma du kartus ir tvarkos klausimo nėra. Išlieka ta komanda, kurią analizatorius matė paskutinę, todėl eilutės perkėlimas gali pakeisti nugalėtoją, o kitas scenarijus lieka miręs.

Ta pati schema galioja ir kitiems scenarijų etapams: po vieną komandą kiekvienam. Jei du darbai turi įvykti abu, jiems reikia vieno įėjimo taško, o ne dviejų nurodymų, primenančių sąrašą.

Raskite abu apibrėžimus tikrame paleidime

Pradėkite nuo to, ką demonas tikrai gavo, o ne nuo profilio, kurį redagavote. ps -ef ir įrenginio ExecStart rodo komandinę eilutę, į kurią konteinerio įėjimo taškas ar apvalkalas gali pridėti --up; platinimo init failas gali padaryti tą patį. systemctl cat openvpn-server@server atskleidžia, ką prideda pati paslauga, o rekursyvus grep konfigūracijos kataloge randa failų lygio apibrėžimus. Dublikatai paprastai ateina iš skirtingų sluoksnių, ir būtent todėl vieno failo redagavimas nieko nekeičia.

Scenarijaus kopijavimas į kitą katalogą ar pervadinimas taip pat nepašalina nurodymo. Analizatorius skaičiuoja apibrėžimus, o ne failus.

Tegul vienas hook atlieka darbą

Ilgalaikis sprendimas yra vienas siuntėjas, atliekantis abu veiksmus apgalvota tvarka. Trumpas shell scenarijus su set -eu, kuris iškviečia reikiamą integraciją ir tada vietinį veiksmą bei perduoda "$@", kad argumentų ribos išliktų, laiko elgesį vienoje tikrinamoje vietoje. Argumentų perdavimas juos tik išsaugo; jis neįrodo, kad abu pagalbininkai tikisi tos pačios sąsajos, todėl perskaitykite kiekvieno sutartį. Nuspręskite, ką turi daryti klaida ir ar dalinius pakeitimus reikia atšaukti.

Jei paleidiklis siūlo palaikomą plėtinio hook, rinkitės jį, o ne rankomis sukurtą grandinę. Konteinerio atvaizdas ar tiekėjo paketas dažnai turi dokumentuotą vietą papildomam darbui, ir jo naudojimas neleidžia naujinimui perrašyti jūsų siuntėjo.

Valymas priklauso atitinkamam down etapui. Up veiksmas, perrašantis DNS ar pridedantis maršrutus, reikalauja dokumentuoto atšaukimo, o siuntėjas, kuris tvarko tik paleidimą, yra pusė dizaino.

Patvirtinkite integraciją, o ne tik tylą

Pašalinti pasikartojantį įspėjimą yra lengvoji dalis; integracija vis tiek turi veikti. Po prisijungimo patikrinkite sprendiklio būseną su resolvectl status arba perskaitę /etc/resolv.conf, ir patvirtinkite maršrutus su ip route. Tada atsijunkite ir vėl prisijunkite, nes paskubomis sujungtas hook linkęs palikti ką nors iš ankstesnės sesijos. journalctl -u openvpn-server@server -b parodo, ar jūsų siuntėjas veikė ir ką jis išspausdino.

Laikykite hook privilegijas ten, kur jos priklauso. script-security didinimas ar demono paleidimas su daugiau teisių nėra pakeisto hook sprendimas; tai išplečia, ką gali daryti kiekvienas būsimas scenarijus, įskaitant tą, kurį pavadins užpuolikas.

Ženklas, kad sprendimas tikras, yra ne tyla žurnale. Tai DNS atsakymas, maršruto įrašas ir valymas, kurie visi veikia po dviejų prisijungimų iš naujo.