Nagsimula ba ang up script ng OpenVPN nang masyadong maaga, o hindi kailanman ito naging handa?

Tumatakbo ang up script, lumalabas na may zero, at ang gawain sa loob nito ay hindi naabot ang isang pribadong serbisyo na mula sa terminal ay perpektong gumagana pagkalipas ng dalawang segundo. Ang instinct ay timing, at ang karaniwang pag-aayos ay isang tulog, na nagtatago ng karera nang hindi ito nauunawaan. Ang mas kapaki-pakinabang na pagbasa ay ang “up” ay nagpangalan ng hook, hindi isang garantiya ng kahandaan. Nag-aactivate ito kapag na-configure ang tunnel device, na mas maaga kaysa sa mga ruta, DNS at tiyak na mas maaga kaysa sa anumang aplikasyon sa likod ng tunnel.

Nagtagumpay ang pagsubok sa shell dahil tumakbo ito pagkatapos na maging kalmado ang lahat. Ang hook ay tumakbo sa isang tiyak na sandali.

Saan nakalagay ang up sa pagkakasunod-sunod ng pagsisimula

OpenVPN kino-configure ang tunnel device at pagkatapos ay pinapatakbo ang up hook. Ang pag-install ng ruta ay isang huling yugto, at may sarili itong hook, kaya ang isang gawaing umaasa sa ruta na inilagay sa up ay makakakita ng device na walang kapaki-pakinabang na landas. Ilagay ang gawain sa ruta sa route-up at kadalasan ay nawawala ang problema sa timing.

Dinodokumento ng manwal ang pagkakasunod-sunod na ito at ang kapaligirang natatanggap ng bawat hook. Ang pagkakasunod-sunod na iyon ang buong paliwanag sa klasikong ulat na “gumagana mula sa shell ko”, at ito rin ang dahilan kung bakit ang parehong script ay pumapasa sa isang makina at nabibigo sa isa pa na may mas mabagal na yugto ng ruta. Wala sa alinmang resulta ang nagsasabi ng anuman tungkol sa kalidad ng script.

Ang DNS at kahandaan ng aplikasyon ay dumarating nang mas huli. Kahit ang mga naka-install na ruta ay hindi patunay na nakikinig ang malayong endpoint, na nare-resolve ang isang pangalan, o na mayroong desktop session para sa isang gawaing saklaw ng user.

Ano ang aktwal na namamana ng hook

Tumatakbo ang isang hook sa ilalim ng account at kapaligiran ng proseso ng OpenVPN, na hindi katulad ng iyong interactive na shell. Maaaring kulang ito sa session bus ng user, desktop environment, o kredensyal na nabubuksan lamang sa pag-login. Isulat kung alin sa mga ito ang aktwal na kailangan ng gawain.

Mahalaga ito para sa mga gawaing mukhang networking ngunit nakadepende sa konteksto ng user: pag-mount ng share gamit ang kredensyal ng user, pag-set ng proxy bawat user, o pag-configure ng printer. Ang isang privileged tunnel hook ay maling lugar para sa kanila, at walang tagal ng paghihintay ang makakapag-ayos ng nawawalang session.

Kapag nabigo ang isang gawain sa isang hook, itala ang account, ang kapaligiran, at ang unang operasyong nabigo. Hinihiwalay nito ang maagang timing mula sa problema sa pahintulot o konteksto, at ang dalawa ay may ganap na magkaibang pag-aayos. Ang paghula sa pagitan nila ang paraan kung paano nagiging buong hapon ang limang minutong pag-aayos.

Bakit ang pagdaragdag ng tulog ay hindi pagsusuri ng kahandaan

Ang tulog ay nagpapaantala sa script at naglilipat ng window ng karera. Sa mabilis na araw nagtatagumpay ang gawain; sa mabagal na araw nabibigo itong muli, at nagiging mas mahirap kopyahin ang pagkasira dahil mukhang gumagana ang pagkaantala. Ang pagkaantala na gumagana lamang sa magaan na karga ay isang pagkakataon, hindi pag-aayos.

Kung ang dependency ay isang ruta, gamitin ang hook na tumutugma sa pag-install ng ruta. Kung ang dependency ay isang serbisyo sa likod ng tunnel, gamitin ang limitadong pagsusuri na naghihintay sa partikular na kondisyong iyon at malinaw na nabibigo kapag hindi ito dumating.

Panatilihing hayag ang pagkasira. Ang hook na lumalabas na may zero habang nabigo ang aktwal na gawain nito ay mas masama kaysa sa hook na nabibigo, dahil nagtatala ang service manager ng tagumpay at wala nang tumitingin muli. Ang isang linya ng log mula sa script mismo ang pinakamurang paraan upang mapanatiling tapat ito.

Ang paglilinis at muling pagkonekta ay nararapat sa parehong pag-iingat

Ang script na nagbabago ng shared state ay nangangailangan ng tugmang landas ng pag-undo. Ang mga ruta, resolver entry, at firewall mark na idinagdag ng hook ay dapat idempotent at maibabalik, kung hindi ay magpapatong ang muling pagkonekta ng pangalawang kopya sa una.

Ang muling pagkonekta ay maaari ding magpatakbo ng mga hook nang mas madalas kaysa sa buong pagsisimula ng serbisyo. Ang persistent interface na muling nagtatatag ng session ay maaaring mag-trigger muli ng up at route-up cycle, kaya ang script na ipinapalagay ang isang execution bawat boot ay sa huli ay mag-uugali nang mali. Bilangin ang mga execution sa log sa loob ng isang araw ng pagyugyog upang makita kung gaano kadalas talaga itong tumatakbo. Pagkatapos ay gawing ligtas ang script na patakbuhin nang ganoong karaming beses.

Subukan ang lifecycle na nabigo, hindi ang huling command. Muling likhain ang boot o ang muling pagkonekta, panoorin ang hook na tumatakbo, at kumpirmahin na nagtagumpay ang gawain sa sandaling aktwal itong tumatakbo. Ang tagumpay mula sa isang interactive na shell pagkatapos ay ebidensya tungkol sa dependency, hindi patunay na gumagana ang startup path.

Pangalanan ang kaganapan na nakadepende ang bawat gawain, pagkatapos ay ikabit ang gawain sa kaganapang iyon. Ang lahat ng iba pa ay pagkaantala na nagpapanggap na pagsusuri.