Por que um nome de servidor se resolve no seu endereço VPN após a conexão discada

Um servidor de ficheiros de escritório responde no seu endereço de LAN durante toda a manhã, e depois um utilizador remoto liga-se por linha discada e o nome começa a resolver para um endereço de túnel. Nada foi editado no DNS à mão, e essa é a pista: o registo foi publicado pela própria máquina. Três condições decidem se corrige o registrador, o registo ou a visão do cliente, e errar a ordem faz com que o registo volte após a ligação seguinte.

Dois endereços, um nome, três condições

Um servidor Windows com várias interfaces pode ter um endereço de LAN, um ou mais endereços de ligação discada e, por vezes, uma segunda placa de rede. Cada interface pode registar os seus próprios endereços no DNS se o registo dinâmico lhe for permitido. Quando o adaptador PPP se registra, o mesmo nome de anfitrião ganha um endereço que só o par do túnel consegue alcançar, e os clientes da LAN recebem-no como uma resposta válida.

Três condições decidem a reparação. Primeiro, o endereço adicional é alcançável a partir dos clientes que o recebem? Segundo, algum consumidor ainda depende desse registo? Terceiro, o registo é dinâmico e, por isso, pode voltar, ou é estático e, por isso, uma entrada deliberada?

Responda a isso antes de tocar em alguma coisa. Se o endereço não for alcançável a partir da rede que consulta, nenhuma limpeza da cache do cliente o corrige por muito tempo. Se algo depender dele, como um caminho de gestão usado pelos próprios pares do túnel, removê-lo quebra esse caminho. E um registo dinâmico apagado sem tratar do seu publicador reaparece no evento de registo seguinte.

Leia o registo antes de mudar o registrador

Consulte o nome completo qualificado exato a partir da rede que relata o problema e compare as respostas com as interfaces e os ouvintes reais do servidor. Um único nome que devolve vários endereços é normal; a questão é se cada um é utilizável pelo cliente que o recebe.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

A primeira consulta usa o resolvedor local, a segunda pergunta diretamente a um servidor DNS específico e a terceira faz o mesmo a partir do PowerShell no Windows. Compará-las separa uma cache de cliente obsoleta de uma resposta autoritativa. Se a consulta direta já devolve o endereço do túnel, o problema são os dados publicados e não a cache local.

Anote o carimbo temporal do registo e se a consola de DNS o mostra como dinâmico. Esse único atributo diz-lhe qual das três condições acima se aplica, e é a diferença entre uma limpeza de cinco minutos e uma reparação que dura.

Corrija o publicador ou o registo, mas saiba qual

Se o registo for dinâmico e indesejado, a correção duradoura é impedir que essa interface se registe. O Windows expõe definições de registo por interface, e o serviço de cliente DNS volta a publicar na ligação ou alteração de endereço seguinte. Desativar o registo para o adaptador de ligação discada deixa o registo do adaptador de LAN intacto, que é normalmente o que se pretende.

Tenha cuidado com os comutadores que se aplicam a toda a máquina. Uma definição global que desativa a atualização dinâmica afeta cada interface desse anfitrião, incluindo aquela em cujo registo outros clientes confiam. Num controlador de domínio a mesma precaução aplica-se com mais força, porque o anfitrião também pode possuir registos de localização de serviço de que os clientes dependem para iniciar sessão.

Se o registo for estático, foi colocado ali de propósito e a conversa é com quem o colocou. Apagar um registo estático porque hoje é inconveniente elimina a única prova de por que existe. Em ambos os casos, apague a resposta obsoleta só depois de o publicador estar tratado, e anote o que alterou para que a pessoa seguinte possa distinguir uma entrada deliberada de um acidente.

Verifique a partir da rede de cliente que falhou

A verificação pertence à rede que relatou o sintoma, não ao servidor. Limpe a cache do resolvedor do cliente através do mecanismo suportado e, depois, repita a consulta original e a ligação original ao serviço por nome.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

O primeiro comando limpa a cache do resolvedor do Windows, e o segundo mostra se o nome voltou a estar em cache e que endereço foi guardado. Uma ligação bem-sucedida do servidor consigo próprio não prova nada sobre um cliente da LAN, e remover uma rota para o endereço indesejado não corrige o que o DNS publica.

Por fim, repita o evento que antes introduzia o endereço: volte a ligar o cliente VPN ou renove a sessão de ligação discada. Verifique novamente o nome publicado após essa mudança de ciclo de vida. Uma reparação que só dura até à ligação seguinte foi uma limpeza, não uma reparação, e saber qual das duas fez é a diferença entre fechar o bilhete e reabri-lo na semana seguinte.