Windows VPN-fel 720: adresspool eller klientbindning?
Fel 720 betyder att anslutningen aldrig fick en användbar adress. Skilj fel på en värd från fel på många värdar innan du installerar om en adapter.
Fel 720 visas efter att inloggningsuppgifterna har godkänts, och därför skickar det folk tillbaka till lösenordsfältet. Anslutningen nådde punkten där en adress förhandlas och fick ingen. Två helt olika fel ger samma dialogruta: servern hade inget att dela ut, eller just den här klienten kunde inte slutföra förhandlingen. Att skilja de två åt innan man rör något är det mesta av reparationen, och uppdelningen finns dokumenterad på Microsofts felsökningssida för fel 720.
Vad dialogrutan utelämnar
Meddelandet beskriver ett fel i PPP-förhandlingen, och det är medvetet vagt eftersom klienten inte kan se varför servern avvisade. Det är inte ett inloggningsfel, och det är inte ett uttalande om tunnelns kryptering. Det betyder att adressen eller förhandlingsparametrarna inte levererades.
På serversidan är den vanliga orsaken tilldelning: en statisk RRAS-pool utan lediga adresser eller en DHCP-konfiguration vars omfång är uttömt eller oåtkomligt ger exakt detta symptom hos varje klient som försöker. På klientsidan är den vanliga orsaken en bindning. Den WAN Miniport som bär PPP måste vara bunden till rätt komponenter, och en inaktiverad bindning eller ett insatt nätverksfilter kan stoppa förhandlingen utan något synligt enhetsproblem. De två familjerna behöver olika bevis, och det snabbaste sättet att välja mellan dem är att räkna hur många klienter som drabbas.
Dela upp populationen före poolen
Räkna de drabbade klienterna innan du läser någon konfiguration. Ett fel som drabbar alla på en gång är ett servertillstånd, och ett fel som följer en maskin mellan nätverk är ett klienttillstånd. Den räkningen kostar ett meddelande i en chattkanal och sparar 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 |
Korrelera sedan ett misslyckat försök med serverns egen logg, eftersom RRAS loggar en händelse när den inte kan tilldela och den händelsen namnger felet i stället för symptomet. Följer felet en viss klient visar serverloggen inget för det försöket, vilket i sig är informativt. Avsaknaden av ett tilldelningsfel begränsar problemet till förhandlingen på den klienten och talar om vilka kommandon du ska köra härnäst.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Läs serverns tilldelningstillstånd
Bekräfta på RRAS-sidan vilken tilldelningsmetod som faktiskt är konfigurerad och inte vilken dokumentationen antar. En statisk pool och en DHCP-vidarebefordrad konfiguration misslyckas på olika sätt, och åtgärden hör till den som används. Räkna de lediga adresserna i en statisk pool och leta efter tilldelningar per användare som håller en lease som ingen minns, eftersom en pool som ser stor ut kan vara fullt upptagen. Kontrollera för DHCP att reläet når en server och att omfånget har lediga leases.
Ett omfång som tömts av vanliga klienter ger samma 720 som en felkonfigurerad pool, och RRAS-konsolen ser helt frisk ut i båda fallen. Stå emot den ärvda workarounden att dela upp en pool i mindre intervall: det ursprungliga rådet beskrev en administratörs resultat, och det reparerar inte ett tilldelningsfel som serverns egna händelser kan namnge direkt.
Läs klientens bindningar utan att bryta dem
Om bevisen pekar på en klient, undersök den dolda adaptern i stället för att installera om stacken. Det första kommandot listar WAN Miniport-gränssnitten och deras namn; det andra tar det namn det returnerade, inte ett namn kopierat från en guide.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLäs listan efter adressupplösningsbindningen och efter tredjepartsfilter. En inaktiverad bindning är en riktad reparation, medan ett filters närvaro är en fråga för ägaren av den programvaran och inte tillstånd att inaktivera en säkerhetsprodukt. Att radera alla adaptrar är det enda draget som förstör de bevis du skulle behöva om felet återkommer.
Efter rättelsen, prova samma profil igen och upprepa sedan tvåklientfallet om det var det ursprungliga symptomet, eftersom en lyckad första anslutning döljer det tilldelningsproblem som en andra klient avslöjar. Håll anteckningen till fyra fält: vilken klient, vilken bindning, vilken händelse och vad som ändrades. Ändra också ett lager per försök, eftersom en klienträttelse och en pooländring tillsammans inte kan tillskrivas, och nästa fel kommer att se nytt ut när det är samma.