Maaari bang gamitin ng isang OpenVPN hook script ang tunnel na katatayo pa lang nito?

Kung maaabot ng hook script ang kabilang dulo ng tunnel ay nakasalalay sa tatlong kondisyon: kung aling pangyayari ito nakakabit, kung nasa loob pa ng sequence ng pagsisimula ang OpenVPN kapag tumatakbo ang script, at kung nahiwalay na ang gawain mula sa sequence na iyon. Karamihan sa mga script ay nabibigo sa pangatlo. Ang pagdaragdag ng pagtulog ay tinatrato ang problema sa lifecycle bilang problema sa timing, at gumagana ito nang sapat na madalas upang magligaw.

Pagpasyahan muna ang pangyayari, pagkatapos ang mekanismo ng pagpapaliban ng gawain, pagkatapos ang lugar kung saan tumatakbo ang naipalibanag gawain. Ang tatlong pasyang ito ay independiyente, at ang paghahalo sa mga ito ang dahilan kung bakit nagiging isang buong hapon ang dalawang linyang hook.

Bakit naghihintay ang hook sa tunnel na naghihintay dito

OpenVPN tinatawag ang mga hook nito nang synchronous, sa loob ng parehong prosesong naglilipat ng packet. up ay pumapasok kapag umiiral na ang tun o tap device pero bago pa magdagdag ng anumang ruta, at route-up ay pumapasok pagkatapos ng mga ruta; wala sa mga sandaling iyon ang nangangako na sasagot ang kabilang panig. Habang tumatakbo pa ang script ng alinmang hook, hindi nagpapasa ang daemon, kaya ang utos na umaasang tatawid ang trapiko sa tunnel ay naghihintay sa tunnel na naghihintay sa utos. Ang paikot na paghihintay na ito ang dahilan kung bakit pumapasa ang manu-manong pagpapatakbo at nag-timeout ang hook.

Ang halatang tapal, ang pagtulog ng ilang segundo, ay paminsan-minsang gumagana dahil kusang umangat ang malayong dulo, hindi dahil may inayos ang pagtulog. Ang katulong na nagtatanong tungkol sa kahandaan ay ibang sagot: bumabalik ang hook, nagsisimula ang pagpapasa, at nakukuha ng katulong ang kailangan nito kapag talagang naroon na ito.

Piliin ang hook ayon sa pangyayari, hindi ayon sa kaginhawahan

Ikabit ang up sa gawaing nangangailangan lamang ng device, ang route-up sa gawaing nangangailangan ng mga ruta, at itabi ang client-connect at client-disconnect para sa mga gawain bawat kliyente sa panig ng server. Ang paglilinis sa pag-disconnect ay dapat makayanan ang pagtakbo nang dalawang beses, dahil ang muling pagkonekta sa isang permanenteng interface ay hindi sumusunod sa parehong sequence ng isang buong restart. Sa server, pumapasok ang client-connect kapag nagpapatunay ang kliyente, hindi kapag nagsisimula ang daemon, na sulit tiyakin bago ilipat doon ang lohika. Kung ang gawain ay kabilang sa lifecycle ng serbisyo at hindi sa isang koneksyon, ang systemd unit ay mas mabuting tahanan kaysa sa anumang hook.

Ang mga utos ng hook ay direktang pinapatakbo ng daemon, walang shell sa pagitan, kaya ang ifconfig_remote sa linyang up ay dumarating bilang literal na teksto. Balutin ang utos sa malinaw na shell, o itago ang lohika sa script na nagbabasa ng kapaligiran. Ang ipchange ay isang direktiba na nagdaragdag ng sarili nitong argumento: ibinibigay nito sa utos ang address at port, kaya ang script na isinulat para sa wala ay nakakakita ng dalawang hindi inaasahan.

Tatlong paraan upang ihiwalay ang gawain

Ang unang opsyon ay ipadala ang katulong sa background mula sa loob ng hook: simulan ito gamit ang setsid o systemd-run --scope, isara ang mga namana na descriptor, at lumabas agad nang may zero. Ang pangalawa ay hayaang magsulat ang hook ng maliit na file ng estado at hayaang kumilos dito ang isang systemd timer o path unit, na nagpapanatiling simple ng hook at naglalagay ng patakaran sa pagsubok muli kung saan may mga log. Ang pangatlo ay tuluyang iwanan ang hook at ilipat ang gawain sa isang unit na inayos pagkatapos ng serbisyo ng VPN, na siyang tamang sagot kapag ang gawain ay hindi talaga bawat koneksyon. Lahat ng tatlo ay nagbabahagi ng isang tuntunin: dapat bumalik ang hook bago nito kailanganin ang tunnel.

Anuman ang piliin mo, gawing idempotent at napapansin ang katulong. Ang dalawang magkapatong na tawag ay hindi dapat magsagawa ng parehong hindi maibabalik na aksyon nang dalawang beses, at ang katulong na nabibigo ay dapat mag-iwan ng isang bagay na mababasa ng tao.

Ihiwalay ang mga pagkabigo sa sandbox mula sa mga pagkabigo sa lifecycle

Kapag tumatakbo ang script mula sa root prompt at nabibigo bilang serbisyo, ang sanhi ay karaniwang sandbox at hindi network. Ang mahigpit na ProtectHome, ang read-only na ProtectSystem, o isang working directory na wala ay maaaring gawing hindi maabot ang script o ang data nito, at sa isang SELinux host kailangan din ng file ng context na nagpapahintulot sa pagpapatupad. Basahin ang unit gamit ang systemctl cat openvpn-server@server at ang journal gamit ang journalctl -u openvpn-server@server -n 80, pagkatapos ay humanap ng error sa pahintulot o context sa halip na timeout ng koneksyon. Ang pag-disable sa sandbox ay dapat ang huling hakbang, hindi ang una.

Ang pagkabigo sa lifecycle ay iba ang hitsura: nagsisimula ang hook, tumatakbo ang katulong, at wala pa talaga ang socket. Sumulat ng linyang may timestamp mula sa hook mismo, idiskonekta at ikonekta muli, at basahin ang mga pangyayari ayon sa pagkakasunod-sunod. Kapag talagang kailangan ng katulong ang tunnel, hayaang magtanong ito tungkol sa kahandaan sa halip na matulog nang takdang panahon.

Tatlong field ang nagpapaging kapaki-pakinabang ng susunod na ulat: aling hook ang tumakbo, aling account ang ginamit, at saan ito tumigil. Kung wala ang mga ito, bawat susunod na imbestigasyon ay nagsisimula sa simula.