Ponovno povezovanje odjemalca OpenVPN: tri nadzori, tri obsegi

Nekdo prosi, da se odjemalec VPN znova poveže, in ta zahteva lahko pomeni tri različne stvari. Lahko pomeni spust ene overjene seje, obvestilo vsakemu odjemalcu, da strežnik UDP odhaja, ali ponoven zagon samega demona. Vsaka ima drugačen polmer vpliva, in napačna izbira spremeni popravek za enega uporabnika v izpad. Obseg je odločitev, in ukaz izhaja iz njega.

Vprašajte, koga naj to prizadene, preden vprašate, kateri nadzor uporabiti.

En primerek: vmesnik za upravljanje

Nastavljen vmesnik za upravljanje lahko našteje povezane primerke in spusti natanko enega od njih. Vsaka seja nosi identifikator odjemalca, in client-kill CID cilja na ta identifikator namesto na skupno ime. Preberite živi identifikator iz trenutnega izhoda stanja, ker se vrednost, kopirana iz starejšega dnevnika, nanaša na sejo, ki ne obstaja več. Spust primerka konča to povezavo in nič drugega.

Ne zagotavlja nove povezave. Ali se odjemalec vrne, je odvisno od njegovih nastavitev ponovnih poskusov, preostalih oddaljenih vnosov, zahtev za preverjanje pristnosti in od tega, ali nadzorna aplikacija še teče. Odjemalec, ki se vrne, dobi nov identifikator, zato je primerjanje identifikatorjev edini zanesljiv način za ločevanje starega od novega.

Obvestilo o izhodu UDP ni ukaz za posameznega odjemalca

explicit-exit-notify je konfiguracijska direktiva o dogodkih izhoda in ponovnega zagona. Na odjemalcu UDP sporoči drugi strani, da se seja konča, in številski argument nadzoruje, kolikokrat se obvestilo ponovi. Ko strežnik teče prek UDP, pošlje povezanim odjemalcem krmilno sporočilo o ponovnem zagonu, in dokumentirane vrednosti razlikujejo ponovno povezavo z istim strežnikom od prehoda na drug oddaljeni vnos. To je signal življenjskega cikla s širokim občinstvom.

Nič v njem ne izbere poljubnega odjemalca v poljubnem trenutku. Če ga obravnavate kot gumb za ponovno povezavo, doseže vse povezane seje hkrati.

Signali delujejo na proces, ne na sejo

SIGUSR1 prosi delujoči proces, naj znova zažene svojo povezavo brez ponovnega branja konfiguracije, in možnosti obstojnosti odločajo, kaj ta ponovni zagon preživi. SIGHUP gre dlje: znova prebere konfiguracijsko datoteko in znova odpre svoje vire. SIGTERM in SIGINT zahtevata urejeno zaustavitev. To so operacije na ravni procesa: na strežniku z mnogimi odjemalci prizadenejo vsako sejo, ki jo proces nosi, ne tiste, imenovane v zahtevi.

Ko proces teče pod upraviteljem storitev, uporabite njegov lastni nadzor namesto pošiljanja signala PID, ki ste ga našli na seznamu procesov. Preberite enoto, da vidite, kateri signal pošilja upravitelj, ker ponovni zagon in ponovno nalaganje naredita z istim demonom različne stvari.

Določite obseg, preden izberete nadzor

Tri vprašanja to razrešijo. Koga naj prizadene: enega uporabnika, vse odjemalce enega strežnika ali demon in vse, kar nosi. Kaj naj preživi: konfiguracija, stanje tunela ali nič. Kdo je za to pooblaščen: integracija upravljanja, lastnik storitve ali omrežni operater, ki nadzoruje obvestilo o izhodu. Odgovorite in ustreza le en nadzor.

Dodajanje neoverjenega upravljalnega poslušalca za gumb za ponovno povezavo preda vsakomur, ki doseže vrata, veliko več kot ta gumb.

Preverite novo sejo, ne prekinitve

Dogodek prekinitve dokazuje, da se je stara seja končala. Nič ne pove o novi, ki se overja, prejme naslov, namesti poti ali doseže vir, ki ga je uporabnik potreboval. Preverite novi identifikator, nato stanje tunela, nato en resničen vir. Ti trije koraki so razlika med ponovno povezavo in delujočo povezavo.

Zapišite obseg v dnevnik sprememb. „Odjemalca sem znova povezal“ ni opis, ko je bil odjemalec eden od štiridesetih na skupnem strežniku.