Туннель әр қайта қосылған сайын қалпына келтірілетін квота шектеу емес, және тұрақты күйді сақтайтын орынсыз VPN серверіне байт санағышты бұрап бекіткенде дәл осы шығады. Санағыш сеансқа тиесілі; квота адамға немесе құрылғы шартына тиесілі. Бұл мүмкіндіктің барлық қиындығы осы сәйкессіздіктен туындайды, сондықтан төмендегі тексерулер күйдің қайда тұратынына және қай қабатқа шешім қабылдауға рұқсат етілгеніне қатысты.

Квотаны туннельге емес, тіркелгіге бекітіңіз

Квотаның субъектісін атаудан бастаңыз. Бір адамның үш құрылғы сертификаты болуы мүмкін, және олардың ешқайсысы бөлек аутентификацияланады деп өз алдына айлық бюджет алуға тиіс емес. Қайта қосылуларға, жаңа туннель мекенжайларына және екінші шлюзге көшуге төтеп беретін тұрақты тіркелгі идентификаторы — квота пайдалана алатын жалғыз зәкір. Сертификаттың ортақ атауы осы кілт ретінде тек сіздің беру саясатыңыз әр атқа бір тіркелгі кепілдік бергенде ғана жарайды.

Тағайындалған туннель мекенжайы ешқашан жауап емес. Мекенжайлар қайта өңделеді, пулдар ортақ, және бір тіркелгі сол минутта екі шлюзде екі рет көрінуі мүмкін. Егер кітап мекенжайға негізделсе, резервуарды қайта толтыру үшін ажыратып қайта қосылу жеткілікті.

Есептеу тексерілетін болуы үшін сеанс бойынша жеткілікті жазыңыз: тіркелгі, есеп айырысу кезеңі, шлюз данасы, сеанс идентификациясы, соңғы байқалған санағыштар және бекітілген жалпы сома. Сеанс идентификациясына демонның іске қосылу ұрпағын қосыңыз, өйткені қайта іске қосылған сервер клиент ID-лерін қайта пайдаланады және аңғал сәйкестендіру алдыңғы базалық сызықты мұра етер еді.

Бірлікті, бағытты және қалпына келтіру шегін бекітіңіз

Кез келген жинау басталмас бұрын төрт анықтама жазбаша бекітілуі керек. Квота клиент жіберетін байттарды, ол қабылдайтын байттарды немесе екеуінің қосындысын санай ма? Гигабайт 10^9 байт па әлде 2^30 ба? Кезең қай жергілікті сағатта және қай уақыт белдеуінде ауысады? Және санағыш дәл нені өлшейді, туннельдің үстеме шығыны мен қайта жіберулер кіреді, ал қолданба файлының өлшемі мен провайдердің шоты кірмейді?

Бұл таңдаулардың ешқайсысы қате емес, бірақ іске асыру мен клиент көретін сан келісуі керек. Бір жүйенің екі жартысы GiB немесе жергілікті уақыттың орнына UTC түн ортасында болатын ауысу туралы келіспесе, бүкіл квотаға сенімді әлсірететін дәл сол тектес билет шығады.

Байт сомаларын бір алынатын айырмаға айналдырыңыз

Басқару интерфейсі клиент ID-сін және әр бағыттағы жинақталған байт сомаларын тасымалдайтын мерзімді 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

Жаңа базалық сызықтар мен пайдалану өсімін бірге бекітіңіз, сонда үлгіні қайта ойнату екі рет алудың орнына ештеңе алмайды. Артқа жылжыған санағыш — сигнал, қарыз емес: бұл сеанстың ауыстырылғанын немесе демонның қайта іске қосылғанын білдіреді, және дұрыс жауап теріс соманы кредиттеу емес, сеанс идентификациясын сәйкестендіру.

Ажырату жолы да сол қамқорлықты қажет етеді. Егер қорытынды оқиға сеанс соңының сомаларын тасымалдаса, тек соңғы бекітілген үлгіден айырманы алыңыз. Мерзімді іріктеу алынып болғаннан кейін толық соманы қосу — үйде жасалған квота жүйелеріндегі ең көп тараған қос есептеу. Кезең шекарасын кесіп өтетін сеанстарға да ереже керек, өйткені бір қорытынды сома байттардың түн ортасынан қашан өткені туралы ақпарат тасымалдамайды.

Таусылу кіруді қабылдамасын, туннельді ғана өлтірмесін

Тіркелгі өз шегіне жеткенде екі нәрсе болуы керек: бар сеанстар аяқталады және жаңалары қабылданбайды. Басқару протоколы клиент ID-сі бойынша client-kill ұсынады, бұл бірінші жартысын шешеді, егер тіркелгінің әр тірі сеансын санап шықсаңыз, кездейсоқ байқаған бір мекенжайды өлтірудің орнына.

Екінші жарты — квота дизайндары сәтсіздікке ұшырайтын жер. Тек өлтіру клиенттің қайта қосылу циклімен жарыс, ол бірнеше секундтан кейін қуана оралады. Кіру ортақ кітаппен кеңесуі керек, ал көп шлюзді орналастыруда бұл тексеру машинаға арналған файл бола алмайды. Кіруді қабылдай алатын әр дана бірдей таусылған күйді көруі керек.

Токенге негізделген қайта қосылулар өз сынағына лайық. OpenVPN 2.6 auth-gen-token арқылы сеанс токенін іштей тексере алады, контроллеріңіз шекті орындау үшін пайдаланған сыртқы аутентификация шақыруын өткізіп жібереді. Сондықтан әлі жарамды токен идентификацияны дәлелдейді, қалған квотаны емес, және әр жаңа клиент данасы әлі де кітаппен кеңесуі керек. Оның орнына management-client-auth қоссаңыз, контроллер аутентификаторға айналады және сеанс күйін талдап, мерзімі өткен немесе жарамсыз токендерді өзі қабылдамау міндетін мұра етеді.

Іріктеу жасайтын асып кетуді қабылдаңыз

Мерзімді бақылау және ажырату сізге белгілі төзімділікпен іріктелген квота береді. Клиент шамамен бір есеп беру интервалы және контроллерге әрекет етуге кететін уақытқа асып кетуі мүмкін, ал бір тіркелгідегі қатар сеанстар бұл терезені бірнеше есе арттырады. Соңғы байтта дәл кесуге уәде бере алмайтыныңызды интерфейсте айтыңыз.

Шынайы қатты шек — басқа инженерлік мәселе: жіберу жолының ішінде сеанстар бойы бір тіркелгіге байланған орындау. Санағыштарды жылдамырақ оқу бір нәрсе емес және жай ғана көбірек туннель ашатын клиентке төтеп бермейді.

Іске қосу алдында аңғал іске асыруларды бұзатын қабылдау жағдайларын жүргізіңіз: қайталамалы қайта қосылулар, бір уақытта екі құрылғы, контроллер мен шлюздің қайта іске қосылуы, жоғалған ажырату оқиғасы, сеанс ортасында кезеңнің ауысуы және таусылудан кейін бірден токенмен қайта қосылу әрекеті. Содан кейін есепке алу үзілістерінің істен шығу режимін шешіңіз. Тұрақты кітап жазған пайдалануыңызды қорғайды; ол ешқашан келмеген бақылауларды тірілте алмайды, және клиент осы екі жағдайдың қайсысында екенін білуге лайық.

Қатысты мақалалар