Windows VPN-fejl 720: adressepulje eller klientbinding?
Fejl 720 betyder, at forbindelsen aldrig fik en brugbar adresse. Adskil fejl på én vært fra fejl på mange værter, før du geninstallerer en adapter.
Fejl 720 vises, efter at legitimationsoplysningerne er accepteret, og derfor sender den folk tilbage til adgangskodefeltet. Forbindelsen nåede det punkt, hvor en adresse forhandles, og fik ingen. To meget forskellige fejl giver den samme dialog: serveren havde intet at uddele, eller netop denne klient kunne ikke gennemføre forhandlingen. At skelne de to, før man rører noget, er det meste af reparationen, og opdelingen er dokumenteret på Microsofts fejlfindingsside for fejl 720.
Hvad dialogen udelader
Meddelelsen beskriver en fejl i PPP-forhandlingen, og den er bevidst vag, fordi klienten ikke kan se, hvorfor serveren afviste. Det er ikke en legitimationsfejl, og det er ikke en udtalelse om tunnelens kryptering. Det betyder, at adressen eller forhandlingsparametrene ikke blev leveret.
På serversiden er den sædvanlige årsag tildeling: en statisk RRAS-pulje uden frie adresser eller en DHCP-konfiguration, hvis område er udtømt eller utilgængeligt, giver præcis dette symptom hos enhver klient, der prøver. På klientsiden er den sædvanlige årsag en binding. Den WAN Miniport, der bærer PPP, skal være bundet til de rigtige komponenter, og en deaktiveret binding eller et indsat netværksfilter kan stoppe forhandlingen uden et synligt enhedsproblem. De to familier har brug for forskellige beviser, og den hurtigste måde at vælge mellem dem er at tælle, hvor mange klienter der er ramt.
Del populationen, før du ser på puljen
Tæl de ramte klienter, før du læser nogen konfiguration. En fejl, der rammer alle på én gang, er en servertilstand, og en fejl, der følger én maskine på tværs af netværk, er en klienttilstand. Den optælling koster én besked i en chatkanal og sparer en eftermiddag.
| 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 |
Korrelér derefter ét mislykket forsøg med serverens egen log, fordi RRAS logger en hændelse, når den ikke kan tildele, og den hændelse navngiver fejlen i stedet for symptomet. Følger fejlen en bestemt klient, vil serverloggen intet vise for det forsøg, hvilket i sig selv er informativt. Fraværet af en tildelingsfejl indsnævrer problemet til forhandlingen på den klient og fortæller dig, hvilke kommandoer du skal køre næste gang.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Læs serverens tildelingstilstand
Bekræft på RRAS-siden, hvilken tildelingsmetode der faktisk er konfigureret, og ikke hvilken dokumentationen antager. En statisk pulje og en DHCP-videresendt konfiguration fejler på forskellige måder, og rettelsen hører til den, der er i brug. Tæl de frie adresser i en statisk pulje, og se efter tildelinger pr. bruger, der holder en lease, som ingen husker, fordi en pulje, der ser stor ud, kan være fuldt optaget. Kontroller for DHCP, at relayet når en server, og at området har frie leases.
Et område, der er udtømt af almindelige klienter, giver den samme 720 som en forkert konfigureret pulje, og RRAS-konsollen vil se helt sund ud i begge tilfælde. Modstå den nedarvede workaround at dele en pulje op i mindre intervaller: det oprindelige råd beskrev én administrators resultat, og det reparerer ikke en tildelingsfejl, som serverens egne hændelser kan navngive direkte.
Læs klientens bindinger uden at ødelægge dem
Hvis beviserne peger på én klient, skal du undersøge den skjulte adapter i stedet for at geninstallere stakken. Den første kommando viser WAN Miniport-grænsefladerne og deres navne; den anden bruger det navn, den returnerede, ikke et navn kopieret fra en vejledning.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLæs listen for adresseopløsningsbindingen og for tredjepartsfiltre. En deaktiveret binding er en målrettet reparation, mens et filters tilstedeværelse er et spørgsmål til ejeren af den software og ikke tilladelse til at deaktivere et sikkerhedsprodukt. At slette alle adaptere er det ene træk, der ødelægger de beviser, du ville få brug for, hvis fejlen vender tilbage.
Efter rettelsen skal du prøve den samme profil igen og derefter gentage toklienttilfældet, hvis det var det oprindelige symptom, fordi en vellykket første forbindelse skjuler det tildelingsproblem, som en anden klient afslører. Hold noten på fire felter: hvilken klient, hvilken binding, hvilken hændelse og hvad der blev ændret. Ændr også ét lag pr. forsøg, da en klientrettelse og en puljeændring sammen ikke kan tilskrives, og den næste fejl vil se ny ud, når det er den samme.