Kur pieder ikmēneša datu kvota vienam OpenVPN kontam

Kvota, kas tiek atiestatīta katru reizi, kad tunelis atkārtoti savienojas, nav ierobežojums, un tieši to iegūst, kad baitu skaitītājs tiek pieskrūvēts VPN serverim bez vietas noturīgam stāvoklim. Skaitītājs pieder sesijai; kvota pieder personai vai ierīces līgumam. Visa funkcijas grūtība izriet no šīs neatbilstības, tāpēc tālākās pārbaudes ir par to, kur dzīvo stāvoklis un kurai slānim ir atļauts izlemt.

Piesieniet kvotu kontam, nevis tunelim

Sāciet ar kvotas subjekta nosaukšanu. Vienai personai var būt trīs ierīces sertifikāti, un nevienam no tiem nevajadzētu saņemt neatkarīgu ikmēneša budžetu tikai tāpēc, ka tie autentificējas atsevišķi. Stabils konta identifikators, kas pārdzīvo atkārtotas savienošanas, jaunas tuneļa adreses un pārcelšanos uz otru vārteju, ir vienīgais enkurs, ko kvota var izmantot. Sertifikāta vispārpieņemtais nosaukums darbojas kā šī atslēga tikai tad, ja jūsu izsniegšanas politika garantē vienu kontu uz vārdu.

Piešķirtā tuneļa adrese nekad nav atbilde. Adreses tiek pārstrādātas, pūli tiek koplietoti, un viens un tas pats konts var parādīties divreiz divās vārtejās tajā pašā minūtē. Ja grāmata balstās uz adresi, atvienošanās un atkārtota savienošanās ir pietiekama, lai tvertni atkal piepildītu.

Pierakstiet pietiekami daudz katrai sesijai, lai aritmētika būtu auditējama: kontu, norēķinu periodu, vārtejas instanci, sesijas identitāti, pēdējos novērotos skaitītājus un apstiprināto kopsummu. Iekļaujiet dēmona palaišanas paaudzi sesijas identitātē, jo restartēts serveris atkārtoti izmanto klientu ID, un naiva atbilstība mantotu iepriekšējo bāzes līniju.

Nosakiet vienību, virzienu un atiestatīšanas robežu

Pirms jebkuras vākšanas sākuma rakstiski jāvienojas par četrām definīcijām. Vai kvota skaita baitus, ko klients sūta, ko saņem, vai abu summu? Vai gigabaits ir 10^9 baiti vai 2^30? Kurā vietējā stundā un kurā laika joslā periods pārslēdzas? Un ko tieši mēra skaitītājs, ņemot vērā, ka tuneļa papildu izmaksas un atkārtotas pārraides ir iekļautas, bet lietojumprogrammas faila lielums un pakalpojumu sniedzēja rēķins nav?

Neviena no šīm izvēlēm nav nepareiza, bet ieviešanai un klienta redzamajam skaitlim jāsakrīt. Divas vienas sistēmas puses, kas nepiekrīt par GiB vai par pārslēgšanos UTC pusnaktī, nevis vietējā laikā, rada tieši tādu biļeti, kas grauj uzticēšanos visai kvotai.

Pārvērtiet baitu kopsummas vienā iekasētā starpībā

Pārvaldības saskarne ziņo periodiskas BYTECOUNT_CLI rindas, kas satur klienta ID un uzkrātās baitu kopsummas katrā virzienā, un komanda bytecount nosaka, cik bieži tās ienāk. No servera viedokļa saņemtais skaitlis skaita klienta nosūtītos baitus, bet nosūtītais skaitlis skaita tam piegādātos baitus. Iestatiet intervālu tādu, ko grāmata spēj absorbēt; ļoti īss intervāls nopērk precizitāti, ko jūs faktiski nesaņemat.

Viens ierobežojums veido visu dizainu: pārvaldības ligzda pieņem vienu vadības savienojumu. Uzraudzības eksportētājs, GUI un jūsu kontrolieris nevar katrs atvērt savu. Izlemiet, kurš process pārvalda kanālu, un ļaujiet pārējiem lasīt stāvokli no tā, jo šī saskarne piešķir administratīvas darbības un to jebkurā gadījumā nevajadzētu atklāt ārpus resursdatora.

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

