Windows VPN-feil 720: adressepool eller klientbinding?
Feil 720 betyr at tilkoblingen aldri fikk en brukbar adresse. Skill feil på én vert fra feil på mange verter før du installerer en adapter på nytt.
Feil 720 vises etter at påloggingsinformasjonen er godtatt, og derfor sender den folk tilbake til passordfeltet. Tilkoblingen nådde punktet der en adresse forhandles, og fikk ingen. To svært ulike feil gir den samme dialogen: serveren hadde ingenting å dele ut, eller nettopp denne klienten kunne ikke fullføre forhandlingen. Å skille de to før man rører noe, er det meste av reparasjonen, og skillet er dokumentert på Microsofts feilsøkingsside for feil 720.
Hva dialogen utelater
Meldingen beskriver en feil i PPP-forhandlingen, og den er bevisst vag fordi klienten ikke kan se hvorfor serveren avviste. Det er ikke en påloggingsfeil, og det er ikke en uttalelse om tunnelens kryptering. Det betyr at adressen eller forhandlingsparameterne ikke ble levert.
På serversiden er den vanlige årsaken tildeling: en statisk RRAS-pool uten ledige adresser eller en DHCP-konfigurasjon der omfanget er brukt opp eller utilgjengelig, gir nøyaktig dette symptomet hos hver klient som prøver. På klientsiden er den vanlige årsaken en binding. WAN Miniport-en som bærer PPP, må være bundet til de riktige komponentene, og en deaktivert binding eller et innsatt nettverksfilter kan stoppe forhandlingen uten noe synlig enhetsproblem. De to familiene trenger ulike bevis, og den raskeste måten å velge mellom dem på er å telle hvor mange klienter som er rammet.
Del populasjonen før poolen
Tell de rammede klientene før du leser noen konfigurasjon. En feil som rammer alle samtidig, er en servertilstand, og en feil som følger én maskin på tvers av nettverk, er en klienttilstand. Den tellingen koster én melding i en chatkanal og sparer en ettermiddag.
| 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 |
Korreler deretter ett mislykket forsøk med serverens egen logg, fordi RRAS logger en hendelse når den ikke kan tildele, og den hendelsen navngir feilen i stedet for symptomet. Følger feilen en bestemt klient, vil serverloggen ikke vise noe for det forsøket, noe som i seg selv er informativt. Fraværet av en tildelingsfeil begrenser problemet til forhandlingen på den klienten og forteller deg hvilke kommandoer du skal kjøre neste gang.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Les serverens tildelingstilstand
Bekreft på RRAS-siden hvilken tildelingsmetode som faktisk er konfigurert, og ikke hvilken dokumentasjonen forutsetter. En statisk pool og en DHCP-videresendt konfigurasjon feiler på ulike måter, og rettelsen hører til den som er i bruk. Tell de ledige adressene i en statisk pool, og se etter tildelinger per bruker som holder en lease som ingen husker, fordi en pool som ser stor ut, kan være fullt opptatt. Kontroller for DHCP at reléet når en server, og at omfanget har ledige leases.
Et omfang som er brukt opp av vanlige klienter, gir den samme 720 som en feilkonfigurert pool, og RRAS-konsollen vil se helt frisk ut i begge tilfeller. Motstå den nedarvede workarounden med å dele en pool i mindre områder: det opprinnelige rådet beskrev én administrators resultat, og det reparerer ikke en tildelingsfeil som serverens egne hendelser kan navngi direkte.
Les klientens bindinger uten å ødelegge dem
Hvis bevisene peker på én klient, undersøk den skjulte adapteren i stedet for å installere stakken på nytt. Den første kommandoen viser WAN Miniport-grensesnittene og navnene deres; den andre tar navnet den returnerte, ikke et navn kopiert fra en veiledning.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLes listen etter adresseoppløsningsbindingen og etter tredjepartsfiltre. En deaktivert binding er en målrettet reparasjon, mens et filters tilstedeværelse er et spørsmål for eieren av den programvaren og ikke tillatelse til å deaktivere et sikkerhetsprodukt. Å slette alle adaptere er det ene trekket som ødelegger bevisene du ville trengt hvis feilen kommer tilbake.
Etter rettelsen, prøv den samme profilen igjen og gjenta deretter toklienttilfellet hvis det var det opprinnelige symptomet, fordi en vellykket første tilkobling skjuler tildelingsproblemet som en andre klient avdekker. Hold notatet på fire felt: hvilken klient, hvilken binding, hvilken hendelse og hva som ble endret. Endre også ett lag per forsøk, siden en klientrettelse og en poolendring sammen ikke kan tilskrives, og den neste feilen vil se ny ut når det er den samme.