Ku i takon kuota mujore e të dhënave për çdo llogari OpenVPN

Një kuotë që rivendoset sa herë që tuneli rilidhet nuk është kufi, dhe pikërisht kjo fitohet kur një numërues bajtësh vidhohet në një server VPN pa një vend për të mbajtur gjendje të qëndrueshme. Numëruesi i përket një sesioni; kuota i përket një personi ose një kontrate pajisjeje. E gjithë vështirësia e veçorisë vjen nga ky mospërputhje, prandaj kontrollet më poshtë kanë të bëjnë me vendin ku jeton gjendja dhe cila shtresë lejohet të vendosë.

Lidhni kuotën me një llogari, jo me një tunel

Filloni duke emërtuar subjektin e kuotës. Një person mund të mbajë tre certifikata pajisjeje dhe asnjëra prej tyre nuk duhet të marrë një buxhet mujor të pavarur vetëm sepse vërtetohen veçmas. Një identifikues i qëndrueshëm llogarie që i mbijeton rilidhjeve, adresave të reja të tunelit dhe zhvendosjes në një portë të dytë është i vetmi ankorim që mund të përdorë një kuotë. Emri i përbashkët i një certifikate funksionon si ai çelës vetëm kur politika juaj e lëshimit garanton një llogari për emër.

Një adresë tuneli e caktuar nuk është kurrë përgjigjja. Adresat riciklohen, pishinat ndahen dhe e njëjta llogari mund të shfaqet dy herë në dy porta në të njëjtën minutë. Nëse libri bazohet në një adresë, shkëputja dhe rilidhja mjaftojnë për të mbushur përsëri rezervuarin.

Regjistroni mjaftueshëm për çdo sesion që aritmetika të jetë e auditueshme: llogarinë, periudhën e faturimit, instancën e portës, identitetin e sesionit, numëruesit e fundit të vëzhguar dhe totalin e angazhuar. Përfshini një gjeneratë nisjeje të demonit në identitetin e sesionit, sepse një server i rinisur ripërdor ID-të e klientëve dhe një përputhje naive do të trashëgonte vijën bazë të mëparshme.

Përcaktoni njësinë, drejtimin dhe kufirin e rivendosjes

Katër përkufizime duhet të përcaktohen me shkrim përpara se të fillojë çdo mbledhje. A numëron kuota bajtët që dërgon klienti, ata që merr, apo shumën e të dyjave? A është një gigabajt 10^9 bajtë apo 2^30? Në cilën orë lokale dhe në cilën zonë kohore kthehet periudha? Dhe çfarë mat saktësisht numëruesi, duke pasur parasysh se kostot e tunelit dhe ritransmetimet përfshihen, ndërsa madhësia e skedarit të aplikacionit dhe fatura e një furnizuesi nuk përfshihen?

Asnjëra nga këto zgjedhje nuk është e gabuar, por zbatimi dhe numri që sheh klienti duhet të pajtohen. Dy gjysma të të njëjtit sistem që nuk bien dakord për GiB, ose për një kthesë që ndodh në mesnatë UTC në vend të orës lokale, prodhojnë pikërisht atë lloj bilete që gërryen besimin në të gjithë kuotën.

Shndërroni totalet e bajtëve në një diferencë të vetme të faturuar

Ndërfaqja e administrimit raporton rreshta periodikë BYTECOUNT_CLI që mbajnë një ID klienti plus totalet kumulative të bajtëve në çdo drejtim, dhe komanda bytecount përcakton sa shpesh vijnë ata. Nga këndvështrimi i serverit, shifra e marrë numëron bajtët që klienti ka dërguar dhe shifra e dërguar numëron bajtët që i janë dorëzuar atij. Vendosni intervalin në diçka që libri mund ta thithë; një interval shumë i shkurtër blen një saktësi që në fakt nuk e merrni.

Një kufizim formëson të gjithë dizajnin: priza e administrimit pranon një lidhje të vetme kontrolli. Një eksportues monitorimi, një GUI dhe kontrolluesi juaj nuk mund të hapin secili të vetin. Vendosni cili proces zotëron kanalin dhe lërini të tjerët të lexojnë gjendjen prej tij, sepse kjo ndërfaqe jep veprime administrative dhe gjithsesi nuk duhet të ekspozohet jashtë hostit.

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

