Першая сесія перамагае: абмежаванне ўваходаў OpenVPN да выгнання
Адхіліць пазнейшы ўваход - не тое самае, што замяніць стары. Рашэнне павінна прымацца да выгнання аднайменнай сесіі, а праверка слота мусіць быць атамарнай.
Палітыка, якая дазваляе адну сесію на ўліковы запіс, выглядае вырашанай, пакуль не прыйдзе другі ўваход. Магчымыя два вынікі: наведвальнік замяняе бягучую сесію або бягучая сесія захоўвае слот, а наведвальніку адмаўляюць. Толькі другі варыянт - гэта палітыка першая сесія перамагае. Кліенцкая опцыя, да якой звяртаюцца большасць, уключае паралельнасць і таму гэтага не дае.
За адной наладай хаваюцца два кантракты
Калі паралельнасць адключана, другое злучэнне з тым самым імем сертыфіката можа выцесніць ужо працуючую сесію. Уключэнне паралельнасці дазваляе некалькі сесій адначасова, што супрацьлеглае абмежаванню. Ні адзін з гэтых станаў не з'яўляецца палітыкай адмовы, таму рашэнне трэба прымаць зусім у іншым месцы.
Запішыце кантракт да таго, як нешта ўкараняць: каму адмаўляюць, якія доказы вызначаюць бягучую сесію і што адбываецца, калі сесія памірае без чыстага адключэння. Палітыку, якую ніхто не сфармуляваў такім чынам, потым немагчыма праверыць.
Выгнанне адбываецца раней за ваш хук падключэння
У шляху кода сервера 2.6 ранняя наладка новага кліента выдаляе існуючыя асобнікі з тым самым імем, калі паралельнасць адключана. Гэтае выдаленне адбываецца да запуску ланцужка апрацоўшчыка падключэння. Таму скрыпт, які заўважае дублікат і вяртае збой, адмаўляе наведвальніку ўжо пасля таго, як бягучую сесію скінулі, - менавіта той вынік, якому палітыка мела перашкодзіць. Парадак зваротаў у upstream-рэалізацыі - адзіны надзейны адказ для вашай зборкі.
| Stage | Who can still refuse | Effect on the incumbent |
|---|---|---|
| Certificate check | Server trust configuration | None |
| Authentication decision | The authentication controller | None, because establishment has not run |
| Connect handler | A profile script | Already evicted in the same-name case |
| Post-establishment | Status tooling, monitoring | Both sessions already exist or one is gone |
Апытанне файла стану таксама не з'яўляецца брамай. Дзве спробы, што прыйшлі адначасова, могуць абедзве ўбачыць пусты слот, перш чым хоць адна зафіксуе яго, і абедзве працягнуць.
Перанясіце рашэнне ў аўтэнтыфікацыю
Інтэрфейс кіравання можа ўзяць на сябе рашэнне аб аўтэнтыфікацыі пасля праверкі сертыфіката. У такой схеме кантролер не назіральнік: ён атрымлівае кожны асобнік кліента, што падключаецца, і адказвае, ці можа гэты асобнік працягваць. Паколькі адказ прыходзіць да ўсталявання, адмова не кранае бягучую сесію. Той жа канал паведамляе аб адключэннях, і так кантролер даведваецца, што слот быў законна вызвалены.
Кожны новы асобнік мусіць прайсці гэтую браму, уключаючы перапаключэнні і любы шлях, які паўторна аўтэнтыфікуе без запыту. Брама, да якой некаторыя асобнікі не даходзяць, нічога не абараняе, і гэты прабел застаецца нябачным, пакуль хто-небудзь не скарыстаецца абыходам.
Токены могуць прайсці міма брамы
Пасля выпуску токена сервер можа праверыць яго ўнутрана і прапусціць знешнюю аўтэнтыфікацыю для гэтага злучэння. Выклік кіравання не адбываецца, таму праверка слота, укаранёная толькі там, ніколі не ўбачыць новы асобнік. Такія паводзіны - зручнасць для карыстальнікаў і дзірка для палітыкі паралельнасці. Прымусьце злучэнні з токенам праходзіць эквівалентную аўтарытэтную праверку або адключыце шлях токена, калі палітыка патрабуе рашэння для кожнага злучэння.
Не кампенсуйце гэта безумоўным прыняццем кожнага токена. Пратэрмінаваны або няправільны токен усё роўна мусіць збаіць, і збаіць праз тую ж кропку рашэння, што і ўсё астатняе.
Прывяжыце рэзерваванне да асобніка, а не да адраса
Адрас - дрэнная ідэнтычнасць: перапаключэнне з таго ж ноўтбука можа прыйсці з іншага адраса, а скапіяваныя ўліковыя даныя - з таго ж. Прывяжыце рэзерваванне да асобніка кліента, які прызначае сервер, каб паўторная аўтэнтыфікацыя ўжо дапушчанага асобніка прызнавалася ўласнікам. Новы ідэнтыфікатар асобніка мусіць атрымаць свой слот праз рашэнне першы перамагае, нават калі ён прад'яўляе той самы токен.
Вызваляйце толькі рэзерваванне таго запыту, што не ўдаўся. Затрыманая падзея адключэння ад старога запыту не павінна ачышчаць слот больш новага ўласніка, і таму вызваленне называе асобнік, а не ўліковы запіс. Пасля перазапуску кантролера ўзгадніце жывыя сесіі, перш чым кагосьці дапускаць, і ўжывайце тое ж правіла на кожным шлюзе, які абслугоўвае ўліковы запіс.
Асобна вырашыце, як аднаўляецца сапраўды састарэлы слот. Адміністратару патрэбен дакументаваны спосаб ачысціць яго, і гэты шлях не павінен быць даступны карыстальніку, які проста націскае перапаключэнне.
Праверце пары, што маюць значэнне: два амаль адначасовыя ўваходы, перапаключэнне пасля чыстага разрыву, паўторная аўтэнтыфікацыя бягучай сесіі, адхілены наведвальнік і перазапуск кантролера. У кожным выпадку бягучая сесія мусіць заставацца прыдатнай, а наведвальніку трэба адмовіць без шкоды для іншых уліковых запісаў.