Gdje mjesečna kvota podataka pripada po OpenVPN računu

Kvota koja se resetuje kad god se tunel ponovo poveže nije ograničenje, i upravo to dobijete kada se brojač bajtova prikači na VPN server bez mjesta za trajno stanje. Brojač pripada sesiji; kvota pripada osobi ili ugovoru o uređaju. Sve teško u vezi s ovom funkcijom dolazi iz tog nesklada, pa se provjere ispod bave time gdje stanje živi i kojem sloju je dopušteno donositi odluku.

Vežite kvotu za račun, ne za tunel

Počnite imenovanjem subjekta kvote. Jedna osoba može imati tri sertifikata uređaja i nijedan od njih ne bi trebao dobiti nezavisan mjesečni budžet samo zato što se autentifikuju odvojeno. Stabilan identifikator računa koji preživi ponovna povezivanja, nove adrese tunela i prelazak na drugi prolaz jedino je sidro koje kvota može koristiti. Opšte ime sertifikata radi kao taj ključ samo kada vaša politika izdavanja garantuje jedan račun po imenu.

Dodijeljena adresa tunela nikada nije odgovor. Adrese se recikliraju, poolovi se dijele, a isti račun može se pojaviti dvaput na dva prolaza u istoj minuti. Ako se knjiga vodi po adresi, isključivanje i ponovno povezivanje dovoljni su da se rezervoar ponovo napuni.

Bilježite dovoljno po sesiji da aritmetika bude provjerljiva: račun, obračunski period, instancu prolaza, identitet sesije, zadnje uočene brojače i potvrđeni ukupni iznos. Uključite generaciju pokretanja demona u identitet sesije, jer restartovani server ponovo koristi ID-ove klijenata i naivno podudaranje naslijedilo bi prethodnu osnovnu liniju.

Utvrdite jedinicu, smjer i granicu resetovanja

Četiri definicije moraju se pismeno utvrditi prije nego što počne bilo kakvo prikupljanje. Broji li kvota bajtove koje klijent šalje, bajtove koje prima ili zbir oba? Je li gigabajt 10^9 bajtova ili 2^30? U kojem lokalnom satu i u kojoj vremenskoj zoni se period preokreće? I šta tačno mjeri brojač, s obzirom da su uključeni overhead tunela i retransmisije, a veličina datoteke aplikacije i dobavljačev račun nisu?

Nijedan od tih izbora nije pogrešan, ali implementacija i broj koji kupac vidi moraju se slagati. Dvije polovine istog sistema koje se ne slažu oko GiB, ili oko preokreta koji se događa u ponoć UTC umjesto po lokalnom vremenu, proizvode upravo onu vrstu tiketa koja ruši povjerenje u cijelu kvotu.

Pretvorite ukupne bajtove u jednu naplaćenu razliku

Upravljački interfejs prijavljuje periodične BYTECOUNT_CLI linije koje nose ID klijenta i kumulativne ukupne bajtove u svakom smjeru, a naredba bytecount određuje koliko često stižu. Sa stanovišta servera, primljena brojka broji bajtove koje je klijent poslao, a poslana brojka broji bajtove dostavljene njemu. Postavite interval na nešto što knjiga može apsorbovati; vrlo kratak interval kupuje preciznost koju zapravo ne dobijate.

Jedno ograničenje oblikuje cijeli dizajn: upravljački socket prihvata jednu kontrolnu vezu. Izvoznik za nadzor, GUI i vaš kontroler ne mogu svaki otvoriti svoju. Odlučite koji proces posjeduje kanal i pustite ostale da čitaju stanje iz njega, jer ovaj interfejs daje administrativne radnje i ionako ne bi trebao biti izložen izvan hosta.

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

Potvrdite nove osnovne linije i prirast potrošnje zajedno, tako da ponovno puštanje uzorka ne naplati ništa umjesto da naplati dvaput. Brojač koji se kreće unatrag je signal, ne dug: znači da je sesija zamijenjena ili je demon restartovan, a ispravan odgovor je uskladiti identitet sesije umjesto knjižiti negativan iznos.

Put isključivanja zahtijeva istu pažnju. Ako završni događaj nosi ukupne iznose na kraju sesije, naplatite samo razliku od zadnjeg potvrđenog uzorka. Dodavanje punog iznosa nakon što je periodično uzorkovanje već naplaćeno najčešće je dvostruko brojanje u domaćim sistemima kvota. Sesije koje prelaze granicu perioda takođe trebaju pravilo, jer jedan završni iznos ne nosi informaciju o tome kada su bajtovi prešli ponoć.

Neka iscrpljenje odbije prijem, a ne samo ubije tunel

Kada račun dosegne svoj limit, moraju se dogoditi dvije stvari: postojeće sesije završavaju, a nove se odbijaju. Upravljački protokol nudi client-kill po ID-u klijenta, što rješava prvu polovinu ako nabrojite svaku živu sesiju za račun umjesto da ubijete jednu adresu koju ste slučajno primijetili.

Druga polovina je mjesto gdje dizajni kvota propadaju. Samo ubijanje je trka s klijentovom petljom ponovnog povezivanja, koja će se rado vratiti za nekoliko sekundi. Prijem mora konsultovati zajedničku knjigu, a u rasporedu s više prolaza ta provjera ne može biti datoteka po mašini. Svaka instanca koja može prihvatiti prijavu mora vidjeti isto iscrpljeno stanje.

Ponovna povezivanja zasnovana na tokenima zaslužuju vlastiti test. OpenVPN 2.6 može interno validirati sesijski token pomoću auth-gen-token, preskačući vanjski poziv autentifikacije koji je vaš kontroler koristio za provođenje ograničenja. Token koji je još valjan stoga dokazuje identitet, a ne preostalu kvotu, i svaka nova klijentska instanca i dalje mora konsultovati knjigu. Ako umjesto toga omogućite management-client-auth, kontroler postaje autentifikator i nasljeđuje obavezu da sam analizira stanje sesije i odbija istekle ili nevažeće tokene.

Prihvatite prekoračenje koje uzorkovanje stvara

Periodično posmatranje plus isključivanje daje vam kvotu po uzorku s poznatom tolerancijom. Klijent može prekoračiti za otprilike jedan interval izvještavanja plus vrijeme koje kontroleru treba da reaguje, a istovremene sesije na jednom računu umnožavaju taj prozor. Recite to u interfejsu umjesto da reklamirate tačan prekid na zadnjem bajtu koji ne možete isporučiti.

Pravi tvrdi plafon je drugi inženjerski problem: provođenje unutar puta prosljeđivanja, vezano za isti račun kroz sesije. Brže čitanje brojača nije ista stvar i ne preživljava klijenta koji jednostavno otvara više tunela.

Prije uvođenja pokrenite prijemne slučajeve koji lome naivne implementacije: ponovljena povezivanja, dva uređaja odjednom, restarte kontrolera i prolaza, izgubljen događaj isključivanja, preokret usred sesije i pokušaj ponovnog povezivanja tokenom odmah nakon iscrpljenja. Zatim odlučite način kvara za prekide u obračunu. Trajna knjiga štiti potrošnju koju ste zabilježili; ne može oživjeti posmatranja koja nikada nisu stigla, a kupac zaslužuje znati u kojoj je od te dvije situacije.