Erro 720 da VPN de Windows: conxunto de enderezos ou vinculación do cliente?
O erro 720 significa que a conexión nunca recibiu un enderezo utilizábel. Separe os fallos dun só host dos fallos de moitos hosts antes de reinstalar un adaptador.
O erro 720 aparece despois de que se acepten as credenciais, e por iso devolve a xente ao campo do contrasinal. A conexión chegou ao punto no que se negocia un enderezo e non obtivo ningún. Dous fallos moi distintos producen ese mesmo diálogo: o servidor non tiña nada que repartir, ou este cliente concreto non puido completar a negociación. Separar eses dous antes de tocar nada é a maior parte da reparación, e a distinción está documentada na páxina de solución de problemas de Microsoft sobre o erro 720.
O que o diálogo omite
A mensaxe describe un fallo na negociación PPP, e é deliberadamente vaga porque o cliente non pode ver por que rexeitou o servidor. Non é un erro de credenciais, nin unha afirmación sobre o cifrado do túnel. Significa que non se entregaron o enderezo nin os parámetros de negociación.
Do lado do servidor, a causa habitual é a asignación: un conxunto estático de RRAS sen enderezos libres, ou unha configuración DHCP cuxo ámbito está esgotado ou é inalcanzable, produce exactamente este síntoma en todos os clientes que o intentan. Do lado do cliente, a causa habitual é unha vinculación. O WAN Miniport que transporta PPP debe estar vinculado aos compoñentes correctos, e unha vinculación desactivada ou un filtro de rede inserido pode deter a negociación sen ningún problema visible no dispositivo. As dúas familias necesitan probas distintas, e a forma máis rápida de escoller entre elas é contar cantos clientes están afectados.
Separe a poboación antes do conxunto
Conte os clientes afectados antes de ler calquera configuración. Un fallo que golpea a todos á vez é unha condición do servidor, e un fallo que segue unha máquina entre redes é unha condición do cliente. Ese reconto custa unha mensaxe nunha canle de chat e aforra unha tarde.
| 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 |
Despois relacione un intento fallido co propio rexistro do servidor, porque RRAS rexistra un evento cando non pode asignar e ese evento nomea o fallo en lugar do síntoma. Se o fallo segue un cliente concreto, o rexistro do servidor non mostrará nada para ese intento, o cal é informativo en si mesmo. A ausencia dun erro de asignación reduce o problema á negociación dese cliente e di que comandos executar despois.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Lea o estado de asignación do servidor
Do lado de RRAS, confirme que método de asignación está configurado realmente e non cal supón a documentación. Un conxunto estático e unha configuración retransmitida por DHCP fallan de formas distintas, e a solución corresponde ao que estea en uso. Nun conxunto estático, conte os enderezos libres e busque asignacións por usuario que manteñan unha concesión que ninguén lembra facer, porque un conxunto que parece grande pode estar totalmente comprometido. En DHCP, comprobe que o repetidor chega a un servidor e que o ámbito ten concesións libres.
Un ámbito esgotado por clientes normais produce o mesmo 720 que un conxunto mal configurado, e a consola de RRAS parecerá perfectamente sa en ambos os casos. Resista a solución herdada de dividir un conxunto en rangos máis pequenos: o consello orixinal describía o resultado dun administrador, e non repara un fallo de asignación que os propios eventos do servidor poden nomear directamente.
Lea as vinculacións do cliente sen rompelas
Se as probas apuntan a un cliente, inspeccione o adaptador oculto en lugar de reinstalar a pila. O primeiro comando enumera as interfaces WAN Miniport e os seus nomes; o segundo toma o nome que devolveu, non un nome copiado dunha guía.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLea a lista en busca da vinculación de resolución de enderezos e de filtros de terceiros. Unha vinculación desactivada é unha reparación dirixida, mentres que a presenza dun filtro é unha pregunta para o propietario dese software e non un permiso para desactivar un produto de seguridade. Borrar todos os adaptadores é o único movemento que destrúe as probas que necesitaría se o fallo volve.
Tras a corrección, reintente o mesmo perfil e despois repita o caso de dous clientes se ese era o síntoma orixinal, porque unha primeira conexión correcta oculta o problema de asignación que expón un segundo cliente. Manteña a nota en catro campos: que cliente, que vinculación, que evento e que cambiou. Cambie tamén unha capa por intento, xa que unha corrección do cliente e un cambio do conxunto aplicados xuntos non se poden atribuír, e o seguinte fallo parecerá novo cando sexa o mesmo.