Restartigi servon ĉe OpenVPN up: hokoj superas tun0.device

Konekti dependan servon al tun0.device aspektas kiel aboni la tunelon, kaj ĝi ne estas. Aparata unuo reflektas, ke la interfaco ekzistas, kio povas resti vera tra malsukcesa konekto kaj la rekonkto, kiu sekvas. Tiam la servo agas en la malĝusta momento, aŭ neniam, laŭ tio, ĉu la interfaco malaperis intere. La hoko, kiu priskribas la eventon, pri kiu vi vere zorgas, estas tiu, kiun vokas OpenVPN, ne tiu, kiun deduktas systemd.

Decidu, kiun kondiĉon la servo bezonas, antaŭ ol elekti la ellasan kaŭzon, ĉar la tri kandidatoj ne estas interŝanĝeblaj.

Kion la aparata unuo vere spuras

systemd kreas aparatan unuon el la vidpunkto de la kerno pri reta interfaco, do tun0.device aktiviĝas kiam la interfaco aperas kaj malaktiviĝas kiam ĝi foriĝas. Kun persist-tun, mola restartigo konservas la interfacon en loko, do la unuo neniam flirtas kaj nenio ligita al ĝi estas ekigata. Eĉ sen persisteco, la unuo diras nenion pri itineroj, DNS aŭ ĉu la malproksima fino respondas.

Tio igas ĝin malbona anstataŭanto por 'la VPN estas preta'. Aŭskultanto, kiu bezonas nur la lokan adreson, povas kontentiĝi per la ekzisto de la interfaco, dum servo, kiu vokas aplikaĵon en la malproksima reto, bezonas itinerojn kaj atingeblon, kion la aparata unuo ne povas esprimi.

up, route-up kaj up-restart signifas malsamajn aferojn

up ruliĝas post kiam la TUN/TAP-aparato malfermiĝis kaj la interfaco agordiĝis, kio estas la ĝusta momento por aŭskultanto, kiu ligas la asignitan adreson. route-up ruliĝas post kiam itineroj instaliĝis, submetita al ajna agordita itinera prokrasto, kaj taŭgas por laboro, kiu bezonas la itineran fazon kompleta. Neniu el ili pruvas, ke la malproksima aplikaĵo respondas. Elekti inter ili estas demando pri tio, kion la servo bezonas, ne pri tio, kiu hoko sonas pli finita.

Kun persist-tun, restartigoj reuzas la aparaton, do up ne ruliĝas denove krom se up-restart estas agordita. Tiu opcio ebligas la skripton up por la dokumentita restartiga vivciklo, kaj ĝia medio estas reduktita kompare kun unua starto. Skripto, kiu supozas la plenan medion, funkcias ĉe la unua konekto kaj malsukcesas ĉe la sekva.

Sendu la agon sen atendi ĝin

Hoko, kiu vokas systemctl restart sinkrone, povas blokiĝi kontraŭ unuo, kies ordo atendas la tunelon. systemctl --no-block try-restart vpn-dependent.service enigas la taskon en la vicon kaj revenas, kio malhelpas la hokon bloki la konekton, al kiu ĝi reagis. try-restart agas nur sur ruliĝanta unuo, dum restart ankaŭ startas malaktivan; elektu intence, ne pro kutimo.

Enigi en vicon ne estas kontrolado. La hoko revenigas sukceson tuj kiam la tasko akceptiĝas, do la kontrolo devas okazi en la ĵurnalo de la cela unuo aŭ en ĝia reala aŭskultanta stato.

Restartiga politiko loĝas en la unuo, ne en la hoko

oneshot-unuo kun RemainAfterExit=yes restas aktiva post kiam ĝia komando eliras, kaj dua startpeto faras nenion ĉar systemd konsideras ĝin jam startinta. Tio estas eco, ĉirkaŭ kiu oni projektas, ne difekto, kiun oni evitas per ripetaj startvokoj. Se la ago devas ruliĝi po konekto, la unuo bezonas formon, kiu permesas tion.

After= ordigas unuojn, kaj BindsTo= ligas vivdaŭrojn, sed nek tio signifas 'restartigu ĉi tion kiam ajn la VPN rekonektiĝas'. Unuo ligita al la tunelo haltas kiam la tunelo haltas; ĝi ne restartigas sin kiam la tunelo revenas, krom se io startas ĝin denove.

Testu tri rekonktojn, ne unu

Malvarma starto, plena klienta restartigo kaj mola rekonkto ĉiu ekzercas malsaman vojon. La mola rekonkto estas tiu, kiu malkaŝas mankantan up-restart, reduktitan medion aŭ aparatan unuon, kiu neniam malaktiviĝis. Rulu ĉiujn tri kaj konfirmu ambaŭ direktojn: la servo agas kiam la tunelo supreniras, kaj ĝi ne restartigas ĉe nerilataj ligilaj ŝanĝoj kiel Wi-Fi-romado.

Konservu sendependan restaŭran vojon kiam la dependa servo portas vian propran administran aliron. Hoko, kiu restartigas tion, tra kio vi estas konektita, estas ŝanĝo, kiu povas ŝlosi vin ekstere.