Дзе павінна быць месячная квота даных на ўліковы запіс OpenVPN

Квота, якая скідваецца пры кожным перападключэнні тунеля, — гэта не ліміт, і менавіта такое вынік, калі лічыльнік байтаў прымацоўваюць да сервера VPN без месца для захавання ўстойлівага стану. Лічыльнік належыць сеансу; квота належыць чалавеку або дагавору на прыладу. Уся складанасць функцыі паходзіць ад гэтай няўзгодненасці, таму праверкі ніжэй тычацца таго, дзе захоўваецца стан і якому ўзроўню дазволена прымаць рашэнне.

Прывяжыце квоту да запісу, а не да тунеля

Пачніце з таго, каб назваць суб'ект квоты. Адзін чалавек можа мець тры сертыфікаты прылад, і ніводзін з іх не павінен атрымліваць незалежны месячны бюджэт проста таму, што яны аўтэнтыфікуюцца асобна. Стабільны ідэнтыфікатар запісу, які перажывае перападключэнні, новыя адрасы тунеля і перанос на другі шлюз, — адзіны якар, які можа выкарыстоўваць квота. Агульнае імя сертыфіката працуе як такі ключ толькі тады, калі ваша палітыка выпуску гарантуе адзін запіс на імя.

Прызначаны адрас тунеля ніколі не з'яўляецца адказам. Адрасы паўторна выкарыстоўваюцца, пулы супольныя, і адзін запіс можа з'явіцца двойчы на двух шлюзах у тую ж хвіліну. Калі рэестр абапіраецца на адрас, адключэння і паўторнага падключэння дастаткова, каб зноў напоўніць бак.

Запісвайце на кожны сеанс дастаткова, каб арыфметыка была правераная: запіс, разліковы перыяд, асобнік шлюза, ідэнтычнасць сеансу, апошнія назіраныя лічыльнікі і зацверджаны агульны аб'ём. Уключыце пакаленне запуску дэмана ў ідэнтычнасць сеансу, бо перазапушчаны сервер паўторна выкарыстоўвае ідэнтыфікатары кліентаў, і наіўнае супастаўленне атрымала б папярэднюю базавую лінію.

Замацуйце адзінку, кірунак і мяжу скіду

Чатыры азначэнні трэба замацаваць пісьмова да пачатку любога збору. Квота лічыць байты, якія кліент адпраўляе, байты, якія ён атрымлівае, ці суму абодвух? Гігабайт — гэта 10^9 байтаў ці 2^30? У якую мясцовую гадзіну і ў якім часавым поясе перамыкаецца перыяд? І што менавіта вымярае лічыльнік, улічваючы, што накладныя выдаткі тунеля і паўторныя перадачы ўключаныя, а памер файла праграмы і рахунак пастаўшчыка — не?

Ніводзін з гэтых выбараў не памылковы, але рэалізацыя і лічба, якую бачыць кліент, павінны супадаць. Дзве паловы адной сістэмы, якія разыходзяцца ў GiB або ў перамыканні, што адбываецца ў поўнач UTC замест мясцовага часу, даюць менавіта такі запыт, які падрывае давер да ўсёй квоты.

Ператварыце сумы байтаў у адну спагнаную розніцу

Інтэрфейс кіравання паведамляе перыядычныя радкі BYTECOUNT_CLI, якія нясуць ідэнтыфікатар кліента і назапашаныя агульныя аб'ёмы байтаў у кожным кірунку, а каманда 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 па ідэнтыфікатары кліента, што закрывае першую палову, пакуль вы пералічваеце кожны жывы сеанс запісу, а не забіваеце адзіны адрас, які выпадкова заўважылі.

Другая палова — там, дзе дызайны квот церпяць няўдачу. Адно забойства — гэта гонка з цыклам перападключэння кліента, які ахвотна вернецца праз секунды. Допуск павінен звяртацца да супольнага рэестра, а пры разгортванні з некалькімі шлюзамі гэтая праверка не можа быць файлам на кожнай машыне. Кожны асобнік, які можа прыняць уваход, павінен бачыць аднолькавы стан вычарпання.

Перападключэнні на аснове токена заслугоўваюць асобнага тэсту. OpenVPN 2.6 можа правяраць токен сеансу ўнутрана з дапамогай auth-gen-token, прапускаючы знешні выклік аўтэнтыфікацыі, які ваш кантролер выкарыстоўваў для забеспячэння ліміту. Таму токен, які ўсё яшчэ сапраўдны, даказвае ідэнтычнасць, а не рэштку квоты, і кожны новы асобнік кліента ўсё роўна павінен звяртацца да рэестра. Калі замест гэтага ўключыць management-client-auth, кантролер становіцца аўтэнтыфікатарам і атрымлівае абавязак сам разбіраць стан сеансу і адхіляць пратэрмінаваныя або несапраўдныя токены.

Прыміце перавышэнне, якое стварае замер

Перыядычнае назіранне плюс адключэнне даюць вам квоту па замеры з вядомай дапушчальнасцю. Кліент можа перавысіць прыблізна на адзін інтэрвал справаздачы плюс час, патрэбны кантролеру для дзеяння, а адначасовыя сеансы на адным запісе памнажаюць гэтае акно. Скажыце пра гэта ў інтэрфейсе замест рэкламы дакладнага адсячэння на апошнім байце, якога вы не можаце забяспечыць.

Сапраўдная жорсткая столь — іншая інжынерная задача: забеспячэнне ўнутры шляху перасылкі, прывязанае да аднаго запісу праз сеансы. Чытанне лічыльнікаў хутчэй — не тое ж самае, і яно не вытрымлівае кліента, які проста адкрывае больш тунеляў.

Перад разгортваннем праганіце прыёмачныя выпадкі, якія ламаюць наіўныя рэалізацыі: паўторныя перападключэнні, дзве прылады адначасова, перазапускі кантролера і шлюза, страчаная падзея адключэння, перамыканне ў сярэдзіне сеансу і спроба перападключэння па токене адразу пасля вычарпання. Затым вызначце рэжым адмовы для перабояў уліку. Устойлівы рэестр абараняе запісанае выкарыстанне; ён не можа вярнуць назіранні, якія ніколі не прыйшлі, і кліент заслугоўвае ведаць, у якой з гэтых двух сітуацый ён знаходзіцца.