Първата сесия печели: ограничаване на 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 |
Анкетирането на файла със състояние също не е врата. Два опита, пристигнали заедно, могат и двата да видят празен слот, преди някой да го заеме, и двата да продължат.
Преместете решението в автентикацията
Интерфейсът за управление може да поеме решението за автентикация след проверка на сертификата. При тази схема контролерът не е наблюдател: той получава всеки свързващ се клиентски екземпляр и отговаря дали този екземпляр може да продължи. Тъй като отговорът идва преди установяването, отказът оставя текущата сесия непокътната. Същият канал съобщава за прекъсвания и така контролерът научава, че слот е бил законно освободен.
Всеки нов екземпляр трябва да мине през тази врата, включително повторните свързвания и всеки път, който повторно автентикира без подкана. Врата, до която някои екземпляри никога не стигат, не защитава нищо и пропускът остава невидим, докато някой не използва заобикалянето.
Токените могат да минат покрай вратата
След като бъде издаден токен, сървърът може да го валидира вътрешно и да пропусне външната автентикация за тази връзка. Извикването към управлението никога не се случва, така че проверка на слота, реализирана само там, никога не вижда новия екземпляр. Това поведение е удобство за потребителите и дупка за политиката за паралелност. Накарайте връзките с токен да минават през еквивалентна авторитетна проверка или изключете пътя с токен, когато политиката изисква решение за всяка връзка.
Не компенсирайте, като приемате всеки токен безусловно. Изтекъл или невалиден токен все още трябва да се провали и трябва да се провали през същата точка на решение като всичко останало.
Вържете резервацията към екземпляр, а не към адрес
Адресът е слаба идентичност: повторно свързване от същия лаптоп може да дойде от друг адрес, а копирано удостоверение може да дойде от същия. Вържете резервацията към клиентския екземпляр, който сървърът назначава, така че повторната автентикация на вече допуснатия екземпляр да бъде разпозната като собственик. Нов идентификатор на екземпляр трябва да получи своя слот чрез решението първият печели, дори когато представя същия токен.
Освобождавайте само резервацията на неуспешния опит. Закъсняло събитие за прекъсване от по-стар опит не бива да изчиства слота на по-нов собственик и затова освобождаването назовава екземпляра, а не акаунта. След рестарт на контролера съгласувайте живите сесии, преди да допуснете някого, и прилагайте същото правило на всеки шлюз, който обслужва акаунта.
Решете отделно как се възстановява наистина остарял слот. На администратора е нужен документиран начин да го изчисти и този път не бива да е достъпен за потребител, който просто натиска повторно свързване.
Тествайте двойките, които имат значение: два почти едновременни входа, повторно свързване след чисто прекъсване, повторна автентикация на текущата сесия, отказан новодошъл и рестарт на контролера. Във всеки случай текущата сесия трябва да остане използваема, а новодошлият да бъде отказан без вреди за други акаунти.