Apstipriniet jaunās bāzes līnijas un lietojuma pieaugumu kopā, lai parauga atkārtošana neiekasētu neko, nevis iekasētu divreiz. Skaitītājs, kas virzās atpakaļ, ir signāls, nevis parāds: tas nozīmē, ka sesija tika aizstāta vai dēmons restartēts, un pareizā atbilde ir saskaņot sesijas identitāti, nevis ieskaitīt negatīvu summu.

Atvienošanas ceļš prasa tādu pašu rūpību. Ja galīgais notikums satur sesijas beigu kopsummas, iekasējiet tikai starpību no pēdējā apstiprinātā parauga. Pilnas kopsummas pievienošana pēc tam, kad periodiskā paraugu ņemšana jau iekasēta, ir visizplatītākā dubultā uzskaite mājās būvētās kvotu sistēmās. Sesijām, kas šķērso perioda robežu, arī vajag noteikumu, jo viena galīgā kopsumma nesatur informāciju par to, kad baiti šķērsoja pusnakti.

Izsmelšana lai atsaka piekļuvi, nevis tikai nogalina tuneli

Kad konts sasniedz savu robežu, jānotiek divām lietām: esošās sesijas beidzas, un jaunās tiek atteiktas. Pārvaldības protokols piedāvā client-kill pēc klienta ID, kas atrisina pirmo pusi, ja jūs uzskaitāt katru dzīvo konta sesiju, nevis nogalināt vienu adresi, ko nejauši pamanījāt.

Otrā puse ir vieta, kur kvotu dizaini cieš neveiksmi. Tikai nogalināšana ir sacensība ar klienta atkārtotas savienošanas cilpu, kas labprāt atgriezīsies pēc dažām sekundēm. Piekļuvei ir jākonsultējas ar koplietoto grāmatu, un izvietojumā ar vairākām vārtejām šī pārbaude nevar būt fails katrā mašīnā. Katrai instancei, kas var pieņemt pieteikšanos, ir jāredz tas pats izsmeltais stāvoklis.

Atkārtotas savienošanas ar žetonu ir pelnījušas savu testu. OpenVPN 2.6 var iekšēji validēt sesijas žetonu ar auth-gen-token, izlaižot ārējo autentifikācijas izsaukumu, ko jūsu kontrolieris izmantoja ierobežojuma izpildei. Tāpēc vēl derīgs žetons pierāda identitāti, nevis atlikušo kvotu, un katrai jaunai klienta instancei joprojām ir jākonsultējas ar grāmatu. Ja tā vietā iespējojat management-client-auth, kontrolieris kļūst par autentifikatoru un manto pienākumu pašam analizēt sesijas stāvokli un atteikt beigušos vai nederīgus žetonus.

Pieņemiet pārsniegumu, ko rada paraugu ņemšana

Periodiska novērošana un atvienošanās dod jums paraugotu kvotu ar zināmu pielaidi. Klients var pārsniegt aptuveni par vienu atskaites intervālu un laiku, kas kontrolierim nepieciešams, lai rīkotos, un viena konta vienlaicīgas sesijas šo logu vairo. Sakiet to saskarnē, nevis reklamējiet precīzu pēdējā baita nogriezni, ko nevarat nodrošināt.

Īsts cietais griesti ir cita inženiertehniska problēma: izpilde pārsūtīšanas ceļā, piesaistīta vienam un tam pašam kontam visās sesijās. Skaitītāju ātrāka lasīšana nav tas pats, un tas neiztur klientu, kas vienkārši atver vairāk tuneļu.

Pirms ieviešanas palaidiet pieņemšanas gadījumus, kas salauž naivas implementācijas: atkārtotas savienošanas, divas ierīces vienlaikus, kontroliera un vārtejas restartēšana, pazaudēts atvienošanās notikums, perioda pārslēgšanās sesijas vidū un mēģinājums atkārtoti savienoties ar žetonu tūlīt pēc izsmelšanas. Pēc tam izlemiet uzskaites pārtraukumu atteices režīmu. Noturīga grāmata aizsargā ierakstīto lietojumu; tā nevar atdzīvināt novērojumus, kas nekad nav ieradušies, un klients ir pelnījis zināt, kurā no šīm divām situācijām viņš atrodas.