Gaano katagal dapat subukan muli ng OpenConnect ang isang putol na VPN?

--reconnect-timeout sinasagot ang isang makitid na tanong: pagkatapos bumagsak ang tunnel, gaano katagal patuloy na sinusubukan ng prosesong kliyente na ito bago sumuko at lumabas. Itinatala ng pahina ng manwal ng OpenConnect ang opsyong iyon na may dokumentadong default na 300 segundo para sa mga pagtatangkang sumusunod sa nawalang link o peer na tumigil sumagot, at ang bilang ay isang takda para sa isang tumatakbong kliyente, hindi patunay na nananatiling maabot ang VPN. Hindi rin ito patakaran sa pagpapanatiling buhay ng proseso, at doon nagsisimula ang karamihan ng kalituhan.

Lumalaki ang kalituhan kapag may pangalawang mekanismong nakaupo sa itaas. Ang supervisor na nag-restart ng kliyente, ang prober na nagpi-ping sa gateway, at ang built-in na window ng muling pagtatangka ay maaaring lahat tumugon sa isang pagkabigo, at pagkatapos ay nagbibigay ang insidente ng tatlong timeline na walang makapagkasundo.

Ano ang aktuwal na nililimitahan ng window ng muling pagkonekta

Isipin na nawala ang access network nang ilang segundo. Nakikita ng kliyente ang pagbagsak ng link, o tumitigil sa pakikinig sa mga sagot ng patay na peer, at nagsisimulang muling itayo ang session habang hinahawakan ang estadong kaya nito. Nagpapatuloy ang mga pagtatangka hanggang tanggapin muli ng gateway o maubos ang window, at ang naubos na window ay nagtatapos sa exit na hindi zero. Ang exit na iyon, hindi ang halaga ng timeout, ang lugar kung saan lumilipat ang pagmamay-ari ng lifecycle sa sinumang nangangasiwa sa proseso.

Walang sinasabi ang window tungkol sa dalas ng pagtakbo ng prober, at hindi nito mapapahaba ang authentication. Kung binawi ng gateway ang session, o kailangan na ngayon ng account ang bagong pangalawang salik, hindi magiging wasto muli ang lumang session dahil sa mas mahabang paghihintay. Nagtatagumpay lamang ang bagong pagtatangka kapag bumalik ang landas, kinikilala pa rin ng gateway ang session, at nananatiling magagamit ang hinihinging kredensyal, kaya basahin ang bilang na ito bilang takda at hindi bilang agwat ng sigla.

Hindi rin pinamamahalaan ng window kung ano ang ginagawa ng mga aplikasyon habang tumatakbo ito. Depende sa platform at sa lalim ng pagkabigo, maaaring muling kumonekta ang kliyente habang nakalagay pa ang mga ruta, o pagkatapos na alisin ang mga ito. Kaya naman ang isang kahilingang inilabas sa gitna ng pagkagambala ay may posibilidad na mag-hang hanggang sa takda sa halip na mabilis na mabigo.

Ang mga restart ng supervisor at ang mga bagong pagtatangka ng kliyente ay dalawang sapin

Hayaan ang tumatakbong kliyente na ubusin ang sarili nitong window, at hayaang tumugon ang tagapamahala ng serbisyo sa exit. Ang kliyente sa harapan sa ilalim ng systemd na may patakaran sa restart ay nagbibigay ng eksaktong paghahating iyon: mga pagtatangka sa loob ng limitadong panahon, pagkatapos ay isang desisyon sa restart. Ang resulta ay isang timeline na maaari pa ring buuin muli sa ibang pagkakataon.

Ang kliyenteng nasa background kasama ang isang malayang poller na naglulunsad ng isa pang kopya kapag wala itong nakikitang interface ang pattern na nagkakamali. Pagkatapos ay nag-aagawan ang dalawang proseso sa parehong node ng device, mga ruta, at mga setting ng resolver. Kung talagang gusto mo ng daemon, ilagay ang opsyong iyon sa command line na aktuwal na ginagamit ng kliyente sa pagsisimula:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

Dalawang detalye sa linyang iyon ang may timbang. Hinihiwalay ng --background ang proseso, kaya ang pid file ang nagiging tanging maaasahang hawakan dito, at ang timeout ay nagagamit lamang habang buhay ang parehong proseso; ang supervisor na pumatay dito ay walang iniiwang badyet para magpatuloy.

