VPN w Windows nie łączy? Dopasuj kod do dziennika zdarzeń

W piątek to działało. W poniedziałek ten sam klient Windows odpowiada oknem, które mówi, że próba połączenia nie powiodła się, a zdanie pod nim jest tym, które widziałeś już przy tuzinie niepowiązanych problemów. To okno jest końcem łańcucha, a nie jego początkiem. Windows ukrywa etap, na którym próba naprawdę umarła, a dwa małe dowody go nazywają: liczbowy kod wyniku i jedno zdarzenie RasClient z tej samej minuty. Oto kolejność, której używam — ustal próbę, odczytaj kod, pobierz zdarzenie, a potem zmień dokładnie jedną warstwę.

Tekst okna to ostatni krok, nie przyczyna

Zdanie, które czytasz, jest wybierane po tym, jak próba już się rozwinęła. „Połączenie zostało zakończone przez komputer zdalny, zanim nawiązano połączenie” pojawia się, gdy serwer odkłada słuchawkę w połowie negocjacji, gdy IPsec zawiódł, zanim twoja nazwa użytkownika została w ogóle wysłana, i gdy zasada odrzuciła tunel z miejsca. Trzech różnych właścicieli, jedno zdanie. Traktuj sformułowanie jako klasę objawów i nie pozwól mu niczym kierować, dopóki kod się z nim nie zgodzi.

To, co nadal możesz ustalić, to sama próba. Zapisz nazwę połączenia, typ tunelu zapisany w profilu — PPTP, L2TP/IPsec, SSTP lub IKEv2 —, czas co do sekundy i kod. Jeśli nie masz pewności, który protokół naprawdę działał, otwórz %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk i przeczytaj wpis, zamiast ufać pamięci; profil użyty ponownie dla nowego protokołu zachowuje swoją starą nazwę wyświetlaną.

Przeczytaj liczbę, zanim przeczytasz słowa

Kody dzielą się na trzy etapy, i etap liczy się bardziej niż dokładne sformułowanie: wymiana uwierzytelniania, do której dotarto i którą odrzucono, serwer, który nigdy nie odpowiedział, albo negocjacja, która się zawaliła po podniesieniu łącza. 691 to pierwszy rodzaj — sprawdzenie poświadczeń odbyło się i nie powiodło, czy to z powodu złego hasła, zablokowanego lub wygasłego konta, czy protokołu uwierzytelniania, którego serwer nie akceptuje. 812 to także odmowa, ale z ważnymi poświadczeniami: zasada na serwerze dostępu zdalnego zdecydowała przeciwko tobie. Microsoft utrzymuje kanoniczną lista kodów błędów połączeń komutowanych i VPN, i warto przeczytać tam swój numer, zanim zaczniesz szukać tekstu komunikatu.

809 to klasa przeciwna: nic nie wróciło. To problem ścieżki — TCP 443 filtrowany dla SSTP, GRE blokowany dla PPTP, UDP 500 i 4500 albo ESP odrzucane dla przejścia IPsec. Nowe hasło tego nie naprawi, a nowy certyfikat też nie. 720 oznacza, że łącze się podniosło i PPP nigdy nie dokończył negocjacji, co wskazuje na niezgodność protokołu albo serwer, który nie potrafił przydzielić adresu. 789, albo 13801 w IKEv2, to tożsamość wewnątrz IPsec: certyfikat, którego podmiot nie zgadza się z nazwą, na którą dzwonisz, niezaufany łańcuch albo klucz wstępnie współdzielony, który różni się między dwoma końcami.

Pobierz zdarzenie RasClient z tej samej minuty

W Podglądzie zdarzeń Windows Logs > Application filtrowane według źródła RasClient to pierwsze miejsce, w które warto spojrzeć. Opis błędu 720 autorstwa Microsoftu wskazuje zdarzenie 20227 w tym dzienniku. Ten sam dostawca emituje inne identyfikatory dla innych wyników, więc czytaj komunikat i osadzony w nim kod wyniku, zamiast traktować ID jako diagnozę; ogólne okno plus 20227 niosące 720 to już znacznie węższa historia.

Z programu PowerShell, bez klikanie przez GUI:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

