Erro 720 da VPN do Windows: pool de endereços ou vínculo do cliente?
O erro 720 significa que a conexão nunca recebeu um endereço utilizável. Separe falhas de um único host das falhas de muitos hosts antes de reinstalar um adaptador.
O erro 720 aparece depois que as credenciais são aceitas, e é por isso que devolve as pessoas ao campo da senha. A conexão chegou ao ponto em que um endereço é negociado e não recebeu nenhum. Duas falhas muito diferentes produzem essa mesma caixa de diálogo: o servidor não tinha nada para distribuir, ou este cliente específico não conseguiu concluir a negociação. Separar as duas antes de tocar em qualquer coisa é a maior parte do reparo, e a distinção está documentada na página de solução de problemas da Microsoft sobre o erro 720.
O que a caixa de diálogo omite
A mensagem descreve uma falha na negociação PPP, e é deliberadamente vaga porque o cliente não consegue ver por que o servidor recusou. Não é um erro de credenciais, nem uma afirmação sobre a criptografia do túnel. Significa que o endereço ou os parâmetros de negociação não foram entregues.
No lado do servidor, a causa habitual é a alocação: um pool estático do RRAS sem endereços livres, ou uma configuração DHCP cujo escopo está esgotado ou inacessível, produz exatamente esse sintoma em todo cliente que tenta. No lado do cliente, a causa habitual é um vínculo. O WAN Miniport que transporta PPP precisa estar vinculado aos componentes corretos, e um vínculo desabilitado ou um filtro de rede inserido pode interromper a negociação sem nenhum problema visível no dispositivo. As duas famílias exigem evidências diferentes, e o modo mais rápido de escolher entre elas é contar quantos clientes são afetados.
Separe a população antes do pool
Conte os clientes afetados antes de ler qualquer configuração. Uma falha que atinge todos de uma vez é uma condição do servidor, e uma falha que acompanha uma máquina entre redes é uma condição do cliente. Essa contagem custa uma mensagem em um canal de chat e economiza uma 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 |
Depois correlacione uma tentativa malsucedida com o próprio registro do servidor, porque o RRAS registra um evento quando não consegue alocar e esse evento nomeia a falha em vez do sintoma. Se a falha acompanha um cliente específico, o log do servidor não mostrará nada para essa tentativa, o que é informativo por si só. A ausência de um erro de alocação restringe o problema à negociação naquele cliente e indica quais comandos executar em seguida.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }Leia o estado de alocação do servidor
No lado do RRAS, confirme qual método de alocação está realmente configurado e não qual a documentação supõe. Um pool estático e uma configuração retransmitida por DHCP falham de modos diferentes, e a correção pertence ao que estiver em uso. Num pool estático, conte os endereços livres e procure atribuições por usuário que mantêm uma concessão que ninguém lembra ter feito, porque um pool que parece grande pode estar totalmente comprometido. No DHCP, verifique se o relay alcança um servidor e se o escopo tem concessões livres.
Um escopo esgotado por clientes comuns produz o mesmo 720 que um pool mal configurado, e o console do RRAS parecerá perfeitamente saudável nos dois casos. Resista ao contorno herdado de dividir um pool em faixas menores: o conselho original descrevia o resultado de um administrador e não repara uma falha de alocação que os próprios eventos do servidor podem nomear diretamente.
Leia os vínculos do cliente sem quebrá-los
Se as evidências apontarem para um cliente, inspecione o adaptador oculto em vez de reinstalar a pilha. O primeiro comando lista as interfaces WAN Miniport e seus nomes; o segundo usa o nome que ele retornou, não um nome copiado de um guia.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsLeia a lista em busca do vínculo de resolução de endereços e de filtros de terceiros. Um vínculo desabilitado é um reparo direcionado, enquanto a presença de um filtro é uma pergunta para o dono desse software e não uma permissão para desativar um produto de segurança. Excluir todos os adaptadores é o único movimento que destrói as evidências de que você precisaria se a falha voltasse.
Após a correção, repita o mesmo perfil e depois repita o caso de dois clientes se esse era o sintoma original, porque uma primeira conexão bem-sucedida esconde o problema de alocação que um segundo cliente expõe. Mantenha a nota em quatro campos: qual cliente, qual vínculo, qual evento e o que mudou. Altere também uma camada por tentativa, já que uma correção no cliente e uma mudança no pool aplicadas juntas não podem ser atribuídas, e a próxima falha parecerá nova quando for a mesma.