Mga kaganapan sa hook ng OpenVPN: bakit hindi susi ang pangalan at timestamp

Dumating ang talaan ng pagdiskonekta pagkatapos nang magsimula ang pangalawang koneksyon sa ilalim ng parehong pangalan, at isinasara ng handler na nag-a-update ng pinakabagong hilera para sa user na iyon ang maling session. Ang pagkakamali ay hindi ang paghahambing ng timestamp. Ito ang pagpapalagay na ang pangalan at isang buong segundo ay tumutukoy sa isang session. Inilalarawan ng mga kaganapan sa hook ang mga koneksyon, at ang isang koneksyon ay nangangailangan ng susi na pag-aari lamang nito.

Magsimula sa kung ano talaga ang ibig sabihin ng mga variable ng pagdiskonekta. Sa gayon lamang may saysay ang pagpili ng identifier.

Ano talaga ang dinadala ng hook ng pagdiskonekta

Sa Community OpenVPN 2.6, tinutukoy ng sanggunian ng hook time_unix ang sandali nang kumonekta ang kliyente; itinakda ito bago tumakbo ang hook ng pagkonekta at hindi muling tinutukoy kapag na-trigger ang hook ng pagdiskonekta sa kalaunan. time_duration ay nagbibigay ng haba ng session na iyon sa mga segundo, kaya ang wakas ay humigit-kumulang oras ng pagkonekta dagdag ang tagal. Parehong buong segundo ang dalawa, at wala sa kanila ang sandali nang pinroseso ng iyong database ang kaganapan. Ang paghiwalay ng tatlong oras na iyon ang dahilan kung bakit nananatili ang ugnayan, sa halip na mukhang tama lamang habang nagtetest.

Ang aritmetikang ito ay karapat-dapat isulat, dahil ito ang tanging oras ng pagtatapos na inaalok ng hook mismo. Ang pagkaantala ng pagproseso at mga pagkakaiba ng orasan sa pagitan ng mga host ay nananatili pa ring labas nito.

Bakit hindi natatangi ang halatang pares

Ang pagsasama ng pangalan sa oras ng pagkonekta ay nagpapaliit ng paghahanap at hindi pa rin natutukoy ang isang session. Maaaring muling kumonekta ang kliyente sa loob ng parehong segundo, kaya maaaring magbahagi ang dalawang session ng parehong halaga. Dalawang instance ng daemon, o pagpapalit ng server na nagpapanatili ng parehong configuration, ay maaaring gumawa ng pares na iyon mula sa magkaibang proseso. Ang mga address ng tunnel ay nire-recycle sa parehong dahilan, na ginagawa silang katangian ng isang session, hindi identifier nito.

Tahimik ang paraan ng pagpalya. Ang huling pagdiskonekta para sa unang session ay tumutugma sa pinakabagong hilera at tinatapos ang isang alokasyon na ginagamit pa ng pangalawang session, kaya nakakaranas ang user ng random na pagkawala ng access na hindi niya ginawa. Ang bilang ng hilerang mukhang tama pagkatapos ay nagpapahirap makita ang problema.

Saan nagmumula ang matatag na pagkakakilanlan

Ang interface ng pamamahala ay nagbibigay sa bawat kliyente ng identifier ng instance ng kliyente, at ang identifier na iyon ay limitado sa instance ng daemon na naglabas nito. Ang magagamit na panlabas na susi ay pinagsasama ang matatag na identifier ng server, isang epoch na nagbabago kapag nagsimula ang daemon, at ang client ID na iyon. Mahalaga ang epoch dahil nagre-restart ang mga identifier kasama ng proseso, at ang hubad na process ID ay maaaring muling gamitin sa kalaunan ng isang bagay na walang kaugnayan.

Ang mga environment variable na itinakda sa loob ng child connect script ay hindi naglalakbay patungo sa susunod na disconnect script ng parent daemon, dahil tumatakbo ang mga script na iyon bilang hiwalay na proseso na may sariling environment. Kaya ang pagbuo ng UUID sa oras ng pagkonekta ay kalahating solusyon. Kailangang mapangalanan ng panig ng pagdiskonekta ang parehong UUID, na nangangahulugang kailangang manirahan ang pagkakakilanlan sa lugar na maaabot ng parehong kaganapan.

Gawing may kondisyon at idempotent ang pagretiro

Magretiro ayon sa may-ari ng session, hindi ayon sa user. Ang handler na nagtatanggal ng anumang alokasyon na kasalukuyang pag-aari ng isang pangalan ay tiyak na magtatanggal ng mali sa huli, at ang tanging depensa ay tiyakin na ang talaang inaalis ay ang talaang inilalarawan ng kaganapang ito.

Ang interface ng pamamahala ay tumatanggap ng isang konektadong management client sa isang pagkakataon, kaya makipag-integrate sa kung sino ang may-ari na nito sa halip na mag-attach ng pangalawang tagamasid na nakikipag-agawan sa parehong socket.

Pangasiwaan ang mga paulit-ulit na kaganapan nang hindi binabago ang resulta nang dalawang beses, at itago ang mga hindi kapares na kaganapan para sa pagkakasundo sa halip na itapon. Ang callback ng pagdiskonekta ay may dokumentadong mga kondisyon ng lifecycle at maaaring hindi kailanman dumating pagkatapos ng pag-crash o hard stop, kaya kailangan ng disenyo ng paraan upang kumatawan sa isang session na nawawala ang kaganapan ng pagtatapos.

Subukan ang mga kakaibang kaso nang sinasadya: dalawang muling pagkonekta sa loob ng isang segundo, dalawang instance ng daemon, isang koneksyon na nabigo ang pagproseso, at isang pag-restart ng daemon sa gitna ng session. Ang susi na nakakaligtas sa lahat ng apat ay isang susing karapat-dapat pagkatiwalaan.