O DNS da VPN funciona, pero os nomes .local seguen fallando: quen os resolve?

Dous equipos na mesma VPN, o mesmo nome de host, e só un deles o resolve: a diferenza normalmente non é o túnel senón que resolutor respondeu. Nun escritorio Linux ese nome pode viaxar polo conmutador de servizos de nomes, polo stub de systemd-resolved ou por un resolutor que a aplicación trouxo consigo, e cada un deles aplica a súa propia regra ao mesmo sufixo. O sufixo é onde as regras diverxen, porque .local non é unha etiqueta neutra. Averigüe que ruta toma realmente o programa que falla antes de cambiar a orde na que se executa algo.

Dous resolutores, dúas respostas distintas

Unha busca tradicional de glibc percorre a liña hosts: de nsswitch.conf e pregunta a cada módulo por quendas ata que un responde. Un cliente que fala con systemd-resolved a través do stub listener pregunta en cambio a un só proceso, e ese proceso aplica a política por enlace máis os seus propios casos especiais. Unha aplicación que trae o seu propio resolutor, ou que liga unha biblioteca que o fai, pode evitar ambos. Un nome de host pode ter, polo tanto, tres propietarios nun mesmo equipo, e só un deles sabe que pretendía a VPN.

Identifique o propietario antes de cambiar nada, porque a solución é distinta para cada un dos tres. Un navegador e unha ferramenta de liña de ordes no mesmo escritorio poden discrepar lexitimamente, e esa discrepancia é a pista, non o erro. Se o navegador resolve o nome e a ferramenta non, está a depurar unha ruta de resolutor e non unha ruta de VPN. Confirme a ruta por separado, para que un fallo de encamiñamento non se confunda cun fallo do servizo de nomes. Cando ambos coinciden, o fallo está por riba do host e a configuración do resolutor de aquí non merece outra edición.

Que orde preguntou realmente ao seu resolutor

Dúas ordes de só lectura responden preguntas relacionadas, e comparalas localiza o problema máis rápido que ler a configuración. Use un nome interno real e manteña a saída privada, porque os rexistros internos seguen sendo internos. Execute ambas na mesma sesión na que corre o programa que falla:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

A primeira pregunta a través dos módulos configurados, que é o que experimenta un programa típico. A segunda pregunta directamente a systemd-resolved e informa do enlace, o protocolo e o servidor que respondeu. Consultar o servidor corporativo por enderezo só demostra que o servidor ten o rexistro, porque non di nada sobre se a aplicación chegou a preguntarlle. Lea o enlace que transporta a VPN e os dominios que declara, e despois compare esa lista co sufixo do nome que falla.

Por que .local salta a súa zona unicast

a referencia de systemd-resolved afirma que os nomes de varias etiquetas que rematan en .local normalmente van a DNS multicast cando mDNS está habilitado, en lugar do DNS unicast ordinario. O RFC 6762 reserva ese espazo de nomes para multicast de enlace local, así que unha zona corporativa pode ter un rexistro correcto ao que nunca se consulta para ese sufixo. O túnel pode encamiñar o resolutor á perfección e aínda así perder a carreira. Un ping que funciona desde a caché non di nada sobre a consulta que acaba de ocorrer.

Hai unha excepción documentada, e resolve a maioría destes casos: cando un enlace declara ese sufixo como dominio de busca ou dominio de encamiñamento, o daemon manteno na ruta unicast e salta o caso especial de multicast. Iso é política por enlace e non unha preferencia global. Dous equipos co mesmo servidor VPN poden comportarse distinto cando un perfil de rede declara o dominio e o outro non, así que lea o perfil activo e non o que recorda ter editado.

A excepción estreita gaña a unha reordenación global

Para unha zona existente que non pode renomear, faga que os propietarios do resolutor e da VPN declaren o dominio na conexión que o transporta. Unha entrada de dominio de encamiñamento para ese único sufixo máis o enderezo de servidor previsto é un cambio pequeno cun propietario nomeado, e vive co enlace en lugar de nun ficheiro editado a man.

Tamén sobrevive a unha desconexión, porque a política do enlace se volve aplicar cando o enlace regresa. Editar o nsswitch.conf compartido é a alternativa tentadora e a máis custosa, porque cambia o comportamento de busca de cada nome do equipo, incluído o descubrimento local. Desactivar o daemon multicast tampouco é equivalente: elimina o comportamento local sen ensinar a ningún resolutor a zona corporativa. Se o servizo é novo e non herdado, póñao baixo un subdominio que controle a súa organización e sáltese a competición por completo. Escolla a excepción estreita cando o nome estea fixado no firmware ou impreso nunha etiqueta, e escolla un subdominio novo cando aínda controle o cliente.

Que demostrar despois do cambio

Demostre a solución coa propia busca da aplicación e non cunha ferramenta que instalou para probar, e baleire calquera caché que puidese responder por ela. Despois confirme a ruta do resolutor e o enlace que serviu a resposta. Por último comprobe que o descubrimento local se comporta como antes do cambio, porque a impresora que deixa de aparecer é a parte que a xente nota ao final. Estas tres ordes comproban o nome, a ruta e a identidade TLS nesa orde:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Un enderezo correcto co certificado equivocado segue facendo fallar a un cliente estrito, así que comprobe o nome que espera a aplicación cando a resolución funcione. Confirme que o servizo acepta conexións desde o enderezo da VPN e non só desde o rango da oficina. Escriba o alcance do dominio, o servidor e o propietario na documentación da conexión. Se non, a seguinte persoa que se atope con este fallo acudirá á mesma edición global que vostede acaba de evitar.