O DNS público funciona, pero iso non significa que se atope Active Directory

A VPN conecta, o navegador abre un sitio público e o portátil segue sen poder iniciar sesión no dominio. A conclusión habitual é que o DNS está ben porque os nomes se resolven. Non está ben, e a razón é que unha proba co navegador exercita unha soa consulta dunha cadea que necesita un cliente unido ao dominio. O descubrimento do dominio pide primeiro rexistros de servizo, despois os enderezos dos controladores que eses rexistros nomean e por último unha ruta cara aos portos nos que escoitan eses controladores. Unha resposta pública non satisfai ningún deses pasos.

O mito: os nomes resólvense, así que o DNS está feito

Que un sitio público se resolva só di que algún resolutor respondeu a unha consulta A ou AAAA dun nome nunha zona pública. Active Directory usa o mesmo protocolo para outra pregunta: onde están os servizos do dominio e que controlador debe usar este cliente. A pregunta exprésase como rexistros SRV baixo unha zona co nome do dominio, e un resolutor público recursivo non ten motivo para telos.

Cando falta o rexistro, o resolutor devolve unha resposta negativa, que é unha resposta DNS válida e non unha caída. O cliente recorre entón a información de controlador na caché se a ten, e por iso mesmo un escritorio pode parecer ben durante horas e fallar tras un reinicio ou un cambio de contrasinal.

Que pide realmente un cliente de dominio, por orde

Para un dominio como corp.example, a consulta xenérica de localizador é _ldap._tcp.dc._msdcs.corp.example. As respostas SRV nomean controladores candidatos e os seus portos, e despois o cliente necesita rexistros de enderezo para eses nomes de host antes de abrir unha conexión. O descubrimento consciente do sitio engade consultas baixo o subdominio do sitio, e as respostas determinan que controladores se prefiren, non cal é obrigatorio.

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

Siga a cadea nesa orde, desde a rede onde ocorre o problema. Un nome de host que se resolve a un enderezo inalcanzable é un fallo de encamiñamento, non un fallo de DNS. Un controlador alcanzable ao que lle faltan os rexistros de localizador é un fallo de DNS, non un fallo de encamiñamento. Os dous producen queixas de usuario parecidas e reparacións completamente distintas.

Por que un resolutor público responde e aínda así rompe o inicio de sesión

Se o adaptador entrega ao cliente un resolutor público, os nomes públicos funcionan e o espazo de nomes interno non. Engadir un segundo resolutor público non axuda, porque ningún dos dous ten a zona. Tampouco a lista habitual «primeiro interno, despois público» se comporta como unha regra por dominio: unha resposta negativa do primeiro servidor é unha resposta lexítima, e o cliente non reintenta o segundo servidor só porque a resposta estivese baleira.

Ambos os resolutores internos, se ten dous, deben ter o espazo de nomes de AD e ser alcanzables desde a rede actual do cliente. Esa é a parte que rompen os deseños de túnel dividido: a VPN pode transportar a subrede do túnel mentres o resolutor interno está nun prefixo que o túnel non encamiña, así que a consulta sae cara a un resolutor que non pode respondela.

Windows tamén aplica unha directiva de resolución de nomes que pode dirixir espazos de nomes concretos a servidores concretos, e os enderezos DNS que mostra o adaptador non son toda a historia. Cambiar a lista do adaptador sen cambiar esa directiva pode deixar intacta a configuración efectiva, e por iso unha corrección que parece aplicada non ten ningún efecto.

Manteña o DNS do túnel e as súas rutas de acordo

Un perfil de VPN que empurra un resolutor pero non o prefixo que o contén crea un resolutor que o cliente non pode alcanzar; un que empurra o prefixo pero ningún resolutor deixa o cliente preguntando ao local. Trate o par como un só elemento de configuración e comprobe ambos tras cada cambio de perfil, porque un envío reordenado ou unha nova directiva de túnel dividido pode separalos.

Comprobe tamén que fai o cliente co axuste enviado. Algúns clientes aplican o servidor DNS só á interface do túnel e deixan o resolutor do adaptador físico no seu sitio, así que cal gaña depende da métrica da interface e do nome consultado. Se a resposta interna só chega cando o adaptador físico está desactivado, ese é o mecanismo que hai que corrixir, non os rexistros do dominio.

Acepte cunha chamada de descubrimento e unha operación en vivo

Unha proba de aceptación útil executa a consulta de localizador e despois realiza unha operación autenticada real, como abrir un recurso compartido apoiado por directorio ou pedir un tique. Fágao antes da transición da VPN e outra vez despois, na mesma máquina, sen reiniciar entre medias. As credenciais na caché e as sesións xa abertas farán de boa gana que un camiño roto pareza san, así que un inicio de sesión correcto no escritorio non é a proba.

As recomendacións de Microsoft para o cliente DNS trazan a mesma liña entre resolver o espazo de nomes interno e reenviar as consultas públicas cara arriba, e esa é a disposición que hai que conservar ao introducir unha VPN.

Se o fallo é só lento e non fallido, manteña o atraso separado do diagnóstico. Un tempo de espera durante o descubrimento pode vir dun controlador inalcanzable, un porto bloqueado ou un resolutor que responde tarde, e nada diso queda demostrado só pola espera. Capture a consulta real, a súa resposta e o intento de conexión antes de cambiar calquera axuste do resolutor.