Angazhoni së bashku vijat e reja bazë dhe rritjen e përdorimit, në mënyrë që riprodhimi i një kampioni të mos faturojë asgjë në vend që të faturojë dy herë. Një numërues që lëviz mbrapsht është sinjal, jo borxh: do të thotë që sesioni u zëvendësua ose demoni u rinis, dhe përgjigjja e saktë është të pajtohet identiteti i sesionit në vend që të kreditohet një shumë negative.

Rruga e shkëputjes kërkon të njëjtin kujdes. Nëse një ngjarje përfundimtare mbart totale të fundit të sesionit, faturojeni vetëm diferencën nga kampioni i fundit i angazhuar. Shtimi i totalit të plotë pasi kampionimi periodik është faturuar tashmë është numërimi i dyfishtë më i zakonshëm në sistemet e kuotave të bëra në shtëpi. Edhe sesionet që kalojnë një kufi periudhe kanë nevojë për një rregull, pasi një total i vetëm përfundimtar nuk mbart informacion se kur bajtët kaluan mesnatën.

Shterimi le ta refuzojë hyrjen, jo vetëm ta vrasë tunelin

Kur një llogari arrin kufirin e saj, duhet të ndodhin dy gjëra: sesionet ekzistuese përfundojnë dhe ato të reja refuzohen. Protokolli i administrimit ofron client-kill sipas ID-së së klientit, që zgjidh gjysmën e parë për sa kohë që numëroni çdo sesion të gjallë të llogarisë në vend që të vrisni adresën e vetme që vutë re rastësisht.

Gjysma e dytë është vendi ku dështojnë dizajnet e kuotave. Vrasja e vetme është një garë me ciklin e rilidhjes së klientit, i cili do të kthehet me kënaqësi sekonda më vonë. Hyrja duhet të konsultojë librin e përbashkët, dhe në një vendosje me shumë porta ai kontroll nuk mund të jetë një skedar për çdo makinë. Çdo instancë që mund të pranojë një hyrje duhet të shohë të njëjtën gjendje të shteruar.

Rilidhjet e bazuara në token meritojnë provën e tyre. OpenVPN 2.6 mund të vërtetojë brenda një token sesioni me auth-gen-token, duke kapërcyer thirrjen e vërtetimit të jashtëm që kontrolluesi juaj përdorte për të zbatuar kufirin. Një token ende i vlefshëm provon, pra, identitetin, jo kuotën e mbetur, dhe çdo instancë e re klienti duhet ende të konsultojë librin. Nëse në vend të kësaj aktivizoni management-client-auth, kontrolluesi bëhet vërtetuesi dhe trashëgon detyrimin për të analizuar vetë gjendjen e sesionit dhe për të refuzuar token-t e skaduara ose të pavlefshme.

Pranoni tejkalimin që krijon kampionimi

Vëzhgimi periodik plus shkëputja ju japin një kuotë të kampionuar me një tolerancë të njohur. Një klient mund të tejkalojë për rreth një interval raportimi plus kohën që i duhet kontrolluesit për të vepruar, dhe sesionet e njëkohshme në një llogari e shumëfishojnë atë dritare. Thojeni këtë në ndërfaqe në vend që të reklamoni një prerje të saktë në bajtin e fundit që nuk mund ta ofroni.

Një tavan i vërtetë i fortë është një problem tjetër inxhinierik: zbatimi brenda rrugës së përcjelljes, i lidhur me të njëjtën llogari përgjatë sesioneve. Leximi më i shpejtë i numëruesve nuk është e njëjta gjë dhe nuk i qëndron një klienti që thjesht hap më shumë tunele.

Përpara vënies në punë, ekzekutoni rastet e pranimit që thyejnë zbatimet naive: rilidhje të përsëritura, dy pajisje njëkohësisht, rinisje të kontrolluesit dhe të portës, një ngjarje e humbur shkëputjeje, një kthesë në mes të sesionit dhe një përpjekje për rilidhje me token menjëherë pas shterimit. Pastaj vendosni mënyrën e dështimit për ndërprerjet e kontabilitetit. Një libër i qëndrueshëm mbron përdorimin që keni regjistruar; nuk mund të ringjallë vëzhgime që nuk mbërritën kurrë, dhe klienti meriton të dijë në cilën nga këto dy situata ndodhet.