Erro 868 com um endereço IP? O que o Windows resolve primeiro

A caixa de diálogo informa que o nome do servidor não pôde ser resolvido, e o campo do perfil que você está encarando é um endereço. Essa combinação não é uma contradição: o cliente está resolvendo algo diferente do valor que você acha que ele lê. Descubra para onde ele disca de fato antes de concluir que o DNS está quebrado. A ordem das etapas do próprio cliente mostra onde você deve olhar.

O cliente resolve um nome antes de discar

Uma conexão VPN nativa do Windows lê o perfil, resolve o endereço do servidor, inicia o túnel e só então autentica. O erro 868 pertence à segunda etapa. Como as etapas seguintes nunca são executadas, a caixa de diálogo pode parecer um problema de credenciais quando a pesquisa falhou primeiro.

Essa ordem é útil porque restringe a camada a inspecionar. Quando o mesmo perfil funciona a partir de uma rede e falha a partir de outra, a diferença costuma ser a resolução de nomes e não o tipo de túnel ou a conta. Teste a pesquisa onde a falha ocorre, não onde o perfil foi criado.

Qual nome, quando o campo mostra um endereço

Leia o valor armazenado em vez do nome exibido. O rótulo de uma conexão não é o endereço do servidor, e duas entradas com rótulos parecidos mandam você atrás da errada:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

Se o perfil foi provisionado para todos os usuários, consulte também esse escopo com -AllUserConnection. Depois, resolva exatamente o valor que o comando imprimiu, a partir da rede onde a falha ocorre. Use o gateway documentado pela operadora, não o nome interno do aplicativo que só é resolvido depois que o túnel sobe. Essa segunda consulta falha por um motivo esperado e não lhe diz nada sobre a discagem:

Resolve-DnsName vpn.example.com

Quando o valor armazenado é realmente numérico, procure um segundo lugar em que o cliente leia um nome. Uma configuração EAP pode referenciar um servidor, um perfil importado de outra ferramenta pode trazer o próprio valor, e um instalador anterior pode deixar uma entrada duplicada. O campo da caixa de diálogo não é sempre a única entrada.

O padrão de reconexão do Windows 7

O tópico por trás deste erro descreve máquinas que se conectaram uma vez e depois falharam numa tentativa posterior com 868, sem que nada mudasse no perfil. Colaboradores relataram que reiniciar o serviço Remote Access Connection Manager ou sair e entrar novamente restaurava a conexão temporariamente. São contornos, não uma causa raiz demonstrada.

Trate esse padrão como uma hipótese separada. Uma reinicialização redefine o estado do cliente, então um sucesso temporário depois disso não prova que o registro DNS estava errado:

Leia a tabela como um conjunto de observações que distinguem, não como um diagnóstico. A primeira linha é um problema de nome, a segunda é o estado do cliente e a terceira é um perfil que nunca esteve correto. Cada uma leva a uma pessoa diferente e a uma correção diferente.

O que coletar para o administrador

Anote o nome do perfil, o endereço armazenado, o tipo de túnel, a rede em que o cliente estava e se a falha veio depois de uma desconexão. Esse registro separa uma falha real de pesquisa do comportamento histórico de reconexão sem que ninguém precise adivinhar. Guarde também o log de eventos do cliente em torno da tentativa.

O contorno das versões mais antigas é evidência de que o comportamento existia, não uma promessa de que o mesmo reinício do serviço consertará uma máquina atual. Substituir um nome de host documentado por um endereço literal também não é um reparo.

Alguns perfis esperam uma identidade de servidor que corresponda ao nome configurado, então um contorno numérico pode trocar um erro por outro. Se o nome precisar ficar, corrija o caminho de resolução e não o texto do perfil. De qualquer forma, registre o que você mudou e por quê.