Per què un nom de servidor es resol a la seva adreça VPN després de la connexió telefònica

Un servidor de fitxers d’oficina respon a la seva adreça de LAN tot el matí, i llavors un usuari remot es connecta per telèfon i el nom comença a resoldre’s a una adreça de túnel. No s’ha editat res al DNS a mà, i aquesta és la pista: el registre el va publicar la mateixa màquina. Tres condicions decideixen si arregleu el registrador, el registre o la visió del client, i equivocar-vos en l’ordre fa que el registre torni després de la connexió següent.

Dues adreces, un nom, tres condicions

Un servidor Windows amb diverses interfícies pot tenir una adreça de LAN, una o més adreces de connexió telefònica i de vegades una segona targeta de xarxa. Cada interfície pot registrar les seves pròpies adreces al DNS si se li permet el registre dinàmic. Quan l’adaptador PPP es registra, el mateix nom d’amfitrió guanya una adreça que només pot assolir el parell del túnel, i els clients de la LAN la reben com una resposta vàlida.

Tres condicions decideixen la reparació. Primer, l’adreça addicional és assolible des dels clients que la reben? Segon, algun consumidor encara depèn d’aquest registre? Tercer, el registre és dinàmic i, per tant, pot tornar, o és estàtic i, per tant, una entrada deliberada?

Responeu això abans de tocar res. Si l’adreça no és assolible des de la xarxa que consulta, cap neteja de la memòria cau del client ho arregla per gaire temps. Si alguna cosa hi depèn, com un camí de gestió que fan servir els mateixos parells del túnel, treure-la trenca aquest camí. I un registre dinàmic esborrat sense adreçar el seu publicador tornarà a aparèixer al proper esdeveniment de registre.

Llegiu el registre abans de canviar el registrador

Consulteu el nom completament qualificat exacte des de la xarxa que informa del problema i compareu les respostes amb les interfícies i els oients reals del servidor. Un sol nom que retorna diverses adreces és normal; la qüestió és si cada una és utilitzable pel client que la rep.

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

La primera consulta fa servir el resolutor local, la segona pregunta directament a un servidor DNS concret i la tercera fa el mateix des de PowerShell a Windows. Comparar-les separa una memòria cau del client obsoleta d’una resposta autoritativa. Si la consulta directa ja retorna l’adreça del túnel, el problema és la informació publicada i no la memòria cau local.

Anoteu la marca de temps del registre i si la consola del DNS el mostra com a dinàmic. Aquest sol atribut us diu quina de les tres condicions anteriors s’aplica, i és la diferència entre una neteja de cinc minuts i una reparació que dura.

Arregleu el publicador o arregleu el registre, però sapigueu quin

Si el registre és dinàmic i no el voleu, la solució duradora és impedir que aquesta interfície es registri. Windows exposa configuracions de registre per interfície, i el servei client de DNS torna a publicar en la propera connexió o canvi d’adreça. Desactivar el registre per a l’adaptador de connexió telefònica deixa intacte el registre de l’adaptador de LAN, que normalment és el que voleu.

Aneu amb compte amb els interruptors de tot l’equip. Una configuració global que desactiva l’actualització dinàmica afecta cada interfície d’aquell amfitrió, inclosa aquella en el registre de la qual confien altres clients. En un controlador de domini la mateixa precaució s’aplica amb més força, perquè l’amfitrió també pot posseir registres d’ubicació de servei dels quals els clients depenen per iniciar sessió.

Si el registre és estàtic, es va col·locar allà a propòsit i la conversa és amb qui el va col·locar. Esborrar un registre estàtic perquè avui és incòmode elimina l’única prova de per què existeix. En tots dos casos, esborreu la resposta obsoleta només després d’haver tractat el publicador, i anoteu què heu canviat perquè la persona següent pugui distingir una entrada deliberada d’un accident.

Verifiqueu des de la xarxa de clients que va fallar

La verificació pertany a la xarxa que va informar del símptoma, no al servidor. Netegeu la memòria cau del resolutor del client pel seu mecanisme suportat i, després, repetiu la consulta original i la connexió original al servei pel nom.

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

La primera ordre neteja la memòria cau del resolutor de Windows, i la segona mostra si el nom torna a estar a la memòria cau i quina adreça s’hi ha desat. Una connexió correcta del servidor amb si mateix no demostra res sobre un client de la LAN, i treure una ruta cap a l’adreça no desitjada no corregeix el que publica el DNS.

Finalment, repetiu l’esdeveniment que abans introduïa l’adreça: torneu a connectar el client VPN o renoveu la sessió de connexió telefònica. Comproveu el nom publicat una altra vegada després d’aquest canvi de cicle de vida. Una reparació que només dura fins a la connexió següent va ser una neteja, no una reparació, i saber quina de les dues heu fet és la diferència entre tancar el tiquet i tornar-lo a obrir la setmana vinent.