Pusty wynik jest pouczający. Zwykle oznacza, że wybieranie nigdy nie zaszło dość daleko, by RAS cokolwiek zapisał, albo że oprogramowanie, które zawiodło, wcale nie jest natywnym klientem — klienci firm trzecich trzymają własną diagnostykę i często nic nie zapisują do dziennika Application. Sprawdź dziennik dostawcy, zanim stwierdzisz, że rejestrowanie zdarzeń jest zepsute.

Zbuduj jedną os czasu zamiast stosu zdarzeń

Pętle ponownych prób tworzą szum. Pięć automatycznych ponownych połączeń zostawia grupę zdarzeń, a pokusa jest taka, by czytać je jako jedną sekwencję z jedną przyczyną. To pięć osobnych prób i tylko część z nich dotarła do serwera. Weź okno dwóch lub trzech minut, jedną nazwę połączenia i wypisz każde zdarzenie z jego własnym kodem, zanim cokolwiek zinterpretujesz.

Potem zapytaj, gdzie próba się zatrzymała. Gdy brama albo backend uwierzytelniania nie ma żadnego rekordu dla tego znacznika czasu, klient nigdy do niego nie dotarł i patrzysz na problem osiągalności. Gdy backend pokazuje żądanie i odmowę, decyzja zapadła tam i obowiązuje klasa poświadczeń lub zasady. Porównaj zegary, zanim porównasz czasy: klienci raportują czas lokalny, wiele bram rejestruje w UTC, a przesunięcie sprawi, że idealnie skorelowana para będzie wyglądać na niepowiązaną.

Dla powtarzalnego zapisu wybierz z wiersza poleceń i pozwól mu wydrukować wynik:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

Konsola pokazuje numer, który GUI ukrywa za przyjaznym tekstem, a uruchomienie dwa razy mówi, czy kod jest stabilny, czy pojawia się okresowo.

Co każdy etap każe zmienić

Nazwanie etapu jest użyteczne tylko wtedy, gdy zwęża zbiór zmian do jednej warstwy:

• 691 — uwierzytelnianie: metoda EAP oferowana przez klienta wobec tej, którą akceptuje serwer, stan konta, wygaśnięcie hasła, uprawnienie do połączeń przychodzących.
• 812 — zasada serwera: zasada dostępu zdalnego lub reguła NPS pasująca do tego użytkownika i tego okna czasowego.
• 809 — osiągalność: reguły zapory na ścieżce, NAT i przejście protokołu, port potrzebny wybranemu typowi tunelu.
• 720 — negocjacja PPP: niezgodność protokołu uwierzytelniania, przydział adresu, ustawienie PPP po stronie serwera.
• 789 / 13801 — tożsamość IPsec: podmiot certyfikatu wobec nazwy, na którą dzwonisz, łańcuch zaufania, klucz wstępnie współdzielony.

Zmień jedną z tych rzeczy, przetestuj ponownie ten sam profil i zapisz nowy kod. Inny kod po zmianie to postęp, a nie sprzeczność: przesunąłeś awarię na późniejszy etap, a tak wygląda naprawa wieloetapowego uścisku dłoni. Czego nie powinieneś robić, to zmieniać zaporę, certyfikat i hasło za jednym posiedzeniem, a potem przypisywać zasługę temu, co przyszło ostatnie.

Udostępniaj dowody, nie środowisko

Komunikaty zdarzeń są bogatsze, niż wyglądają. Niosą nazwę połączenia, konto, często wewnętrzną nazwę lub adres bramy, a czasem odcisk certyfikatu. Trzymaj oryginał tam, gdzie jego miejsce, i zbuduj osobną zredagowaną kopię dla każdego innego; przepisywanie osi czasu z pamięci gubi dokładnie te szczegóły, które czynią ją użyteczną.

Przekazanie, które zostanie podjęte, potrzebuje pięciu pól: kodu, etapu, do którego należy, klienta i typu tunelu, znacznika czasu ze strefą czasową oraz tego, czy brama w ogóle widziała żądanie. Wszystko inne jest opcjonalne. Z tymi pięcioma następna osoba odróżni spór o poświadczenia od sporu o routing, nie powtarzając dochodzenia.

Zanim cokolwiek zamkniesz, odtwórz próbę na tym samym profilu i potwierdź, gdzie kod teraz ląduje. Sukces to kończy; inna awaria oznacza, że pierwotny etap jest naprawiony, a następny masz w ręku.