Błąd 720 VPN w Windows: pula adresów czy powiązanie klienta?
Błąd 720 oznacza, że połączenie nigdy nie otrzymało użytecznego adresu. Oddziel awarie na jednym hoście od awarii na wielu hostach, zanim ponownie zainstalujesz adapter.
Błąd 720 pojawia się po zaakceptowaniu poświadczeń, dlatego odsyła ludzi do pola hasła. Połączenie dotarło do punktu negocjacji adresu i nie otrzymało go. Dwie bardzo różne awarie dają to samo okno: serwer nie miał nic do rozdania albo ten konkretny klient nie zdołał dokończyć negocjacji. Rozdzielenie tych dwóch przed dotknięciem czegokolwiek to większość naprawy, a podział jest udokumentowany na stronie rozwiązywania problemów Microsoftu dotyczącej błędu 720.
Czego okno dialogowe nie mówi
Komunikat opisuje awarię negocjacji PPP i jest celowo nieprecyzyjny, ponieważ klient nie widzi, dlaczego serwer odmówił. To nie jest błąd poświadczeń ani stwierdzenie o szyfrowaniu tunelu. Oznacza, że adres lub parametry negocjacji nie zostały dostarczone.
Po stronie serwera zwykłą przyczyną jest alokacja: statyczna pula RRAS bez wolnych adresów albo konfiguracja DHCP, której zakres jest wyczerpany lub nieosiągalny, daje dokładnie ten objaw u każdego klienta, który próbuje. Po stronie klienta zwykłą przyczyną jest powiązanie. WAN Miniport przenoszący PPP musi być powiązany z właściwymi składnikami, a wyłączone powiązanie lub wstawiony filtr sieciowy może zatrzymać negocjację bez żadnego widocznego problemu urządzenia. Obie rodziny wymagają innych dowodów, a najszybszym sposobem wyboru między nimi jest policzenie, ilu klientów jest dotkniętych.
Najpierw podziel populację, potem pulę
Policz dotkniętych klientów, zanim przeczytasz jakąkolwiek konfigurację. Awaria, która dotyka wszystkich naraz, jest stanem serwera, a awaria, która podąża za jedną maszyną między sieciami, jest stanem klienta. To liczenie kosztuje jedną wiadomość na kanale czatu i oszczędza popołudnie.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
Następnie skoreluj jedną nieudaną próbę z własnym zapisem serwera, ponieważ RRAS rejestruje zdarzenie, gdy nie może przydzielić adresu, a to zdarzenie nazywa awarię, a nie objaw. Jeśli awaria dotyczy konkretnego klienta, dziennik serwera nie pokaże nic dla tej próby, co samo w sobie jest informacyjne. Brak błędu alokacji zawęża problem do negocjacji na tym kliencie i mówi, które polecenia uruchomić dalej.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Odczytaj stan alokacji serwera
Po stronie RRAS potwierdź, która metoda alokacji jest faktycznie skonfigurowana, a nie która zakłada dokumentacja. Statyczna pula i konfiguracja przekazywana przez DHCP zawodzą na różne sposoby, a poprawka należy do tej, która jest w użyciu. W przypadku puli statycznej policz wolne adresy i poszukaj przypisań na użytkownika, które utrzymują dzierżawę, o której nikt nie pamięta, ponieważ pula, która wygląda na dużą, może być w pełni zajęta. W przypadku DHCP sprawdź, czy przekazywanie dociera do serwera i czy zakres ma wolne dzierżawy.
Zakres wyczerpany przez zwykłych klientów daje ten sam 720 co błędnie skonfigurowana pula, a konsola RRAS będzie wyglądać całkowicie zdrowo w obu przypadkach. Oprzyj się odziedziczonemu obejściu polegającemu na dzieleniu puli na mniejsze zakresy: pierwotna rada opisywała wynik jednego administratora i nie naprawia awarii alokacji, którą zdarzenia samego serwera mogą nazwać bezpośrednio.
Odczytaj powiązania klienta, nie niszcząc ich
Jeśli dowody wskazują na jednego klienta, sprawdź ukryty adapter, zamiast reinstalować stos. Pierwsze polecenie wyświetla interfejsy WAN Miniport i ich nazwy; drugie przyjmuje nazwę, którą zwróciło, a nie nazwę skopiowaną z poradnika.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsPrzeczytaj listę pod kątem powiązania rozpoznawania adresów i filtrów innych firm. Wyłączone powiązanie to ukierunkowana naprawa, natomiast obecność filtra to pytanie do właściciela tego oprogramowania, a nie zgoda na wyłączenie produktu zabezpieczającego. Usunięcie wszystkich adapterów to jedyny ruch, który niszczy dowody potrzebne, gdyby awaria wróciła.
Po poprawce ponów tę samą konfigurację, a następnie powtórz przypadek dwóch klientów, jeśli to był pierwotny objaw, ponieważ udane pierwsze połączenie ukrywa problem alokacji, który ujawnia drugi klient. Trzymaj notatkę w czterech polach: który klient, które powiązanie, które zdarzenie i co się zmieniło. Zmieniaj też jedną warstwę na próbę, ponieważ poprawki klienta i zmiany puli zastosowane razem nie można przypisać, a następna awaria będzie wyglądać na nową, choć będzie tą samą.