Dlaczego ponowne połączenie VPN znów prosi o dane logowania
Zapisane hasło i token wielokrotnego użytku wygasają według różnych harmonogramów. Przeczytaj, jakiego materiału zażądało ponowne połączenie, zanim cokolwiek zmienisz na kliencie.
Tunel, który działał godzinami, prosi o hasło w chwili, gdy laptop się budzi, a w konfiguracji nic się nie zmieniło. Zmienił się stan danych logowania, które ponowne połączenie próbowało wykorzystać ponownie. Rządzą tym trzy rodzaje materiału i tylko jeden z nich przetrwa dowolną przerwę.
Przeczytaj, którego zażądał klient, bo wszystkie trzy wygasają według różnych zegarów i kończą się różnymi komunikatami.
Trzy rodzaje materiału wielokrotnego użytku
Zapisane w pamięci podręcznej hasło to sekret trzymany przez klienta i pozostaje ważne, dopóki konto go nie zmieni. Token sesji wystawia serwer po udanym logowaniu, ma własny czas życia i można go unieważnić w każdej chwili. Bilet sesji TLS lub asocjacja bezpieczeństwa IKE to stan protokołu, tani do wznowienia i całkowicie niezależny od twojego hasła. Każdy wystawia inny komponent i każdy wygasa na własnych warunkach.
Pierwszy przetrwa restart, drugi zwykle przetrwa uśpienie, a trzeci może w ogóle nie przetrwać zmiany sieci. Mylenie ich daje złe rozwiązanie, na przykład reset hasła, które nigdy nie zostało odrzucone.
Sam monit jest diagnozą. Okno przeglądarki lub kod drugiego składnika oznacza, że serwer zażądał uwierzytelnienia interaktywnego, natomiast cicha awaria bez monitu oznacza, że klient nigdy nie dotarł wystarczająco daleko, by go zapytano.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
Odnowienie kluczy to nie ponowne uwierzytelnienie
Odnowienie kluczy zastępuje klucze, zachowując uwierzytelnioną tożsamość, dlatego na zdrowym tunelu zdarza się to czasem po cichu. Ponowne uwierzytelnienie powtarza samą kontrolę tożsamości i to jest zdarzenie, które cię potrzebuje. IKEv2 wyraźnie rozdziela oba, a peer może wymagać pełnego ponownego uwierzytelnienia w skonfigurowanym interwale niezależnie od tego, ile odnowień kluczy miało miejsce pomiędzy. Oba zdarzenia wyglądają z zewnątrz identycznie, dopóki nie przeczytasz, które z nich nazywa dziennik.
OpenVPN zachowuje się tak samo we własnym słowniku: interwał ponownego negocjowania odświeża kanał danych, a token uwierzytelniania można zwrócić klientowi, aby uniknąć pełnego logowania przy następnym połączeniu. Ten token ma czas życia, a serwer decyduje, czy przyjąć go ponownie.
Tak więc ponowne połączenie po ośmiu godzinach może się nie udać tam, gdzie po ośmiu minutach się powiodło, bez żadnej zmiany konfiguracji po obu stronach. To całe wyjaśnienie monitu, który pojawia się dopiero po obiedzie.
Gdy klient nie potrafi ukończyć nowego wyzwania
Polityka wymagająca kroku w przeglądarce zawiedzie na kliencie, który nie ma sposobu go pokazać. Serwery bez interfejsu, skrypty startowe i stare profile zbudowane pod uwierzytelnianie samym hasłem wszystkie uderzają w tę ścianę, a awaria często pojawia się jako ogólny limit czasu, a nie błąd uwierzytelnienia.
Przejścia urządzenia i sieci również mogą wypaść w oknie oceny polityki, więc roaming z Wi-Fi do hotspotu zbiega się z kontrolą, która i tak by się odbyła. Ta zbieżność sprawia, że sieć wygląda na winną, gdy przyczyną jest licznik czasu.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
Pierwsza linia pokazuje zdarzenia ponownego negocjowania i uwierzytelniania w logu samego klienta, a druga pokazuje asocjacje bezpieczeństwa, które peer strongSwan obecnie trzyma. Porównaj znaczniki czasu z momentem pojawienia się monitu; zgodność potwierdza licznik czasu, a nie sieć.
Co zgłaszać, a czego nie wyłączać
Jeśli ręczne logowanie się udaje, a automatyczne ponowne użycie konsekwentnie zawodzi, powiedz to dokładnie operatorowi. To nazywa komponent: ścieżkę ponownego użycia, a nie dane logowania. Podaj czas awarii, używane konto i typ monitu, który widziałeś.
Nie wyłączaj drugiego składnika, nie pomijaj walidacji certyfikatu i nie wklejaj danych logowania do skryptu, aby ponowne połączenie było ciche. Każde z tych działań usuwa kontrolę, dla której istnieje polityka, i każde zamienia monit logowania w incydent.
Zamiast tego poproś o obsługiwany przepływ: klienta, który potrafi ukończyć wyzwanie, czas życia tokenu dopasowany do dnia pracy, albo zatwierdzony profil nieinteraktywny dla maszyny, która nie może zapytać. To wszystko decyzje konfiguracyjne, które ktoś może zatwierdzić, czym obejście nie jest.