Por que un nome de servidor se resolve na súa dirección VPN tras a conexión telefónica

Un servidor de ficheiros de oficina responde na súa dirección de LAN toda a mañá, e despois un usuario remoto conecta por teléfono e o nome comeza a resolverse nunha dirección de túnel. Non se editou nada no DNS a man, e esa é a pista: o rexistro publicouno a propia máquina. Tres condicións deciden se corrixe o rexistrador, o rexistro ou a visión do cliente, e equivocarse na orde fai que o rexistro volva tras a seguinte conexión.

Dúas direccións, un nome, tres condicións

Un servidor Windows con varias interfaces pode ter unha dirección de LAN, unha ou máis direccións de conexión telefónica e ás veces unha segunda tarxeta de rede. Cada interface pode rexistrar as súas propias direccións no DNS se se lle permite o rexistro dinámico. Cando o adaptador PPP se rexistra, o mesmo nome de host gaña unha dirección á que só pode chegar o par do túnel, e os clientes da LAN recíbena como unha resposta válida.

Tres condicións deciden a reparación. Primeiro, é alcanzable a dirección adicional desde os clientes que a reciben? Segundo, algún consumidor segue dependendo dese rexistro? Terceiro, o rexistro é dinámico e, por tanto, pode volver, ou é estático e, por tanto, unha entrada deliberada?

Responda iso antes de tocar nada. Se a dirección non é alcanzable desde a rede que consulta, ningunha limpeza da caché do cliente o arranxa por moito tempo. Se algo depende dela, como unha ruta de xestión que usan os propios pares do túnel, quitala rompe esa ruta no seu lugar. E un rexistro dinámico borrado sen atender o seu publicador reaparecerá no seguinte evento de rexistro.

Lea o rexistro antes de cambiar o rexistrador

Consulte o nome completo cualificado exacto desde a rede que informa do problema e compare as respostas coas interfaces e os oíntes reais do servidor. Un só nome que devolve varias direccións é normal; a cuestión é se cada unha é utilizábel polo cliente que a recibe.

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 resolutor local, a segunda pregunta directamente a un servidor DNS concreto e a terceira fai o mesmo desde PowerShell en Windows. Comparalas separa unha caché de cliente obsoleta dunha resposta autoritativa. Se a consulta directa xa devolve a dirección do túnel, o problema son os datos publicados e non a caché local.

Anote a marca de tempo do rexistro e se a consola de DNS o mostra como dinámico. Ese único atributo dille cal das tres condicións anteriores se aplica, e é a diferenza entre unha limpeza de cinco minutos e unha reparación que dura.

Corrixa o publicador ou corrixa o rexistro, pero saiba cal

Se o rexistro é dinámico e non se desexa, a solución duradeira é impedir que esa interface se rexistre. Windows expón axustes de rexistro por interface, e o servizo cliente de DNS volve publicar na seguinte conexión ou cambio de dirección. Desactivar o rexistro do adaptador de conexión telefónica deixa intacto o rexistro do adaptador de LAN, que adoita ser o que se quere.

Teña coidado cos conmutadores de toda a máquina. Un axuste global que desactiva a actualización dinámica afecta cada interface dese host, incluída aquela en cuxo rexistro confían outros clientes. Nun controlador de dominio a mesma precaución aplícase con máis forza, porque o host tamén pode posuír rexistros de localización de servizo dos que dependen os clientes para iniciar sesión.

Se o rexistro é estático, colocouse alí a propósito e a conversa é con quen o colocou. Borrar un rexistro estático porque hoxe resulta inconveniente elimina a única proba de por que existe. En ambos os casos, borre a resposta obsoleta só despois de ter atendido o publicador, e anote que cambiou para que a seguinte persoa poida distinguir unha entrada deliberada dun accidente.

Verifique desde a rede de cliente que fallou

A verificación pertence á rede que informou do síntoma, non ao servidor. Limpe a caché do resolutor do cliente mediante o seu mecanismo admitido e, despois, repita a consulta orixinal e a conexión orixinal ao servizo por nome.

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

O primeiro comando limpa a caché do resolutor de Windows, e o segundo mostra se o nome volve estar en caché e que dirección se gardou. Unha conexión correcta do servidor consigo mesmo non demostra nada sobre un cliente da LAN, e quitar unha ruta cara á dirección non desexada non corrixe o que publica o DNS.

Por último, repita o evento que antes introducía a dirección: volva conectar o cliente VPN ou renove a sesión de conexión telefónica. Comprobe de novo o nome publicado tras ese cambio de ciclo de vida. Unha reparación que só dura até a seguinte conexión foi unha limpeza, non unha reparación, e saber cal das dúas fixo é a diferenza entre pechar o tícket e volvelo abrir a próxima semana.