Windows-VPN-fout 720: adrespool of clientbinding?
Fout 720 betekent dat de verbinding nooit een bruikbaar adres heeft gekregen. Scheid fouten op één host van fouten op veel hosts voordat u een adapter opnieuw installeert.
Fout 720 verschijnt nadat de inloggegevens zijn geaccepteerd, en daarom stuurt hij mensen terug naar het wachtwoordveld. De verbinding bereikte het punt waarop een adres wordt onderhandeld en kreeg er geen. Twee heel verschillende storingen leveren datzelfde venster op: de server had niets uit te delen, of juist deze client kon de onderhandeling niet afronden. Die twee scheiden voordat je iets aanraakt is het grootste deel van de reparatie, en de splitsing staat gedocumenteerd op Microsofts pagina over probleemoplossing voor fout 720.
Wat het venster weglaat
Het bericht beschrijft een fout in de PPP-onderhandeling, en het is bewust vaag omdat de client niet kan zien waarom de server weigerde. Het is geen fout in de inloggegevens, en het is geen uitspraak over de versleuteling van de tunnel. Het betekent dat het adres of de onderhandelingsparameters niet zijn geleverd.
Aan de serverkant is de gebruikelijke oorzaak toewijzing: een statische RRAS-pool zonder vrije adressen, of een DHCP-configuratie waarvan het bereik uitgeput of onbereikbaar is, levert precies dit symptoom bij elke client die het probeert. Aan de clientkant is de gebruikelijke oorzaak een binding. De WAN Miniport die PPP draagt moet aan de juiste onderdelen gebonden zijn, en een uitgeschakelde binding of een ingevoegd netwerkfilter kan de onderhandeling stoppen zonder enig zichtbaar apparaatprobleem. De twee families vragen verschillend bewijs, en de snelste manier om tussen hen te kiezen is tellen hoeveel clients getroffen zijn.
Eerst de populatie, dan de pool
Tel de getroffen clients voordat je enige configuratie leest. Een storing die iedereen tegelijk treft is een serverconditie, en een storing die één machine over netwerken heen volgt is een clientconditie. Die telling kost één bericht in een chatkanaal en bespaart een middag.
| 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 |
Koppel dan één mislukte poging aan het eigen record van de server, want RRAS logt een gebeurtenis wanneer het niet kan toewijzen en die gebeurtenis noemt de storing in plaats van het symptoom. Volgt de storing één specifieke client, dan toont het serverlog voor die poging niets, wat op zichzelf informatief is. Het ontbreken van een toewijzingsfout beperkt het probleem tot de onderhandeling op die client en vertelt je welke commando's je hierna moet uitvoeren.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }De toewijzingsstatus van de server lezen
Bevestig aan de RRAS-kant welke toewijzingsmethode werkelijk is geconfigureerd en niet welke de documentatie veronderstelt. Een statische pool en een DHCP-doorgestuurde configuratie falen op verschillende manieren, en de oplossing hoort bij degene die in gebruik is. Tel bij een statische pool de vrije adressen en zoek naar toewijzingen per gebruiker die een lease vasthouden die niemand zich herinnert, want een pool die groot lijkt kan volledig bezet zijn. Controleer bij DHCP of de relay een server bereikt en of het bereik vrije leases heeft.
Een bereik dat door gewone clients is uitgeput levert dezelfde 720 op als een verkeerd geconfigureerde pool, en de RRAS-console ziet er in beide gevallen volkomen gezond uit. Weersta de overgenomen workaround om een pool in kleinere bereiken te splitsen: het oorspronkelijke advies beschreef het resultaat van één beheerder, en het repareert geen toewijzingsfout die de gebeurtenissen van de server zelf direct kunnen benoemen.
De bindingen van de client lezen zonder ze te breken
Wijzen de bewijzen op één client, inspecteer dan de verborgen adapter in plaats van de stack opnieuw te installeren. Het eerste commando somt de WAN Miniport-interfaces en hun namen op; het tweede neemt de naam die het teruggaf, niet een naam uit een handleiding.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLees de lijst op de adresresolutiebinding en op filters van derden. Een uitgeschakelde binding is een gerichte reparatie, terwijl de aanwezigheid van een filter een vraag is voor de eigenaar van die software en geen toestemming om een beveiligingsproduct uit te schakelen. Elke adapter verwijderen is de enige stap die het bewijs vernietigt dat je nodig hebt als de storing terugkeert.
Probeer na de correctie hetzelfde profiel opnieuw en herhaal dan het geval met twee clients als dat het oorspronkelijke symptoom was, want een geslaagde eerste verbinding verbergt het toewijzingsprobleem dat een tweede client blootlegt. Houd de notitie op vier velden: welke client, welke binding, welke gebeurtenis en wat er veranderd is. Wijzig ook per poging één laag, want een clientoplossing en een poolwijziging samen zijn niet toe te schrijven, en de volgende fout zal nieuw lijken terwijl het dezelfde is.