Rekonekti OpenVPN-klienton: tri regiloj, tri ampleksoj

Iu petas, ke la VPN-kliento estu rekonektita, kaj tiu peto povas signifi tri malsamajn aferojn. Ĝi povas signifi forigon de unu aŭtentikigita seanco, informadon de ĉiu kliento, ke UDP-servilo foriras, aŭ restartadon de la demono mem. Ĉiu havas malsaman efikan radiuson, kaj malĝusta elekto transformas riparon por unu uzanto en servinterrompon. La amplekso estas la decido, kaj la komando sekvas el ĝi.

Demandu, kiun ĝi tuŝu, antaŭ ol demandi, kiun regilon uzi.

Unu ekzemplero: la administra interfaco

Agordita administra interfaco povas listigi konektitajn ekzemplerojn kaj forigi precize unu el ili. Ĉiu seanco portas klientan identigilon, kaj client-kill CID celas tiun identigilon anstataŭ komunan nomon. Legu la vivan identigilon el la nuna statusa eligo, ĉar valoro kopiita el pli malnova protokolo rilatas al seanco, kiu ne plu ekzistas. Forigi la ekzempleron finas tiun konekton kaj nenion alian.

Ĝi ne garantias novan konekton. Ĉu la kliento revenos, dependas de ĝiaj ripetaj agordoj, ĝiaj restantaj malproksimaj eroj, ĝiaj aŭtentikigaj postuloj kaj de tio, ĉu la kontrolanta aplikaĵo ankoraŭ funkcias. Revenanta kliento ricevas novan identigilon, kaj tial komparo de identigiloj estas la sola fidinda maniero distingi malnovan de nova.

UDP-elira sciigo ne estas komando por unuopa kliento

explicit-exit-notify estas agorda direktivo pri eliraj kaj restartaj eventoj. Ĉe UDP-kliento ĝi diras al la alia flanko, ke la seanco finiĝas, kaj la nombra argumento regas, kiom da fojoj la sciigo ripetiĝas. Kiam la servilo funkcias per UDP, ĝi sendas restartan kontrolmesaĝon al siaj konektitaj klientoj, kaj la dokumentitaj valoroj distingas rekonekton al la sama servilo de transiro al alia malproksima ero. Tio estas vivcikla signalo kun vasta publiko.

Nenio en ĝi elektas arbitran klienton en arbitra momento. Trakti ĝin kiel rekonektan butonon atingas ĉiun konektitan seancon samtempe.

Signaloj agas sur la procezon, ne sur la seancon

SIGUSR1 petas de funkcianta procezo restarti sian konekton sen relegi la agordon, kaj la persistaj opcioj decidas, kio postvivos tiun restartigon. SIGHUP iras plu: ĝi relegas la agordan dosieron kaj remalfermas siajn rimedojn. SIGTERM kaj SIGINT petas ordan haltigon. Tiuj estas operacioj je proceza nivelo: ĉe servilo kun multaj klientoj ili tuŝas ĉiun seancon, kiun la procezo portas, ne tiun nomitan en la bileto.

Kiam la procezo funkcias sub serva administrilo, uzu la propran regilon de la administrilo anstataŭ sendi signalon al PID, kiun vi trovis en proceza listo. Legu la unuon por vidi, kiun signalon la administrilo sendas, ĉar restartigo kaj reŝargo faras malsamajn aferojn al la sama demono.

Decidu la amplekson antaŭ ol elekti la regilon

Tri demandoj decidas tion. Kiun ĝi tuŝu: unu uzanton, ĉiun klienton de unu servilo, aŭ la demonon kaj ĉion, kion ĝi portas. Kio postvivu: la agordo, la tunela stato aŭ nenio. Kiu rajtas fari tion: la administra integriĝo, la serva posedanto aŭ la reta operatoro, kiu regas la eliran sciigon. Respondu tion, kaj nur unu regilo taŭgas.

Aldoni neaŭtentikigitan administran aŭskultilon por akiri rekonektan butonon transdonas al iu ajn, kiu povas atingi la pordon, multe pli ol tiun butonon.

Kontrolu la novan seancon, ne la malkonekton

Malkonekta evento pruvas, ke la malnova seanco finiĝis. Ĝi diras nenion pri nova, kiu aŭtentikiĝas, ricevas adreson, instalas itinerojn aŭ atingas la rimedon, kiun la uzanto bezonis. Kontrolu la novan identigilon, poste la tunelan staton, poste unu realan rimedon. Tiuj tri paŝoj estas la diferenco inter rekonekto kaj funkcianta konekto.

Skribu la amplekson en la ŝanĝprotokolon. „Mi rekonektis la klienton“ ne estas priskribo, kiam la kliento estis unu el kvardek en komuna servilo.