Pag-restart ng serbisyo sa OpenVPN up: mas mabuti ang hooks kaysa tun0.device

Ang pagkonekta ng dependent na serbisyo sa tun0.device ay parang pag-subscribe sa tunnel, at hindi ito ganoon. Ipinapakita ng unit ng device na umiiral ang interface, na maaaring manatiling totoo sa buong nabigong koneksyon at sa muling pagkonekta na sumusunod. Pagkatapos ay kumikilos ang serbisyo sa maling sandali, o hindi kailanman, depende sa kung nawala ang interface sa pagitan. Ang hook na naglalarawan ng kaganapang talagang mahalaga sa iyo ay ang tinatawag ng OpenVPN, hindi ang hinihinuha ng systemd.

Magpasya kung anong kondisyon ang kailangan ng serbisyo bago piliin ang trigger, dahil ang tatlong kandidato ay hindi mapagpapalit.

Ano ba talaga ang sinusubaybayan ng unit ng device

Gumagawa ang systemd ng unit ng device mula sa pananaw ng kernel sa isang network interface, kaya nagiging aktibo ang tun0.device kapag lumitaw ang interface at hindi aktibo kapag tinanggal ito. Sa persist-tun, pinapanatili ng malambot na restart ang interface sa puwesto, kaya hindi kailanman nag-flap ang unit at walang nakatali dito ang natitiklop. Kahit walang pagtitiyaga, wala ring sinasabi ang unit tungkol sa mga ruta, DNS, o kung tumutugon ang malayong dulo.

Ginagawa nitong mahinang pamalit ito para sa 'handa na ang VPN'. Ang tagapakinig na kailangan lang ang lokal na address ay maaaring masiyahan sa pag-iral ng interface, samantalang ang serbisyong tumatawag ng application sa malayong network ay nangangailangan ng mga ruta at maabot, na hindi maipahayag ng unit ng device.

Ang up, route-up at up-restart ay may magkakaibang kahulugan

Tumatakbo ang up pagkatapos buksan ang TUN/TAP device at i-configure ang interface, na tamang sandali para sa tagapakinig na nagbibigkis sa itinalagang address. Tumatakbo ang route-up pagkatapos i-install ang mga ruta, napapailalim sa anumang naka-configure na pagkaantala ng ruta, at angkop sa gawaing nangangailangan ng kumpletong yugto ng ruta. Wala sa dalawa ang nagpapatunay na tumutugon ang malayong application. Ang pagpili sa pagitan nila ay tanong kung ano ang kailangan ng serbisyo, hindi kung aling hook ang mas ganap na pakinggan.

Sa persist-tun, muling ginagamit ng mga restart ang device, kaya hindi na tumatakbo muli ang up maliban kung nakatakda ang up-restart. Pinapagana ng opsyong iyon ang script na up para sa dokumentadong lifecycle ng restart, at ang kapaligiran nito ay nabawasan kumpara sa unang pag-start. Ang script na ipinapalagay na buo ang kapaligiran ay gumagana sa unang koneksyon at nabibigo sa susunod.

Ipadala ang aksyon nang hindi ito hinihintay

Ang hook na tumatawag sa systemctl restart nang synchronous ay maaaring ma-deadlock laban sa isang unit na ang pagkakasunod-sunod ay naghihintay sa tunnel. Inilalagay ng systemctl --no-block try-restart vpn-dependent.service ang trabaho sa pila at bumabalik, na pumipigil sa hook na harangin ang koneksyong tinutugunan nito. Kumikilos ang try-restart sa tumatakbong unit lamang, samantalang sinisimulan din ng restart ang isang hindi aktibo; pumili nang sadya, hindi dahil sa ugali.

Ang paglalagay sa pila ay hindi pagpapatunay. Nagbabalik ng tagumpay ang hook sa sandaling tanggapin ang trabaho, kaya ang pagsusuri ay dapat mangyari sa journal ng target na unit o sa aktwal na estado ng tagapakinig nito.

Nakatira ang patakaran sa restart sa unit, hindi sa hook

Ang oneshot na unit na may RemainAfterExit=yes ay nananatiling aktibo pagkatapos lumabas ang utos nito, at ang ikalawang kahilingan sa pagsisimula ay walang ginagawa dahil itinuturing ito ng systemd na nasimulan na. Ito ay katangiang dapat idisenyo, hindi depektong nilalampasan ng paulit-ulit na tawag sa pagsisimula. Kung ang aksyon ay dapat tumakbo bawat koneksyon, kailangan ng unit ang anyong nagpapahintulot nito.

Inaayos ng After= ang mga unit, at nagbibigkis ang BindsTo= ng mga habang-buhay, ngunit wala sa dalawa ang nangangahulugang 'i-restart ito sa tuwing muling kokonekta ang VPN'. Ang unit na nakatali sa tunnel ay humihinto kapag huminto ang tunnel; hindi ito nag-restart sa sarili kapag bumalik ang tunnel maliban kung may magsimula muli.

Subukan ang tatlong muling pagkonekta, hindi isa

Ang cold boot, buong restart ng client at malambot na muling pagkonekta ay nagsasanay ng magkakaibang landas. Ang malambot na muling pagkonekta ang naglalantad ng nawawalang up-restart, nabawasang kapaligiran o unit ng device na hindi kailanman naging hindi aktibo. Patakbuhin ang tatlo at kumpirmahin ang dalawang direksyon: kumikilos ang serbisyo kapag tumaas ang tunnel, at hindi ito nag-restart sa mga pagbabago sa link na walang kaugnayan tulad ng Wi-Fi roaming.

Panatilihin ang independiyenteng landas ng pagbawi kapag ang dependent na serbisyo ay nagdadala ng sarili mong administratibong pag-access. Ang hook na nag-restart sa bagay na kinokonektahan mo ay pagbabagong maaaring mag-lock sa iyo.