Абмежаванні падключэнняў VPN: жывы стан супраць захаванай гісторыі
Абмежаванне ў тры адначасовыя падключэнні патрабуе жывога стану слотаў, а не гісторыі праглядаў: што механізм павінен захоўваць, што можна адкінуць і куды гэты стан ідзе далей.
Тры адначасовыя падключэнні — гэта рашэнне аб допуску, і каб адказаць на яго, трэба ведаць, якія слаты занятыя цяпер, а не што адбылося ў мінулым месяцы. Сэрвіс можа адмовіць чацвёртай сесіі з невялікай табліцы актыўных запісаў і зусім не будаваць храналогію. Гэта сцверджанне пра механізм, а не пра аператара, і розніца важная, калі вы чытаеце палітыку прыватнасці. Мадэль ніжэй паказвае, што патрэбна рашэнню і што яно можа адкінуць.
Механізм: табліца слотаў, а не журнал
Самая простая рэалізацыя звязвае падпіску з да трох актыўнымі запісамі сесій. Кожная дапушчаная сесія займае адзін слот, і слот вызваляецца, калі сэрвіс вырашае, што сесія скончылася. Запісу патрэбна дастаткова канкрэтная ідэнтычнасць, каб вызваленне аднаго падключэння не вызваляла слот іншага, і таму ідэнтыфікатар сесіі важнейшы за назву ўліковага запісу.
Занятасць і гісторыя — розныя структуры даных. Занятасць адказвае на пытанне так-не пра сучаснасць, і яе можна адкінуць у момант заканчэння сесіі. Гісторыя — гэта паток падзей толькі для дадання, і яна жыве таму, што нехта вырашыў яе захаваць. Сэрвіс можа мець адно, абодва або ні аднаго.
Розніца нябачная звонку. Бачнае абмежаванне падключэнняў сумяшчальна з маленькім лічыльнікам у памяці, агульнай табліцай базы даных і поўным архівам падзей з панэллю кіравання. Нішта ў абмежаванні не кажа, які з іх працуе.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
Чаму жывая мадэль усё трэба каардынацыі
Страчанае падключэнне можа не быць адразу пазнана як завершанае. Шлюз чакае тайм-аўту, збою keepalive або прыпынку ўліку, і пакуль адно з гэтага не прыйдзе, слот застаецца занятым. Карыстальнік, які перападключаецца ў гэтым акне, бачыць адмову, якая не мае дачынення да чацвёртай прылады.
Перазапушчаны сервер павінен узгадніць свой стан, а некалькі шлюзаў, што абслугоўваюць адзін уліковы запіс, патрабуюць агульнага рашэння. Інакш уліковы запіс можа перавысіць ліміт, падключаючыся да розных месцаў. Агульны або аднаўляльны стан вырашае гэта, і агульны стан — гэта патрабаванне дызайну, а не доказ назірання.
Нішта з гэтай каардынацыі не патрабуе гісторыі праглядаў. Шлюз, які перасылае пакеты, не павінен ведаць, якія сайты наведала сесія, каб лічыць сесіі, і гэтыя два патокі даных звычайна апрацоўваюць цалкам розныя кампаненты.
Захаванне ліку ў памяці таксама не робіць звязаныя факты ананімнымі. Пакуль сэрвіс працуе, запіс, звязаны з падпіскай, паказвае, што ўліковы запіс мае актыўныя падключэнні, і доступ да гэтага стану разам з яго працягласцю варта высветляць.
Куды стан ідзе потым
Пытанне прыватнасці не ў тым, ці можа сервер лічыць. Спытайце, што адбываецца з завершанай сесіяй: запіс выдаляюць ці ён становіцца падзеяй у серыі маніторынгу? Затым спытайце, якія іншыя кампаненты бачылі тую ж падзею, бо журналы аўтэнтыфікацыі, запісы ўліку і рэзервовыя копіі могуць кожны захаваць копію, якую шлях прымянення адкінуў.
Улік RADIUS — самы ясны прыклад. Пара Start і Stop існуе для падтрымкі білінгу і кіравання сесіямі, і яна стварае запіс падключэння незалежна ад таго, ці хто-небудзь калі-небудзь запытвае яго як гісторыю. Сэрвіс, які прымяняе абмежаванні праз улік, таму па сваёй канструкцыі захоўвае больш за табліцу слотаў.
Выдаленне таксама мае форму. Запіс, выдалены з жывой табліцы, можа захавацца ў рэзервовай копіі, зробленай гадзіну раней, і тэрмін захавання гэтай копіі — асобнае палітычнае сцверджанне. Чытанне толькі асноўнага сховішча дае няпоўны адказ.
Задайце пытанне ў тэрмінах палёў
Кіраўніцтва RFC 6973 па мінімізацыі даных звязвае сабраныя і захаваныя даныя з мэтай, якой яны служаць. Ужываючы гэта тут, карыснае пытанне — якія палі задачы адначасовага допуску сапраўды патрэбныя і якая мэта апраўдвае захаванне кожнага з іх пасля завяршэння гэтай задачы.
Дакладнае сцверджанне сэрвіса аддзяляе жывы стан падключэння, які выкарыстоўваецца для прымянення ліміту, ад любых запісаў, што захоўваюцца пасля спынення, і называе іншыя сістэмы ў межах абяцанкі. Сказ, які кажа толькі, што тры падключэнні прымяняюцца, не ўсталяўлівае ні што архіў існуе, ні што яго няма.
Калі жыццёвы цыкл незразумелы, запішыце яго як пытанне захавання без адказу, а не як вырак. Наяўнасць абмежавання не з'яўляецца доказам схаванай гісторыі, і праўдападобнае тлумачэнне жывога стану не з'яўляецца аўдытам правайдэра.