Bakit tumutunog ang 23-oras na paalala ng VPN para sa maling sesyon
Ang 23-oras na abiso ay dapat sumunod sa isang sesyon, hindi sa account. Ikabit ang timer sa koneksyong nagsimula at ituring ang pagtulog at muling pagkonekta bilang magkahiwalay na kaso.
Lumabas ang abiso dalawampung minuto pagkatapos kumonekta. Ang counter sa ilalim nito ay tumatakbo mula pa noong nakaraang umaga, o mula noong huling nagpatunay ang account, at walang sinabi sa alerto kung alin. Iyon ang sintomas: isang paalala na nakatali sa ibang bagay, hindi sa koneksyong nasa harap mo.
Ang solusyon ay hindi isang mas mahusay na alerto. Ito ay ang pagpapasya kung aling orasan ang tinutukoy ng pangangailangan, at pagkatapos ay ikabit ang timer sa isang bagay na umiiral sa orasang iyon.
Ano ang tumunog, at ano ang binibilang nito
Tatlong malamang na pinagmulan ang gumagawa ng parehong mensahe. Ang panuntunan ng kalendaryo ay tumatakbo sa takdang lokal na oras at wala itong alam sa mga tunnel. Ang counter sa client ay naiipon habang may koneksyong buhay at nakakalampas sa muling pagkonekta. Ang patakaran ng gateway ay nagpapawalang-bisa ng sesyon sa panig ng server at nagpapadala muna ng babala.
Tanging ang huling dalawa ang tungkol sa sesyon, at kahit sila ay hindi nagkakasundo. Sinusukat ng counter ng client ang naobserbahan ng lokal na proseso; sinusukat ng gateway ang pinatunayan at inaccount nito. Ang pagtulog, pagbabago ng network o muling pagpapatakbo ng tagamasid ay maaaring maghiwalay sa kanila nang ilang oras, at iyon ang dahilan kung bakit naglalayo ang alerto at ang sapilitang pag-expire.
Tatlong orasan sa likod ng isang pangangailangan
Magsimula sa pagsulat ng pangungusap na talagang gusto mo. Ang pagbababala bago tapusin ng gateway ang koneksyong ito ay hindi kaparehong pangangailangan sa pagpapaalala pagkatapos ng isang araw na konektadong oras. Hindi rin ito kapareho ng pag-uulat na ang sesyong ito ay buhay na nang 23 oras. Ang bawat bersyon ay nagpapangalan ng ibang pangyayari, at ibang bahagi ang dapat sumagot dito.
Pagkatapos ay tingnan kung may data. Ang lokal na timestamp ng simula ay nagbibigay ng edad ng sesyon nang walang pag-asa sa server. Ang patakaran ng gateway ay nagbibigay ng natitirang buhay, ngunit kung ipinapakita ito ng gateway. Ang ulat ng paggamit ay nagbibigay ng tagal pagkatapos ng pangyayari, at hindi nito maaaring patakbuhin ang abisong pauna.
Ikabit ang timer sa sesyon, hindi sa account
Piliin muna ang bagay. Ang isang account ay maaaring maghawak ng maraming device at maraming sabay na sesyon, kaya ang paalalang nakasusi sa username ay hindi masasabi kung aling koneksyon ang umabot sa edad. Ikabit ito sa profile kasama ang activation na iyon, at kanselahin ang abisong naghihintay kapag natapos ang activation.
| Evidence you can read | What it establishes | Where it misleads |
|---|---|---|
| Connection state changes to active | A session started now | Does not carry the gateway's own session identifier |
| Duration reported at disconnect | Total service time for that session | Arrives too late for any advance notice |
| Interim usage update | Time accounted up to that update | Staleness equals the update interval |
| Local timestamp taken at activation | Age of your observation | Resets whenever the observer restarts |
Ang talahanayang iyon ay kontrata para sa iyong sariling notifier, hindi paglalarawan ng callback API ng kahit anong client. Anuman ang idinodokumento ng naka-install na produkto tungkol sa estado ng koneksyon ang pinagmulang dapat kabitan; kung saan naglalabas lamang ito ng mga kaganapan ng pagpapatunay, sabihin ito nang malakas at tanggapin ang mas magaspang na pag-uugali sa halip na maghinuha ng sesyon.
Subukan ito gamit ang maikling hangganan
Huwag kailanman i-debug ang isang araw na timer gamit ang isang araw na paghihintay. Magdagdag ng maikokonpigurang hangganan, itakda ito sa tatlumpung segundo, at patakbuhin ang apat na transition sa pagkakasunod-sunod: kumonekta, maghintay, idiskonekta, muling kumonekta. Ang bawat transition ay dapat gumawa ng eksaktong isang pagbabago ng estado, at ang muling pagkonekta ay dapat mag-iskedyul ng bagong deadline sa halip na mamana ang luma.
# current connection state and profile identity
nmcli -f GENERAL.STATE,GENERAL.CONNECTION connection show work
# the notifier unit you wrote: does it restart the deadline or resume it?
journalctl --user -u vpn-timer.service --since "-5 min" -o catTingnan ang mga timestamp, hindi ang pananalita. Ang abisong dumarating kasama ang oras ng simula ng nakaraang sesyon ay nagkabit ng maling bagay, at ang abisong dumarating nang dalawang beses para sa isang deadline ay nangangahulugang hindi kailanman na-save ang flag ng naipadala.
Pagtulog, muling pagkonekta at nawalang paghahatid
Sinira ng pagtulog ang dalawang simplistic na disenyo. Humihinto ang monotonic countdown habang natutulog ang makina, patuloy na gumagalaw ang deadline ayon sa orasan sa dingding, at ang timer na pumutok habang natutulog ay naihatid nang huli o hindi naihatid. Magpasya kung anong pag-uugali ang kailangan ng iyong pangangailangan, pagkatapos patulugin ang makina lampas sa hangganan at kumpirmahin.
Ang paghahatid ay nararapat sa parehong pag-iingat. Kung hindi maipakita ang abiso, ilagay ito sa pila, at suriing muli kung umiiral pa ang target na sesyon bago ito tuluyang ipakita; kung hindi, ang gumagamit ay binabalaan tungkol sa koneksyong natapos na. Ang sapilitang pagdiskonekta at pag-renew ng kredensyal ay nananatili sa labas ng daang ito, dahil ang paalalang tahimik na nagbabago ng kapalaran ng koneksyon ay isang desisyong patakaran na nakasuot ng damit ng abiso.