Saan nararapat ang buwanang data allowance sa bawat OpenVPN account

Ang allowance na nire-reset tuwing muling kumokonekta ang tunnel ay hindi limitasyon, at iyon mismo ang nakukuha kapag ang isang byte counter ay ikinabit sa isang VPN server na walang lugar na paglalagyan ng matibay na estado. Ang counter ay pag-aari ng isang session; ang allowance ay pag-aari ng isang tao o ng kontrata ng device. Lahat ng kahirapan ng feature na ito ay nagmumula sa hindi pagtutugmang iyon, kaya ang mga pagsusuri sa ibaba ay tungkol sa kung saan nakatira ang estado at aling layer ang pinapayagang magdesisyon.

Ikabit ang allowance sa account, hindi sa tunnel

Simulan sa pagbibigay ng pangalan sa paksa ng allowance. Ang isang tao ay maaaring may tatlong sertipiko ng device, at wala sa mga ito ang dapat makakuha ng sariling buwanang badyet dahil lang nagpapatunay sila nang hiwalay. Ang isang matatag na identifier ng account na tumatagal sa mga muling pagkonekta, bagong address ng tunnel at paglipat sa pangalawang gateway ang tanging angkla na magagamit ng allowance. Ang karaniwang pangalan ng sertipiko ay gumaganap bilang susi na iyon lamang kapag ginagarantiyahan ng iyong patakaran sa pag-isyu ang isang account sa bawat pangalan.

Ang itinalagang address ng tunnel ay hindi kailanman ang sagot. Ang mga address ay nire-recycle, ang mga pool ay ibinabahagi, at ang parehong account ay maaaring lumitaw nang dalawang beses sa dalawang gateway sa parehong minuto. Kung ang ledger ay naka-base sa isang address, sapat na ang pagdiskonekta at muling pagkonekta upang muling mapuno ang tangke.

Itala ang sapat sa bawat session upang ang aritmetika ay ma-audit: ang account, ang panahon ng pagsingil, ang instance ng gateway, ang pagkakakilanlan ng session, ang huling naobserbahang counters at ang nakatalagang kabuuan. Isama ang henerasyon ng pagsisimula ng daemon sa pagkakakilanlan ng session, dahil ang server na nag-restart ay gumagamit muli ng mga client ID at ang isang simpleng pagtutugma ay mamanahin ang dating baseline.

Itakda ang yunit, direksyon at hangganan ng pag-reset

Apat na depinisyon ang dapat itakda sa sulat bago magsimula ang anumang koleksyon. Binibilang ba ng allowance ang mga byte na ipinapadala ng client, ang mga natatanggap nito, o ang kabuuan ng dalawa? Ang isang gigabyte ba ay 10^9 bytes o 2^30? Sa anong lokal na oras at sa anong time zone umiikot ang panahon? At ano ang eksaktong sinusukat ng counter, dahil kasama ang overhead ng tunnel at mga retransmission habang ang laki ng file ng aplikasyon at ang invoice ng provider ay hindi?

Wala sa mga pagpipiliang iyon ang mali, ngunit ang implementasyon at ang numerong nakikita ng customer ay dapat magtugma. Ang dalawang kalahati ng parehong sistema na hindi nagkakasundo tungkol sa GiB, o tungkol sa pag-ikot na nangyayari sa hatinggabi UTC sa halip na lokal na oras, ay gumagawa ng eksaktong uri ng ticket na nagpapahina ng tiwala sa buong allowance.

Gawing isang sisingiling pagitan ang kabuuan ng bytes

Ang interface ng pamamahala ay nag-uulat ng pana-panahong mga linya ng BYTECOUNT_CLI na may dalang client ID at pinagsama-samang kabuuan ng bytes sa bawat direksyon, at ang command na bytecount ang nagtatakda kung gaano kadalas dumarating ang mga iyon. Mula sa pananaw ng server, binibilang ng natanggap na numero ang mga byte na ipinadala ng client at binibilang ng ipinadalang numero ang mga byte na naihatid dito. Itakda ang agwat sa isang bagay na kayang tunawin ng ledger; ang napakaikling agwat ay bumibili ng katumpakan na hindi mo naman nakukuha.

Isang hadlang ang humuhubog sa buong disenyo: ang socket ng pamamahala ay tumatanggap ng isang solong koneksyon sa kontrol. Ang isang exporter ng monitoring, isang GUI at ang iyong controller ay hindi maaaring bawat isa ay magbukas ng sarili nito. Magpasya kung aling proseso ang may-ari ng channel at hayaan ang iba na magbasa ng estado mula rito, dahil ang interface na ito ay nagbibigay ng administratibong aksyon at sa anumang paraan ay hindi dapat ilantad sa labas ng host.

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

