Licznik sesji VPN i token uwierzytelniania wygasają osobno

Zerwanie VPN może nastąpić z powodów, które z punktu widzenia klienta wyglądają identycznie i pod spodem nie mają nic wspólnego: sesja tunelu się skończyła, zadziałał licznik bezczynności albo stało się nieaktualne poświadczenie, którego klient używał ponownie. Każdy ma innego właściciela i inne rozwiązanie. Właśnie sekwencja błędów w chwili zerwania je rozdziela, i zwykle jest to jedna linia.

Przeciw jednemu tunelowi biegną trzy zegary, i tylko jeden z nich jest samym tunelem.

Trzy różne zegary na jednym tunelu

Zegar sesji należy do bramy: maksymalny czas połączenia, limit bezczynności albo oba, i kończy tunel, gdy osiągnięty zostanie którykolwiek z nich. Zegar tokenu należy do systemu uwierzytelniania i decyduje, jak długo poświadczenie można przedstawić ponownie bez człowieka. Zegar ścieżki należy do dowolnego NAT lub zapory między klientem a bramą i pozwala wygasać mapowaniom przepływów, które uważa za zakończone. Wszystkie trzy powodują rozłączenie, i żaden nie daje tej samej linii dziennika.

Tylko pierwszy jest pojęciem VPN. Pozostałe dwa są zapożyczone z tożsamości i sieci, i rutynowo się je z nim myli.

Jak token jest naprawdę używany ponownie

Serwery OpenVPN mogą wydać token uwierzytelniania po pierwszym logowaniu, dzięki czemu ponowne negocjowanie kanału sterowania nie prosi użytkownika ponownie o poświadczenia. Klient nadal przedstawia ten token, a serwer decyduje, jak długo pozostaje on akceptowalny. Gdy czas życia tokenu jest krótszy niż interwał ponownego negocjowania, następne negocjowanie kończy się niepowodzeniem, a klient zgłasza błąd uwierzytelniania zamiast przekroczenia czasu. Dlatego ten sam profil działa przez godzinę, a potem zawodzi w ustalonym punkcie.

Interwał ponownego negocjowania to osobne ustawienie. Jego zmiana przesuwa moment przedstawienia tokenu, a nie czas jego życia.

Jak wygląda każde wygaśnięcie z punktu widzenia klienta

Limit czasu sesji zwykle przychodzi jako czyste rozłączenie z powodem po stronie serwera, często po przewidywalnym czasie i bez żadnego błędu uwierzytelniania. Limit bezczynności wygląda jak cisza: tunel przestaje przenosić ruch, a potem utrzymywanie połączenia się poddaje. Wygaśnięcie tokenu przychodzi jako AUTH_FAILED w środku sesji, która działała sekundę wcześniej.

Przeczytaj linię, a potem spójrz na zegar. Czas, który pasuje do skonfigurowanej wartości, nie jest przypadkiem.

Dlaczego zapisane hasło nie pomaga

Hasło w pamięci podręcznej odpowiada na wyzwanie dotyczące hasła. Nie przedłuża życia tokenu i nie spełnia wyzwania drugiego czynnika ani sprawdzenia stanu urządzenia. Zwiększanie częstotliwości ponowień, skracanie limitów czasu połączenia albo ponowny import profilu niczego nie zmienia w tym, jak długo system tożsamości będzie akceptował poświadczenie.

Trwałe poprawki to właściwy czas życia na właściwym obiekcie albo przepływ klienta, który potrafi wykonać wymagane wyzwanie bez człowieka.

Co udokumentować i przetestować

Zapisz wszystkie trzy wartości: limity sesji i bezczynności bramy, czas życia tokenu oraz najkrótszy istotny limit czasu mapowania na ścieżce. Następnie celowo przetestuj każde wygaśnięcie, skracając jedną wartość, obserwując, co zgłasza klient, i przywracając ją. Potwierdź, co użytkownik musi zrobić na każdej granicy, ponieważ wymaganie pełnego logowania co godzinę jest decyzją polityki, którą ktoś powinien był podjąć świadomie.

Zerwanie, które przychodzi całkowicie bez żadnego zdarzenia uwierzytelniania, należy do ścieżki albo do licznika bezczynności, i to jest inne śledztwo z innymi dowodami.