Ar OpenVPN kabliuko scenarijus gali naudotis tuneliu, kurį ką tik sukūrė?

Ar kabliuko scenarijus pasieks kitą tunelio pusę, priklauso nuo trijų sąlygų: prie kokio įvykio jis prijungtas, ar OpenVPN vis dar yra savo paleidimo sekoje, kai scenarijus vykdomas, ir ar darbas atskirtas nuo tos sekos. Dauguma scenarijų nepavyksta ties trečiąja. Miego pridėjimas traktuoja gyvavimo ciklo problemą kaip laiko problemą, ir jis veikia kaip tik pakankamai dažnai, kad suklaidintų.

Pirmiausia nuspręskite įvykį, po to darbo atidėjimo mechanizmą, po to vietą, kurioje vykdomas atidėtas darbas. Šie trys sprendimai nepriklausomi, ir jų sumaišymas yra tai, kaip dviejų eilučių kabliukas tampa visu popiete.

Kodėl kabliukas laukia tunelio, kuris laukia jo

OpenVPN kviečia savo kabliukus sinchroniškai, tame pačiame procese, kuris judina paketus. up suveikia, kai tun arba tap įrenginys jau yra, bet prieš pridedant bet kokį maršrutą, o route-up suveikia po maršrutų; nė vienas iš šių momentų nežada, kad kita pusė atsakys. Kol bet kurio kabliuko scenarijus dar vykdomas, demonas nepersiunčia, todėl komanda, kuri tikisi, kad srautas kirs tunelį, laukia tunelio, kuris laukia komandos. Šis cikliškas laukimas yra priežastis, kodėl rankinis paleidimas praeina, o kabliukas baigia laiką.

Akivaizdus lopas, kelių sekundžių miegas, kartais veikia todėl, kad tolimasis galas pakilo pats, o ne todėl, kad miegas ką nors pataisė. Pasiruošimą klausiantis pagalbininkas yra kitas atsakymas: kabliukas grįžta, persiuntimas prasideda, ir pagalbininkas gauna, ko jam reikia, kai tai tikrai yra.

Rinkitės kabliuką pagal įvykį, o ne pagal patogumą

Prijunkite up prie darbo, kuriam reikia tik įrenginio, route-up prie darbo, kuriam reikia maršrutų, o client-connect ir client-disconnect palikite užduotims pagal klientą serverio pusėje. Valymas atjungiant turi išlaikyti dvigubą vykdymą, nes prisijungimai iš naujo per nuolatinę sąsają nesilaiko tos pačios sekos kaip visiškas paleidimas iš naujo. Serveryje client-connect suveikia, kai klientas autentifikuojasi, o ne kai demonas paleidžiamas, tai verta patvirtinti prieš perkeliant logiką ten. Jei darbas priklauso paslaugos gyvavimo ciklui, o ne vienam ryšiui, systemd įrenginys yra geresni namai nei bet kuris kabliukas.

Kabliuko komandas demonas vykdo tiesiogiai, be apvalkalo tarp, todėl ifconfig_remote eilutėje up atvyksta kaip pažodinis tekstas. Apvyniokite komandą į aiškų apvalkalą arba laikykite logiką scenarijuje, kuris skaito aplinką. ipchange yra viena direktyva, kuri prideda savo argumentus: ji perduoda adresą ir prievadą komandai, todėl scenarijus, parašytas niekam, mato du netikėtus.

Trys būdai atskirti darbą

Pirmas variantas yra siųsti pagalbininką į foną iš kabliuko vidaus: paleiskite jį su setsid arba systemd-run --scope, uždarykite paveldėtus deskriptorius ir iškart išeikite su nuliu. Antrasis — leisti kabliukui įrašyti nedidelį būsenos failą ir leisti systemd laikmačiui ar kelio įrenginiui juo veikti, o tai palieka kabliuką trivialų ir padeda pakartojimo politiką ten, kur yra žurnalai. Trečiasis — visiškai atsisakyti kabliuko ir perkelti darbą į įrenginį, išdėstytą po VPN paslaugos, o tai yra teisingas atsakymas, kai darbas visai ne pagal ryšį. Visi trys dalijasi viena taisykle: kabliukas turi grįžti, kol jam dar nereikia tunelio.

Kad ir ką pasirinktumėte, padarykite pagalbininką idempotentišką ir stebimą. Du persidengiantys iškvietimai neturėtų du kartus atlikti to paties negrįžtamo veiksmo, o nepavykęs pagalbininkas turi palikti tai, ką žmogus gali perskaityti.

Atskirkite smėlio dėžės gedimus nuo gyvavimo ciklo gedimų

Kai scenarijus vykdomas iš root raginimo ir nepavyksta kaip paslauga, priežastis paprastai yra smėlio dėžė, o ne tinklas. Ribojantis ProtectHome, tik skaitymui skirtas ProtectSystem arba darbo katalogas, kurio nėra gali padaryti scenarijų ar jo duomenis nepasiekiamus, o SELinux hoste failui taip pat reikia konteksto, kuris leidžia vykdymą. Skaitykite įrenginį su systemctl cat openvpn-server@server ir žurnalą su journalctl -u openvpn-server@server -n 80, tada ieškokite leidimų ar konteksto klaidos, o ne ryšio laiko viršijimo. Smėlio dėžės išjungimas turėtų būti paskutinis žingsnis, o ne pirmas.

Gyvavimo ciklo gedimas atrodo kitaip: kabliukas pradeda, pagalbininkas veikia, o lizdo tiesiog dar nėra. Parašykite eilutę su laiko žyma iš paties kabliuko, atjunkite ir prijunkite iš naujo, ir skaitykite įvykius iš eilės. Kai pagalbininkui tikrai reikia tunelio, leiskite jam klausti pasiruošimo, o ne miegoti fiksuotą laiką.

Trys laukai padaro kitą ataskaitą naudingą: kuris kabliukas veikė, kurią paskyrą naudojo ir kur sustojo. Be jų kiekvienas vėlesnis tyrimas prasideda iš naujo.