Каде припаѓа месечната квота за податоци по сметка на OpenVPN

Квота што се ресетира секој пат кога тунелот повторно се поврзува не е ограничување, и токму тоа се добива кога бројач на бајти се зашрафува на VPN сервер без место за трајна состојба. Бројачот ѝ припаѓа на сесија; квотата му припаѓа на лице или на договор за уред. Целата тешкотија на функцијата произлегува од тоа несовпаѓање, затоа проверките подолу се однесуваат на тоа каде живее состојбата и на кој слој му е дозволено да одлучува.

Прицврстете ја квотата за сметка, а не за тунел

Започнете со именување на субјектот на квотата. Едно лице може да има три сертификати за уреди, и ниту еден од нив не треба да добие независен месечен буџет само затоа што се автентицираат одделно. Стабилен идентификатор на сметката што ги преживува повторните поврзувања, новите адреси на тунелот и преместувањето на втор портал е единственото сидро што квотата може да го користи. Заедничкото име на сертификатот функционира како тој клуч само кога вашата политика за издавање гарантира една сметка по име.

Доделената адреса на тунелот никогаш не е одговорот. Адресите се рециклираат, базените се делат, и истата сметка може да се појави двапати на два портала во истата минута. Ако книгата се води по адреса, исклучувањето и повторното поврзување се доволни за повторно полнење на резервоарот.

Запишете доволно по сесија за пресметката да биде проверлива: сметката, наплатниот период, примерокот на порталот, идентитетот на сесијата, последните набљудувани бројачи и потврдениот вкупен износ. Вклучете генерација на стартување на демонот во идентитетот на сесијата, бидејќи рестартиран сервер повторно користи клиентски ID-а и наивно совпаѓање би ја наследило претходната основна линија.

Утврдете ја единицата, насоката и границата на ресетирање

Четири дефиниции мора писмено да се утврдат пред да започне какво било собирање. Дали квотата ги брои бајтите што клиентот ги испраќа, оние што ги прима, или збирот од двете? Дали гигабајтот е 10^9 бајти или 2^30? Во кој локален час и во која временска зона се превртува периодот? И што точно мери бројачот, имајќи предвид дека трошоците на тунелот и повторните преноси се вклучени, а големината на датотеката на апликацијата и фактурата на давателот не се?

Ниту еден од тие избори не е погрешен, но имплементацијата и бројот што клиентот го гледа мора да се согласат. Две половини од истиот систем што не се согласуваат за GiB, или за превртување што се случува на полноќ UTC наместо по локално време, го создаваат токму тој вид тикет што го поткопува довербата во целата квота.

Претворете ги вкупните бајти во една наплатена разлика

Интерфејсот за управување пријавува периодични линии BYTECOUNT_CLI што носат клиентски ID плус кумулативни вкупни бајти во секоја насока, а командата bytecount одредува колку често пристигнуваат. Од гледна точка на серверот, примената бројка ги брои бајтите што клиентот ги испратил, а испратената бројка ги брои бајтите доставени до него. Поставете го интервалот на нешто што книгата може да го апсорбира; многу краток интервал купува прецизност што всушност не ја добивате.

Едно ограничување го обликува целиот дизајн: сокетот за управување прифаќа една контролна врска. Извозник за надзор, GUI и вашиот контролер не можат секој да отвори своја. Одлучете кој процес го поседува каналот и оставете другите да читаат состојба од него, бидејќи овој интерфејс дава административни дејства и онака не треба да се изложува надвор од домаќинот.

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

Потврдете ги новите основни линии и порастот на употреба заедно, така што повторното пуштање на примерок нема да наплати ништо наместо да наплати двапати. Бројач што се движи наназад е сигнал, не долг: значи дека сесијата е заменета или демонот е рестартиран, и точниот одговор е да се усогласи идентитетот на сесијата наместо да се кредитира негативен износ.

Патот на исклучувањето бара исто внимание. Ако завршен настан носи вкупни износи за крајот на сесијата, наплатете само разликата од последниот потврден примерок. Додавањето на целосниот вкупен износ откако периодичното земање примероци веќе е наплатено е најчестото двојно броење во домашно изградени системи за квоти. Сесиите што преминуваат преку граница на период, исто така, бараат правило, бидејќи еден завршен вкупен износ не носи информација кога бајтите преминале полноќ.

Исцрпеноста нека го одбие пристапот, а не само да го убие тунелот

Кога сметката ќе го достигне својот лимит, мора да се случат две работи: постојните сесии завршуваат, а новите се одбиваат. Протоколот за управување нуди client-kill по клиентски ID, што ја решава првата половина ако ја наброите секоја жива сесија на сметката наместо да ја убиете единствената адреса што случајно ја забележавте.

Втората половина е местото каде што дизајните на квоти пропаѓаат. Самото убивање е трка со циклусот за повторно поврзување на клиентот, кој со задоволство ќе се врати по неколку секунди. Пристапот мора да се консултира со заедничката книга, а при распоредување со повеќе портали таа проверка не може да биде датотека по машина. Секој примерок што може да прифати најава мора да ја види истата исцрпена состојба.

Повторните поврзувања засновани на токен заслужуваат свој тест. OpenVPN 2.6 може внатрешно да валидира токен за сесија со auth-gen-token, прескокнувајќи го надворешниот повик за автентикација што вашиот контролер го користеше за спроведување на горната граница. Затоа токенот што е сѐ уште валиден докажува идентитет, не преостаната квота, и секој нов клиентски примерок мора сѐ уште да се консултира со книгата. Ако наместо тоа вклучите management-client-auth, контролерот станува автентикатор и ја наследува обврската сам да ја анализира состојбата на сесијата и да одбива истечени или невалидни токени.

Прифатете го пречекорувањето што го создава земањето примероци

Периодичното набљудување плус исклучувањето ви даваат квота по примероци со позната толеранција. Клиентот може да пречекори за приближно еден интервал на известување плус времето што му е потребно на контролерот да дејствува, а паралелните сесии на една сметка го множат тој прозорец. Кажете го тоа во интерфејсот наместо да рекламирате точно отсекување на последниот бајт што не можете да го обезбедите.

Вистински тврд таван е друг инженерски проблем: спроведување внатре во патот за препраќање, врзано за истата сметка низ сесиите. Побрзото читање на бројачите не е истото, и не издржува клиент што едноставно отвора повеќе тунели.

Пред распоредување, извршете ги случаите за прифаќање што ги кршат наивните имплементации: повторени поврзувања, два уреда истовремено, рестартирања на контролерот и порталот, изгубен настан за исклучување, превртување на периодот на средина на сесија и обид за повторно поврзување со токен веднаш по исцрпеноста. Потоа одлучете го режимот на дефект за прекини во сметководството. Трајната книга ја штити употребата што ја запишавте; таа не може да ги оживее набљудувањата што никогаш не пристигнале, а клиентот заслужува да знае во која од тие две ситуации е.