Kody błędów VPN w Windows: który etap zawiódł i co rejestrować

Otwórz okno VPN w Windows po niepowodzeniu, a otrzymasz numer i zdanie, przy czym zdanie jest zwykle tą mniej użyteczną połową. Numer wskazuje, który etap połączenia zawiódł, a etap decyduje, którego logu, którego ustawienia i którego zespołu szukać dalej. Przejście przez etapy po kolei zajmuje około dziesięciu minut i zapobiega znanej sekwencji: reinstalacji adapterów, zmiany protokołów i resetowania stosu, by naprawić konto, któremu nigdy nie pozwolono wybierać numeru.

Czytaj numer jako etap

Połączenie natywne przechodzi przez cztery kamienie milowe. Dociera do serwera i ustanawia łącze, negocjuje zabezpieczenia, uwierzytelnia użytkownika i stosuje adresowanie oraz routing. Błąd w każdym z nich zostawia inne dowody, a kod należący do jednego etapu nie mówi nic użytecznego o pozostałych.

Błędem, którego należy unikać, jest traktowanie kodu jako stopnia istotności. Błąd łącza i błąd autoryzacji czytają się oba jako "nie można się połączyć" i nie mają poza tym nic wspólnego. Istotność mówi, jak pilna jest sprawa; etap mówi, co otworzyć.

Etap pierwszy: łącze i próba połączenia

829 oznacza, że podstawowe łącze spadło. Nie mówi, czy zdalny partner przestał odpowiadać, czy urządzenie pośredniczące zabiło sesję, czy polityka na kliencie ją zamknęła. Kod zakończenia połączenia, taki jak 703, jest jeszcze wcześniejszy: próba nigdy nie dotarła do łącza, co zwykle wskazuje na profil, stan usługi albo politykę lokalną.

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

Zapytanie o zdarzenia to część, którą ludzie pomijają. Zapis po stronie klienta ze znacznikiem czasu i nazwą interfejsu jest wart więcej niż okno dialogowe, bo mówi, czy próba w ogóle opuściła maszynę. Brak zapisu i brak odpowiedzi nasłuchu to problem osiągalności, a żadna edycja klienta tego nie zmienia.

Jeśli ten sam profil działa w innej sieci, zatrzymaj się tutaj. Kod opisuje warunek ścieżki, a nie błąd konfiguracji, a następnym użytecznym porównaniem są dwa przechwycenia, nie kolejna reinstalacja.

Etap drugi: PPP i powiązanie miniportu

720 leży między łączem a użytkownikiem. Tunel się podniósł, a potem warstwa PPP nie mogła wynegocjować adresu ani protokołu sterującego, co często jest problemem powiązania na kliencie, a nie odrzuconymi poświadczeniami. Ta różnica to cała wartość kodu: mówi, że poświadczeń nigdy nie osiągnięto, więc konto nie jest podejrzanym.

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

Czytanie tych dwóch wyników jest bardziej pouczające niż resetowanie czegokolwiek. Miniport, który istnieje, ale nie został uruchomiony, albo powiązanie protokołu wyłączone przez inne oprogramowanie, daje dokładnie awarię tego etapu. Oba da się naprawić bez dotykania reszty stosu. Pełny reset usuwa natomiast adresowanie i stan filtrowania, które nie miały nic wspólnego z usterką.

Etap trzeci: tożsamość i autoryzacja

691 oznacza, że poświadczenia zostały odrzucone. 649 oznacza, że konto nie ma uprawnień do wybierania numeru, a 812 oznacza, że polityka dostępu zdalnego odrzuciła połączenie. To decyzje, nie awarie transportu, i klient może je tylko zgłosić.

Dowody są po drugiej stronie. Poproś operatora bramy o próbę w tym znaczniku czasu i politykę, która pasowała; zapytaj właściciela katalogu, czy konto ma uprawnienie do wybierania numeru i czy jest w grupie wymaganej przez politykę. Zmiana typu tunelu albo reinstalacja klienta nie może zmienić decyzji podjętej o tożsamości.

Użytecznym nawykiem na tym etapie jest wpisanie w zgłoszeniu dokładnego ciągu konta, wraz z ewentualnym prefiksem domeny. Zaskakująco wiele przypadków 691 to zapisane poświadczenia dla złej domeny, i widać to w ciągu konta, a nie w ustawieniach protokołu.

Etap czwarty: połączono, i nic nie działa

Połączenie może się zakończyć i nadal być bezużyteczne. Ma adres, klient zgłasza sukces, a każde żądanie aplikacji kończy się przekroczeniem czasu. Nic w oknie tego nie odzwierciedla i nie ma kodu do sprawdzenia. W tym momencie okno jest skończone, a użyteczne dowody są gdzie indziej.

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Jeśli brakuje trasy, serwer jej nie wypchnął albo klient ją porzucił. Jeśli trasa istnieje, a nazwa zawodzi, problemem jest rozwiązywanie nazw. Jeśli oba działają, a aplikacja nadal zawodzi, jesteś za tunelem i w konfiguracji samej aplikacji.

Utrzymuj zmiany na jednej warstwie na test. Każda edycja przed następną próbą staje się częścią kontekstu następnego kodu, a kod opisujący twoją ostatnią edycję jest gorszy niż brak kodu.

Jedna próba, jedna zmiana, jeden zapis

Niezależnie od etapu zapis powinien zawierać kod, komunikat, nazwę profilu, znacznik czasu i sieć, w której byłeś. Pięć pól i każde z nich już masz przed sobą w oknie albo w logu klienta. Ten zestaw jest dość mały, by wkleić go do zgłoszenia, i dość konkretny, by ktoś inny go odtworzył.

Następnie połóż ten znacznik czasu obok zapisu po drugiej stronie. Tabela u góry tej strony mówi, do którego etapu należy każda rozbieżność. Bez drugiego zapisu kod tylko zawęża poszukiwania; z nim etap jest rozstrzygnięty. To porównanie zmienia numer w diagnozę, a nie w domysł.

Ten nawyk obejmuje prawie każdą natywną awarię VPN w Windows, a żadna z gałęzi nie wymaga niczego reinstalować. Okno zawsze mówiło, którą masz; praca polega na odmowie traktowania ich wszystkich jako tego samego problemu.