Wygrywa pierwsza sesja: ograniczanie logowań OpenVPN przed usunięciem
Odrzucenie późniejszego logowania to nie to samo co zastąpienie starego. Decyzja musi zapaść przed usunięciem tej samej nazwy, a sprawdzenie slotu musi być atomowe.
Zasada dopuszczająca jedną sesję na konto wydaje się rozstrzygnięta, dopóki nie nadejdzie drugie logowanie. Możliwe są dwa wyniki: nowy użytkownik zastępuje działającą sesję albo działająca sesja zachowuje slot, a nowy zostaje odrzucony. Tylko drugi jest zasadą, w której wygrywa pierwsza sesja. Opcja klienta, po którą sięga większość, włącza współbieżność i dlatego tego nie daje.
Za jednym ustawieniem kryją się dwie umowy
Przy wyłączonej współbieżności drugie połączenie z tą samą nazwą certyfikatu może wyprzeć już działającą sesję. Włączenie współbieżności pozwala na kilka sesji naraz, co jest przeciwieństwem limitu. Żaden z tych stanów nie jest zasadą odrzucania, więc decyzja musi zapaść zupełnie gdzie indziej.
Zapisz umowę, zanim cokolwiek wdrożysz: kto jest odrzucany, jaki dowód identyfikuje działającą sesję i co się dzieje, gdy sesja umiera bez czystego rozłączenia. Zasady, której nikt tak nie sformułował, nie da się później przetestować.
Usunięcie następuje przed twoim hookiem połączenia
W ścieżce kodu serwera 2.6 wczesne przygotowanie nowego klienta usuwa istniejące instancje o tej samej nazwie, gdy współbieżność jest wyłączona. To usunięcie następuje przed uruchomieniem łańcucha procedur obsługi połączenia. Skrypt, który zauważy duplikat i zwróci błąd, odrzuca więc nowego po tym, jak działająca sesja została już wyrzucona - dokładnie ten wynik, któremu zasada miała zapobiec. Kolejność wywołań zwrotnych w implementacji upstream jest jedyną wiarygodną odpowiedzią dla twojej kompilacji.
| 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 |
Odpytywanie pliku stanu też nie jest bramą. Dwie próby, które przyjdą jednocześnie, mogą obie zobaczyć pusty slot, zanim którakolwiek go potwierdzi, i obie przechodzą dalej.
Przenieś decyzję do uwierzytelniania
Interfejs zarządzania może przejąć decyzję o uwierzytelnieniu po weryfikacji certyfikatu. W takim układzie kontroler nie jest obserwatorem: otrzymuje każdą łączącą się instancję klienta i odpowiada, czy ta instancja może kontynuować. Ponieważ odpowiedź przychodzi przed ustanowieniem, odmowa pozostawia działającą sesję nietkniętą. Ten sam kanał zgłasza rozłączenia, i tak kontroler dowiaduje się, że slot został legalnie zwolniony.
Każda nowa instancja musi przejść przez tę bramę, w tym ponowne połączenia i każda ścieżka, która uwierzytelnia się ponownie bez pytania. Brama, do której niektóre instancje nigdy nie docierają, niczego nie chroni, a to przeoczenie pozostaje niewidoczne, dopóki ktoś nie wypróbuje obejścia.
Tokeny mogą przejść obok bramy
Gdy token zostanie wydany, serwer może zweryfikować go wewnętrznie i pominąć uwierzytelnianie zewnętrzne dla tego połączenia. Wywołanie zarządzania nigdy nie następuje, więc sprawdzenie slotu zaimplementowane tylko tam nigdy nie widzi nowej instancji. Takie zachowanie to wygoda dla użytkowników i dziura w zasadzie współbieżności. Spraw, aby połączenia uwierzytelnione tokenem przechodziły równoważną wiążącą kontrolę, albo wyłącz ścieżkę tokenu, gdy zasada wymaga decyzji przy każdym połączeniu.
Nie rekompensuj tego bezwarunkowym akceptowaniem każdego tokenu. Wygasły lub nieprawidłowy token nadal musi zawieść i musi zawieść przez ten sam punkt decyzyjny co wszystko inne.
Powiąż rezerwację z instancją, a nie z adresem
Adres to słaba tożsamość: ponowne połączenie z tego samego laptopa może przyjść z innego adresu, a skopiowane dane logowania mogą przyjść z tego samego. Powiąż rezerwację z instancją klienta przydzieloną przez serwer, aby ponowne uwierzytelnienie już dopuszczonej instancji było rozpoznawane jako właściciel. Nowy identyfikator instancji musi zdobyć własny slot przez decyzję pierwszy wygrywa, nawet gdy przedstawia ten sam token.
Zwalniaj tylko rezerwację należącą do nieudanej próby. Opóźnione zdarzenie rozłączenia ze starszej próby nie może wyczyścić slotu nowszego właściciela, dlatego zwolnienie nazywa instancję, a nie konto. Po restarcie kontrolera uzgodnij żywe sesje, zanim kogokolwiek wpuścisz, i stosuj tę samą regułę na każdej bramie obsługującej konto.
Osobno zdecyduj, jak odzyskiwany jest naprawdę przestarzały slot. Administrator potrzebuje udokumentowanego sposobu jego wyczyszczenia, a ta ścieżka nie powinna być dostępna dla użytkownika, który po prostu klika połącz ponownie.
Przetestuj pary, które mają znaczenie: dwa niemal jednoczesne logowania, ponowne połączenie po czystym zamknięciu, ponowne uwierzytelnienie działającej sesji, odrzuconego nowego użytkownika i restart kontrolera. W każdym przypadku działająca sesja musi pozostać użyteczna, a nowy musi zostać odrzucony bez szkód ubocznych dla innych kont.