Kumpirmahin nang sabay ang mga bagong baseline at ang pagtaas ng paggamit, upang ang muling pag-play ng isang sample ay walang sisingilin sa halip na maningil nang dalawang beses. Ang counter na pabalik ang galaw ay senyales, hindi utang: nangangahulugan ito na ang session ay pinalitan o ang daemon ay nag-restart, at ang tamang tugon ay upang itugma ang pagkakakilanlan ng session sa halip na mag-kredito ng negatibong halaga.

Ang landas ng pagdiskonekta ay nangangailangan ng parehong pag-iingat. Kung ang huling kaganapan ay may dalang kabuuan sa pagtatapos ng session, singilin lamang ang pagkakaiba mula sa huling nakumpirmang sample. Ang pagdaragdag ng buong kabuuan pagkatapos na masingil na ang pana-panahong sampling ay ang pinakakaraniwang dobleng pagbilang sa mga sistemang gawang-bahay ng allowance. Ang mga session na tumatawid sa hangganan ng panahon ay nangangailangan din ng panuntunan, dahil ang isang huling kabuuan ay walang dalang impormasyon tungkol sa kung kailan tumawid ang mga byte sa hatinggabi.

Gawing pagtanggi sa pagpasok ang pagkaubos, hindi lang pagpatay sa tunnel

Kapag naabot ng isang account ang limitasyon nito, dalawang bagay ang dapat mangyari: magtatapos ang mga umiiral na session, at tatanggihan ang mga bago. Ang protocol ng pamamahala ay nagbibigay ng client-kill ayon sa client ID, na humahawak sa unang kalahati hangga't inililista mo ang bawat buhay na session ng account sa halip na patayin ang nag-iisang address na napansin mo.

Ang ikalawang kalahati ang lugar kung saan nabigo ang mga disenyo ng allowance. Ang pagpatay lamang ay isang karera laban sa loop ng muling pagkonekta ng client, na masayang babalik pagkalipas ng ilang segundo. Dapat kumonsulta ang pagpasok sa ibinahaging ledger, at sa deployment na may maraming gateway ang pagsusuring iyon ay hindi maaaring maging file sa bawat makina. Bawat instance na maaaring tumanggap ng login ay dapat makita ang parehong naubos na estado.

Ang mga muling pagkonektang batay sa token ay karapat-dapat sa sariling pagsubok. Maaaring i-validate ng OpenVPN 2.6 ang token ng session sa loob gamit ang auth-gen-token, na nilalaktawan ang panlabas na tawag sa authentication na ginagamit ng iyong controller upang ipatupad ang takip. Ang token na may bisa pa ay nagpapatunay ng pagkakakilanlan, hindi ng natitirang allowance, at ang bawat bagong instance ng client ay dapat pa ring kumonsulta sa ledger. Kung i-enable mo sa halip ang management-client-auth, ang controller ang magiging authenticator at mamanahin ang obligasyong suriin mismo ang estado ng session at tanggihan ang mga token na nag-expire o di-wasto.

Tanggapin ang paglampas na nililikha ng sampling

Ang pana-panahong pagmamasid at pagdiskonekta ay nagbibigay sa iyo ng sample na allowance na may alam na tolerance. Maaaring lumampas ang client nang humigit-kumulang isang agwat ng pag-uulat at ang oras na kailangan ng controller upang kumilos, at ang sabay-sabay na session sa isang account ay nagpaparami ng window na iyon. Sabihin ito sa interface sa halip na mag-advertise ng eksaktong pagputol sa huling byte na hindi mo maibigay.

Ang tunay na matigas na kisame ay ibang problema sa inhenyeriya: pagpapatupad sa loob ng landas ng pagpapasa, nakatali sa parehong account sa mga session. Ang mas mabilis na pagbasa ng counters ay hindi pareho, at hindi ito tumatagal laban sa isang client na basta nagbubukas ng mas maraming tunnel.

Bago ang pag-deploy, patakbuhin ang mga kaso ng pagtanggap na sumisira sa simpleng implementasyon: paulit-ulit na muling pagkonekta, dalawang device nang sabay, pag-restart ng controller at gateway, nawawalang kaganapan ng pagdiskonekta, pag-ikot ng panahon sa gitna ng session, at pagtatangkang muling kumonekta gamit ang token kaagad pagkatapos ng pagkaubos. Pagkatapos ay magpasya sa paraan ng pagkabigo para sa mga pagkaantala sa accounting. Pinoprotektahan ng matibay na ledger ang paggamit na naitala mo; hindi nito maibabalik ang mga obserbasyong hindi kailanman dumating, at karapat-dapat malaman ng customer kung alin sa dalawang sitwasyong iyon ang kanyang kinalalagyan.