Jeden użytkownik nie może zalogować się do VPN: uporządkowana diagnoza

Gdy jedna osoba nie może się połączyć, a reszta zespołu pracuje dalej, użyteczne pytanie nie brzmi, co jest zepsute, ale która warstwa się nie zgodziła. Logowanie to łańcuch: klient startuje, brama odpowiada, tożsamość zostaje zgłoszona, drugi czynnik zostaje spełniony, polityka jest oceniana, i dopiero wtedy płynie ruch. Przerwanie w dowolnym miejscu tego łańcucha dociera do państwa jako to samo zdanie od użytkownika, więc pierwszym zadaniem jest znalezienie ogniwa, które naprawdę zawiodło.

Traktujcie zgłoszenie jako punkt wyjścia, a nie diagnozę. Poniższe kontrole idą od najtańszej, a każda jest napisana tak, by zakończyć dochodzenie, gdy zawiedzie.

Ustalcie etap i znacznik czasu

Zapiszcie cztery rzeczy, zanim dotkniecie jakiejkolwiek konfiguracji: klienta i jego wersję, dokładne brzmienie na ekranie, minutę próby i sieć, w której była ta osoba. Brzmienie niesie realną informację, bo odrzucone dane logowania, brama, która nie odpowiada, i zakończone logowanie, które nadal nie otwiera strony wewnętrznej to trzy różne problemy z trzema różnymi właścicielami. Zwróćcie uwagę, czy klient utworzył lokalny wiersz dziennika, bo klient, który nigdy nie wysłał pakietu, nie ma nic do dodania do wyszukiwania po stronie serwera. Po zapisaniu znacznika czasu każde późniejsze zapytanie staje się wyszukiwaniem, a nie polowaniem.

Przestańcie w tym miejscu zgadywać hasła. Tam, gdzie konto ma limit ponownych prób, seria szybkich prób może je zablokować i dołożyć drugą, sztuczną usterkę na prawdziwą. Zapiszcie, ile prób już wykonano, żeby blokada nie została później wzięta za nowy objaw. Zablokowane konto odbiera też możliwość odróżnienia błędnego hasła od odrzuconej polityki, ponieważ oba przychodzą jako odmowa.

Odczytajcie zdarzenie tożsamości dla tej jednej próby

Poproście administratora o wyciągnięcie rekordu uwierzytelniania, który odpowiada zapisanej minucie. W instalacji Windows NPS przewodnik firmy Microsoft po rozwiązywaniu problemów z NPS dokumentuje zdarzenie odrzucenia 6273 wraz z towarzyszącym mu kodem przyczyny, co zwykle oddziela nieznanego użytkownika, złe dane logowania, niezgodność polityki i połączenie przerwane z niepowiązanego powodu.

Pusty wynik też jest informacją. Jeśli nic nie dotarło do usługi tożsamości, próba zginęła wcześniej: nieaktualny adres bramy w profilu, odbiornik, do którego klient nie może dotrzeć, albo host wycofany z eksploatacji, gdy profil nadal żył. Jeśli rekord istnieje i zgłasza sukces, dane logowania nie są problemem, a spór przenosi się na autoryzację lub na trasowanie za bramą. Te dwa wyniki wskazują przeciwne kierunki, dlatego przeszukanie dzienników musi nastąpić, zanim ktoś przeinstaluje klienta.

Zatrzymajcie kod przyczyny w zgłoszeniu. To jedno pole zamienia następne wystąpienie w pięciominutowe wyszukiwanie zamiast powtarzanego dochodzenia. Połączcie je z wersją klienta, bo kod pojawiający się w jednej kompilacji to inna rozmowa niż ten, który pojawia się w każdej.

Zmieniajcie jeden warunek naraz, w granicach polityki

Pokusa jest taka, by w jednym podejściu przeinstalować klienta, zresetować hasło i przenieść laptopa do innej sieci. To czasem naprawia objaw i zawsze niszczy dowody. Wybierzcie zamiast tego jedną dozwoloną zamianę: ta sama osoba na drugim zarejestrowanym urządzeniu albo zatwierdzona tożsamość testowa na tym samym urządzeniu. Każda zamiana odpowiada dokładnie na jedno pytanie, więc sukces zawęża usterkę do strony, którą zmieniliście, zamiast obwiniać cały VPN.

Nie pożyczajcie danych logowania kolegi do tego porównania. Użyjcie tożsamości testowej przez wspierany proces i nigdy nie kopiujcie klucza urządzenia ani nie pomijajcie rejestracji dlatego, że byłoby szybciej. Tam, gdzie polityka całkowicie zabrania zamiany, to ograniczenie jest częścią testowanego systemu i należy do zapisu, a nie do obejścia.

Potwierdźcie naprawę na pierwotnej ścieżce

Gdy zerwane ogniwo zostanie zidentyfikowane, naprawcie tylko to ogniwo i powtórzcie pierwotną próbę: ta sama osoba, to samo urządzenie, ta sama sieć, ta sama aplikacja. Konto testowe łączące się z VLAN-u administracyjnego dowodzi, że brama żyje, i nie dowodzi niczego o wtorkowym poranku użytkownika. Poproście użytkownika o wykonanie czynności, która zawiodła, a nie prostszej, bo udany ping mówi niewiele o odrzuconym udziale plików.

Zamknijcie zgłoszenie tym, co wykluczono i co się zmieniło. Ta notatka to różnica między jednorazowym ratunkiem a czymś, co następny dyżurujący inżynier będzie mógł wykorzystać ponownie.