Paano patakbuhin ang OpenConnect sa background pagkatapos ng interactive na login

Tinatapos mo ang MFA prompt, tumataas ang tunnel, at ang pagsasara ng terminal ay kasamang bumababa ang koneksyon. Problema ito sa pangangasiwa, hindi sa pagpapatunay, at mayroon nang switch ang OpenConnect na lumulutas dito. Ang solusyon ay hayaang magsanga ang client sa background kapag tapos na ang startup, kapag tunay nang natapos ang interactive na bahagi. Narito ang pagkakasunod-sunod ng mga pagsusuri: gawin sila nang sunod-sunod at huminto sa unang hindi angkop sa iyong gateway.

Kumpirmahin kung ano ang hinihingi ng gateway sa login

Bago mag-type ng command, isulat ang landas ng kredensyal na ipinipilit ng deployment. Tanging certificate, password at token, at pag-ikot sa browser sa pamamagitan ng SAML provider ay magkakaibang kumilos, at hindi kayang laktawan ng background mode ang alinman. Binabago ng opsyon ang nangyayari pagkatapos ng startup, hindi kailanman ang nangyayari habang ito ay tumatakbo.

Ang tukso ay awtomatikin ang prompt. Ang wrapper na nagta-type ng fixed na sagot kapag nakilala ang password prompt ay nasisira sa sandaling humingi ang gateway ng one-time code, at nag-iiwan ng kredensyal sa file na mababasa ng ibang account. Kung kailangang aprubahan ng tao ang session, panatilihin ang tao sa proseso.

Patakbuhin ang unang session sa foreground at basahin ang output

Kumonekta nang normal isang beses at hayaang mai-print ang buong handshake. Itala ang protocol na ginagamit, ang landas ng certificate o token, ang tunnel address na ibinibigay ng server, at bawat babala bago tanggapin ang koneksyon. Ang transcript na iyon ang iyong baseline at ang tanging murang paraan para makilala sa hinaharap ang problema ng client mula sa pagbabago sa gateway. I-save ito sa labas ng buffer ng terminal.

Pagkatapos ulitin ang parehong invocation na may background mode at idinagdag na PID file, halimbawa openconnect --background --pid-file /run/openconnect.pid vpn.example.net, na pinapanatili ang protocol at mga opsyon sa pagpapatunay na hinihingi ng gateway sa parehong linya. Inilalarawan ng OpenConnect manual ang opsyong iyon bilang pagpapatuloy sa background pagkatapos makumpleto ang startup, at iyon ang dahilan kung bakit dapat munang matapos ang interactive na yugto.

Gawing madaling mahanap at mapahinto ang tumatakbong proseso

Ang PID file ay ebidensya lamang habang tumutugma ito sa buhay na proseso. Ilagay ito sa direktoryo na pagmamay-ari ng service account, at ihambing ang naitalang numero sa talahanayan ng proseso bago magpadala ng anumang signal. Ang mga reboot at crash ay nag-iiwan ng file, at ang lumang file ang karaniwang dahilan kung bakit nag-uulat ng tagumpay ang stop script habang nakaupo pa ang tunnel. Ituring ang pagsusuri bilang bahagi ng pamamaraan ng paghinto, hindi opsyonal na hakbang.

Magpadala ng signal sa verified na PID, pagkatapos kumpirmahin na tunay na nawala ang tunnel interface sa halip na magtiwala sa exit status. Kung kailangan ng client ng mataas na pribilehiyo para i-configure ang interface, ang signal ay dapat magmula sa account na pinapayagang magpadala nito.

Huwag isalansan ang background mode sa ilalim ng supervisor

Ang systemd at katulad na supervisor ay umaasang pagmamay-ari ang prosesong inilunsad nila, kaya nalilito sila ng client na nagsasanga palayo. Nakikita ng supervisor na lumalabas ang launcher habang patuloy na nabubuhay ang tunay na koneksyon, kaya inilalarawan ng restart logic, status reporting at stop timeout ang isang bagay na hindi na totoo. Isulat ang unit sa sinusuportahang foreground arrangement at hayaang gawin ng supervisor ang daemon work.

Itabi ang --background para sa mga session na sinisimulan ng tao at pagkatapos ay umaalis. Kung ang pangangailangan ay tunnel na umiiral bago mag-login ang sinuman, kulang ang aprubadong noninteractive identity at plano para i-renew ito, at walang command-line flag ang nagbibigay ng alinman. Ang pagdaragdag ng flag sa boot script ay gumagawa ng tunnel na tahimik na nabibigo sa unang nag-expire na kredensyal.

Ituring ang session cookie bilang kredensyal

Idinodokumento ng OpenConnect ang hiwalay na yugto ng pagpapatunay sa pamamagitan ng --authenticate, at maaaring ibalik ang resultang materyal gamit ang --cookie-on-stdin. Umiiral ang pares na iyon para sa integration work, at kasing-sensitibo ng password na lumikha nito ang ginagawa nito.

Ilayo ang halaga sa shell history, sa mga log at sa anumang ticket na bubuksan mo. Dapat ding pangalagaan ng handoff script ang verified endpoint information na natanggap ng client kasama ng cookie; kapag nawala iyon, maaaring kumonekta ang susunod na run sa host na hindi mo kailanman pinatunayan, na mas masahol pa sa koneksyong basta nabibigo.

Daana ang listahan bago isara ang terminal

Apat na bagay ang dapat totoo: natapos ang interactive na login sa foreground, itinuturo ng PID file ang prosesong verified mo, naayos ang usapin ng supervisor sa isang direksyon, at may storage plan ang cookie na hindi plaintext file. Kapag totoo ang apat, ligtas ang pag-alis sa terminal at patuloy na tumatakbo ang tunnel.

Kung mabigo ang isa, ayusin ang item na iyon bago hawakan ang iba, dahil hindi ito mababawi ng natitirang pagsusuri. Itabi rin ang foreground transcript ng unang run: sa susunod na bumagsak ang tunnel nang walang babala, ang baseline na iyon ang naghihiwalay ng pagbabago sa panig ng gateway mula sa panig ng client.