Błąd L2TP/IPsec 789, 720 lub 691: najpierw napraw właściwy etap

Windows 11 zgłasza inny numer dla każdego etapu L2TP/IPsec, a ten numer oznacza etap, a nie ocenia awarii. 789 zawodzi, zanim istnieje łącze PPP, 720 zawodzi podczas podnoszenia łącza, a 691 zawodzi po podniesieniu łącza i odrzuceniu poświadczeń. Użyteczna decyzja to nie to, która poprawka jest najpopularniejsza, lecz to, który etap kod udowadnia, że osiągnąłeś. Przeczytaj to najpierw, a potem zmieniaj jedną warstwę na próbę, aby następny kod wciąż coś ci mówił.

Czytaj kod jako etap, a nie jako listę usterek

Połączenie L2TP przekracza trzy granice w ustalonej kolejności. IKE negocjuje asocjacje bezpieczeństwa przez UDP 500, przechodzenie NAT przenosi ten ruch na UDP 4500, i dopiero wtedy tunel L2TP przenosi sesję PPP, która uwierzytelnia użytkownika i przydziela adres.

Właśnie ta kolejność sprawia, że zmieniający się kod błędu jest użytecznym dowodem. Przejście z 789 na 720 oznacza, że IPsec już negocjuje, a awaria przeniosła się na zestawianie łącza. Przejście z 720 na 691 oznacza, że łącze stanęło, a brama odrzuciła tożsamość. Jeśli zastosujesz pięć poprawek naraz, tracisz ten sygnał i nie możesz powiedzieć, która zmiana zadziałała.

789: wybierz między ścieżką a polityką lokalną

Kod 789 to błąd przetwarzania podczas początkowych negocjacji bezpieczeństwa. IPsec nigdy nie utworzył użytecznej asocjacji, więc konto nie zostało jeszcze przetestowane. Zacznij od ścieżki i wspólnego klucza, a nie od konta.

Potwierdź, że UDP 500 i UDP 4500 docierają do serwera, a wstępnie udostępniony klucz zgadza się bajt po bajcie, łącznie z wielkością liter i spacjami na końcu. Jeśli serwer stoi za NAT, Windows może potrzebować także udokumentowanej wartości rejestru. Użyj 1, gdy serwer jest za NAT, i 2, gdy oba końce, a następnie uruchom ponownie, ponieważ agent zasad odczytuje wartość przy starcie:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

Cięższa naprawa adaptera należy do drugiej gałęzi. Usunięcie urządzenia Wi-Fi i miniportów WAN, a potem ponowne skanowanie sprzętu jest uzasadnione, gdy sam lokalny stos IPsec jest uszkodzony i inne typy VPN zawodzą w ten sam sposób. To zmarnowany wysiłek, gdy zawodzi tylko jeden serwer L2TP, a wszystkie inne ścieżki sieciowe działają.

720: wybierz między tym adapterem a pulą serwerów

Błąd 720 zgłasza, że nie udało się nawiązać połączenia ze zdalnym komputerem, i pojawia się po udanym IPsec. Tunel dotarł do punktu podniesienia interfejsu lub uzyskania adresu, a potem się zatrzymał. To czyni go kwestią lokalnego adaptera albo pojemności serwera.

Do decyzji użyj promienia wpływu. Awaria jednej maszyny z Windows wskazuje na wadliwy miniport WAN, zatrzymaną usługę Remote Access lub uszkodzony profil połączenia. Awaria kilku klientów jednocześnie wskazuje na serwer: wyczerpana pula adresów, zatrzymana usługa RRAS lub pula, która nie pasuje już do podsieci klienta. Napraw tę stronę, na którą wskazuje wzorzec, zanim zmienisz drugą.

W gałęzi jednego klienta usuń raz miniporty WAN i przeskanuj zmiany sprzętowe, a potem uruchom ponownie i spróbuj jeszcze raz. W gałęzi serwera sprawdź pulę i stan usługi, a nie klienta, ponieważ reinstalacja działającego adaptera nie może utworzyć adresu, którego serwer nie ma.

691: wybierz między poświadczeniem a zatrzymanym pomocnikiem

Kod 691 to odrzucenie uwierzytelnienia i jest to kod najczęściej błędnie odczytywany jako nieprawidłowe hasło. Tunel stoi, brama zobaczyła tożsamość i ją odrzuciła. Przyczyna wciąż może leżeć poza polem hasła.

Najpierw sprawdź pole domeny, potem dokładne znaki w haśle. Hasło zawierające spację, cudzysłów lub znak specjalny powłoki może zostać zniekształcone, zanim dotrze do serwera; w Linuksie pppd zgłasza to samo odrzucenie co E=691 dla wartości bez cudzysłowów lub brakującej domeny. Wpisz hasło ponownie zamiast je wklejać i usuń wszelkie zapisane poświadczenia, które mogą zawierać starszą wartość.

Gałąź, którą ludzie pomijają, to zatrzymana usługa pomocnicza. Gdy klient dostawcy zależy od własnej usługi, aby przekazać poświadczenia do bramy, wyłączona lub zawieszona usługa daje 691, nawet gdy hasło jest poprawne. Sprawdź stan usługi dostawcy przed zresetowaniem konta, zwłaszcza po ponownym uruchomieniu lub aktualizacji.

Aby rozdzielić gałęzie, przetestuj tę samą nazwę użytkownika na innym działającym profilu VPN lub testowym koncie RADIUS. Jeśli to się powiedzie, poświadczenie jest w porządku, a lokalna ścieżka klienta jest podejrzana. Jeśli zawiedzie w ten sam sposób, problemem jest konto lub zasady bramy.

Zmieniaj jedną warstwę na próbę

Pracuj od zewnątrz do wewnątrz: osiągalność i przechodzenie NAT, potem wstępnie udostępniony klucz, potem lokalny stos adaptera, potem poświadczenie, potem pula serwerów i usługi. Ta kolejność podąża za etapami opisanymi przez kody i pozwala przypisać każdy wynik do jednej zmiany.

Prowadź krótki dziennik kodu przed i po każdej próbie, kompilacji klienta i tego, czy zmieniono serwer, czy klienta. Sekwencja taka jak 789, potem 720, potem 691 jest mapą postępu; ten sam kod dwa razy oznacza, że ostatnia zmiana nie dotyczyła tego etapu. Reinstalacja Windows usuwa tę mapę i rzadko naprawia awarię, która mieszka na bramie.

Gdy kod przestaje się zmieniać, przestań zmieniać rzeczy. Zapisz bieżący kod, adres serwera, metodę uwierzytelniania i czas próby, a następnie porównaj ten zapis z działającym klientem. Różnica między dwoma zapisami jest zwykle mniejsza niż lista poprawek, które ludzie wypróbowują domyślnie.