El DNS públic funciona, però això no vol dir que es trobi l’Active Directory

El VPN es connecta, el navegador obre un lloc públic i l’ordinador portàtil encara no pot iniciar sessió al domini. La conclusió habitual és que el DNS va bé perquè els noms es resolen. No va bé, i la raó és que una prova amb el navegador exerceix una sola consulta d’una cadena que necessita un client unit al domini. El descobriment del domini demana primer registres de servei, després les adreces dels controladors que aquests registres nomenen i finalment una ruta cap als ports on escolten aquests controladors. Una resposta pública no satisfà cap d’aquestes passes.

El mite: els noms es resolen, així que el DNS ja està fet

Que un lloc públic es resolgui només diu que algun resolutor ha respost una consulta A o AAAA per a un nom d’una zona pública. L’Active Directory fa servir el mateix protocol per a una altra pregunta: on són els serveis del domini i quin controlador ha de fer servir aquest client. La pregunta s’expressa com a registres SRV sota una zona amb el nom del domini, i un resolutor públic recursiu no té cap motiu per tenir-los.

Quan falta el registre, el resolutor retorna una resposta negativa, que és una resposta DNS vàlida i no una caiguda. El client llavors recorre a informació de controlador en memòria cau si en té, i per això mateix un escriptori pot semblar bé durant hores i fallar després d’un reinici o d’un canvi de contrasenya.

Què demana realment un client de domini, per ordre

Per a un domini com corp.example, la consulta genèrica de localitzador és _ldap._tcp.dc._msdcs.corp.example. Les respostes SRV nomenen controladors candidats i els seus ports, i després el client necessita registres d’adreça per a aquests noms d’amfitrió abans de poder obrir una connexió. El descobriment conscient del lloc afegeix consultes sota el subdomini del lloc, i les respostes determinen quins controladors són preferits i no quin és obligatori.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Seguiu la cadena en aquest ordre, des de la xarxa on passa el problema. Un nom d’amfitrió que es resol a una adreça inabastable és una fallada d’encaminament, no una fallada de DNS. Un controlador abastable a qui falten els registres de localitzador és una fallada de DNS, no una fallada d’encaminament. Les dues produeixen queixes d’usuari semblants i reparacions completament diferents.

Per què un resolutor públic respon i tot i així es trenca l’inici de sessió

Si l’adaptador dona al client un resolutor públic, els noms públics funcionen i l’espai de noms intern no. Afegir un segon resolutor públic no ajuda, perquè cap dels dos té la zona. Ni la llista habitual “primer intern, després públic” es comporta com una regla per domini: una resposta negativa del primer servidor és una resposta legítima, i el client no reintenta el segon servidor només perquè la resposta fos buida.

Tots dos resolutors interns, si en feu servir dos, han de tenir l’espai de noms de l’AD i ser abastables des de la xarxa actual del client. Aquesta és la part que trenquen els dissenys de túnel dividit: el VPN pot portar la subxarxa del túnel mentre el resolutor intern és en un prefix que el túnel no encamina, de manera que la consulta surt cap a un resolutor que no la pot respondre.

Windows també aplica una política de resolució de noms que pot dirigir espais de noms concrets a servidors concrets, i les adreces DNS que mostra l’adaptador no són tota la història. Canviar la llista de l’adaptador sense canviar aquesta política pot deixar la configuració efectiva intacta, i per això una correcció que sembla aplicada no té cap efecte.

Manteniu el DNS del túnel i les seves rutes d’acord

Un perfil de VPN que empeny un resolutor però no el prefix que el conté crea un resolutor que el client no pot abastar; un que empeny el prefix però cap resolutor deixa el client preguntant al local. Tracteu la parella com un sol element de configuració i comproveu tots dos després de cada canvi de perfil, perquè un enviament reordenat o una política nova de túnel dividit els pot separar.

Comproveu també què fa el client amb el paràmetre enviat. Alguns clients apliquen el servidor DNS només a la interfície del túnel i deixen el resolutor de l’adaptador físic al seu lloc, així que quin guanya depèn de la mètrica de la interfície i del nom que es consulta. Si la resposta interna només arriba quan l’adaptador físic està desactivat, aquest és el mecanisme a corregir, no els registres del domini.

Accepteu amb una crida de descobriment i una operació en viu

Una prova d’acceptació útil executa la consulta de localitzador i després fa una operació autenticada real, com ara obrir un recurs compartit basat en directori o demanar un tiquet. Feu-ho abans de la transició del VPN i una altra vegada després, a la mateixa màquina, sense reiniciar entremig. Les credencials en memòria cau i les sessions ja obertes faran de bon grat que un camí trencat sembli sa, així que un inici de sessió correcte a l’escriptori no és la prova.

Les recomanacions de Microsoft per al client DNS tracen la mateixa línia entre resoldre l’espai de noms intern i reenviar les consultes públiques cap amunt, i aquesta és la disposició que cal preservar quan s’introdueix un VPN.

Si la fallada només és lenta i no fallida, manteniu el retard separat del diagnòstic. Un temps d’espera durant el descobriment pot venir d’un controlador inabastable, d’un port bloquejat o d’un resolutor que respon tard, i cap d’aquests no queda demostrat només per l’espera. Captureu la consulta real, la seva resposta i l’intent de connexió abans de canviar cap paràmetre del resolutor.