Где припада месечна квота података по налогу 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, контролер постаје аутентификатор и наслеђује обавезу да сам анализира стање сесије и одбија истекле или неважеће токене.

Прихватите прекорачење које узимање узорака ствара

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

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

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