Error 720 de VPN a Windows: grup d'adreces o enllaç del client?
L'error 720 significa que la connexió mai no va rebre una adreça utilitzable. Separeu les fallades d'un sol host de les fallades de molts hosts abans de reinstal·lar un adaptador.
L'error 720 apareix després que s'acceptin les credencials, i per això torna la gent al camp de la contrasenya. La connexió va arribar al punt en què es negocia una adreça i no en va obtenir cap. Dues fallades molt diferents produeixen aquest mateix diàleg: el servidor no tenia res per repartir, o aquest client concret no va poder completar la negociació. Separar aquestes dues abans de tocar res és la major part de la reparació, i la distinció està documentada a la pàgina de resolució de problemes de Microsoft sobre l'error 720.
Què omet el diàleg
El missatge descriu una fallada en la negociació PPP, i és deliberadament vague perquè el client no pot veure per què el servidor va rebutjar. No és un error de credencials, ni una afirmació sobre el xifratge del túnel. Significa que no s'han lliurat l'adreça ni els paràmetres de negociació.
Pel costat del servidor, la causa habitual és l'assignació: un grup estàtic de RRAS sense adreces lliures, o una configuració DHCP l'àmbit de la qual està esgotat o és inabastable, produeix exactament aquest símptoma a tots els clients que ho proven. Pel costat del client, la causa habitual és un enllaç. El WAN Miniport que transporta PPP ha d'estar enllaçat amb els components correctes, i un enllaç deshabilitat o un filtre de xarxa inserit pot aturar la negociació sense cap problema visible al dispositiu. Les dues famílies necessiten proves diferents, i la manera més ràpida de triar entre elles és comptar quants clients estan afectats.
Separeu la població abans del grup
Compteu els clients afectats abans de llegir cap configuració. Una fallada que colpeja tothom alhora és una condició del servidor, i una fallada que segueix una màquina entre xarxes és una condició del client. Aquest recompte costa un missatge en un canal de xat i estalvia una tarda.
| 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 |
Després relacioneu un intent fallit amb el propi registre del servidor, perquè RRAS registra un esdeveniment quan no pot assignar i aquest esdeveniment anomena la fallada en lloc del símptoma. Si la fallada segueix un client concret, el registre del servidor no mostrarà res per a aquest intent, cosa que ja és informativa. L'absència d'un error d'assignació redueix el problema a la negociació d'aquell client i us diu quines ordres executar després.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Llegiu l'estat d'assignació del servidor
Pel costat de RRAS, confirmeu quin mètode d'assignació està realment configurat i no quin suposa la documentació. Un grup estàtic i una configuració retransmesa per DHCP fallen de maneres diferents, i la solució correspon al que estigui en ús. En un grup estàtic, compteu les adreces lliures i busqueu assignacions per usuari que mantinguin una concessió que ningú no recorda haver fet, perquè un grup que sembla gran pot estar completament compromès. En DHCP, comproveu que el repetidor arriba a un servidor i que l'àmbit té concessions lliures.
Un àmbit esgotat per clients normals produeix el mateix 720 que un grup mal configurat, i la consola de RRAS semblarà perfectament sana en tots dos casos. Resistiu la solució heretada de dividir un grup en rangs més petits: el consell original descrivia el resultat d'un administrador, i no repara una fallada d'assignació que els propis esdeveniments del servidor poden anomenar directament.
Llegiu els enllaços del client sense trencar-los
Si les proves apunten a un client, inspeccioneu l'adaptador ocult en lloc de reinstal·lar la pila. La primera ordre llista les interfícies WAN Miniport i els seus noms; la segona pren el nom que va retornar, no un nom copiat d'una guia.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLlegiu la llista per a l'enllaç de resolució d'adreces i per als filtres de tercers. Un enllaç deshabilitat és una reparació dirigida, mentre que la presència d'un filtre és una pregunta per al propietari d'aquell programari i no un permís per desactivar un producte de seguretat. Esborrar tots els adaptadors és l'únic moviment que destrueix les proves que necessitaríeu si la fallada tornés.
Després de la correcció, torneu a provar el mateix perfil i després repetiu el cas de dos clients si aquest era el símptoma original, perquè una primera connexió correcta amaga el problema d'assignació que exposa un segon client. Manteniu la nota en quatre camps: quin client, quin enllaç, quin esdeveniment i què va canviar. Canvieu també una capa per intent, ja que una correcció del client i un canvi del grup aplicats junts no es poden atribuir, i la propera fallada semblarà nova quan sigui la mateixa.