Kailangan ng sadyaang pagdiskonekta ang sarili nitong senyales. Ang planadong paghinto at tunay na pagkagambala ay magkamukha sa isang walang muwang na tagamasid, at pareho silang nababasa bilang «hindi konektado». Idereketa ang paghinto sa pamamagitan ng stop operation ng supervisor, o ng marker na naiintindihan ng wrapper, para ang sinadyang paghinto ay hindi magdulot ng restart na walang humiling.

Pigilan ang paghahatid na makipagkarera sa loop ng muling pagtatangka

Ang pagbangon na walang nagbabantay ay nakasalalay sa mga kredensyal na nagre-renew nang walang taong naroon. Ang keyring na nagbubukas lamang sa loob ng interactive na desktop session, o token na laging nangangailangan ng nai-type na code, ay mag-iiwan sa kliyente na stranded sa yugto ng authentication kapag bumalik ang landas. Ayusin ang workflow na iyon bago pahabain ang window, dahil ang mas mahabang window ay nagbibigay lamang ng mas maraming oras sa parehong naharang na prompt upang mabigo.

Hindi dapat luwagan ang verification ng server para bawasan ang mga prompt. Ang pin o trust anchor na nagpapatunay sa gateway ang siyang gumagawa ng awtomatikong muling pagkonekta na ligtas, at ang pag-disable nito para maiwasan ang tanong sa sertipiko ay nagpapalit ng nakikitang pagkagambala sa hindi nakikita. Panatilihin ang beripikadong pagkakakilanlan at ayusin ang prompt sa halip; ang kliyenteng handang kumonekta sa kahit anong gateway ay mas masama kaysa sa humihinto at naghihintay.

Ang pagkakaroon ng interface ay hindi rin senyales ng kalusugan. Maaaring may tunnel device na may patay na session sa likod nito, at maaaring may prosesong naglulunsad na walang tunnel. Wala sa mga obserbasyong iyon ang nananatili sa isang tunay na kahilingan. Dapat magmula ang kalusugan sa kailangan ng gumagamit, gaya ng kahilingang dumadaan sa tunnel patungo sa kilalang panloob na serbisyo.

Ano ang i-verify sa panahon at pagkatapos ng pagkagambala

Patakbuhin ang apat na pangyayari bilang magkakahiwalay na pagsubok: pagkagambalang mas maikli kaysa sa window, pagkagambalang mas mahaba kaysa rito, pagkabigo sa authentication, at sinadyang paghinto. Dapat magtapos ang bawat isa sa ibang, mahuhulaang kalagayan, at ang hangganan ng unang dalawa ay ang buong dahilan ng pagpili ng halaga.

Panatilihing nakaharap palabas ang mga pagsusuri, dahil kakaunti lang ang napatutunayan ng talahanayan ng proseso nang mag-isa. Tingnan kung nananatiling matatag ang pid sa maikling pagputol, pagkatapos ay kumpirmahin na wala na ito at isang beses na pinalitan pagkatapos ng mahaba:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

Sa maikling pagkagambala, kumpirmahin na tunay na nagtangka muli ang kliyente sa halip na lumabas nang maaga, at bumalik ang mga ruta at entry ng resolver na walang doble. Para sa mas mahabang pagkagambala, kumpirmahin ang malinis na exit at eksaktong isang restart pagkatapos. Para sa pagkabigo sa authentication, kumpirmahin na hindi umiikot ang kliyente laban sa gateway na patuloy na tatanggi rito. Magdagdag ng pagsusuring bumabalik ang pid sa isang halaga sa halip na maipon.

Para sa sinadyang paghinto, dapat manatiling hindi maabot ang health URL at manatiling down ang proseso. Pagkatapos ay isara ang loop mula sa panig ng aplikasyon: ang parehong kahilingan ay dapat mabigo habang wala ang tunnel at dapat magtagumpay pagkatapos itong bumalik, mula sa source address na inaasahan ng iyong patakaran. Ang berdeng icon ng tunnel ay hindi patunay, ngunit ang kumpletong kahilingan ay patunay.