El DNS del VPN funciona, però els noms .local encara fallen: qui els resol?

Dues màquines al mateix VPN, el mateix nom d’amfitrió i només una d’elles el resol: la diferència normalment no és el túnel, sinó quin resolutor ha respost. En un escriptori Linux aquest nom pot viatjar pel commutador de serveis de noms, pel stub de systemd-resolved o per un resolutor que l’aplicació s’ha portat, i cadascun d’ells aplica la seva pròpia regla al mateix sufix. El sufix és on les regles divergeixen, perquè .local no és una etiqueta neutra. Esbrineu quin camí fa realment el programa que falla abans de canviar l’ordre en què s’executa res.

Dos resolutors, dues respostes diferents

Una cerca tradicional de glibc recorre la línia hosts: de nsswitch.conf i pregunta a cada mòdul per torns fins que un respon. Un client que parla amb systemd-resolved a través del stub listener pregunta en canvi a un sol procés, i aquest procés aplica la política per enllaç més els seus propis casos especials. Una aplicació que porta el seu propi resolutor, o que enllaça una biblioteca que ho fa, pot evitar tots dos. Un nom d’amfitrió pot tenir, doncs, tres propietaris en una màquina, i només un d’ells sap què volia el VPN.

Identifiqueu el propietari abans de canviar res, perquè la solució és diferent per a cadascun dels tres. Un navegador i una eina de línia d’ordres al mateix escriptori poden discrepar legítimament, i aquesta discrepància és la pista, no l’error. Si el navegador resol el nom i l’eina no, esteu depurant un camí de resolutor i no una ruta del VPN. Confirmeu la ruta per separat, perquè una fallada d’encaminament no es confongui amb una fallada del servei de noms. Quan tots dos coincideixen, la fallada és per sobre de l’amfitrió i la configuració del resolutor d’aquí no val una altra edició.

Quina ordre va preguntar realment al vostre resolutor

Dues ordres només de lectura responen preguntes relacionades, i comparar-les localitza el problema més de pressa que llegir la configuració. Feu servir un nom intern real i manteniu la sortida privada, perquè els registres interns segueixen sent interns. Executeu-les totes dues a la mateixa sessió on s’executa el programa que falla:

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

La primera pregunta a través dels mòduls configurats, que és el que experimenta un programa típic. La segona pregunta directament a systemd-resolved i informa de l’enllaç, el protocol i el servidor que ha respost. Consultar el servidor corporatiu per adreça només demostra que el servidor té el registre, perquè no diu res sobre si l’aplicació li va preguntar mai. Llegiu l’enllaç que porta el VPN i els dominis que declara, i després compareu aquesta llista amb el sufix del nom que falla.

Per què .local salta la vostra zona unicast

la referència de systemd-resolved diu que els noms amb diverses etiquetes que acaben en .local normalment van a DNS multicast quan mDNS està habilitat, en lloc del DNS unicast ordinari. L’RFC 6762 reserva aquest espai de noms per al multicast d’enllaç local, així que una zona corporativa pot tenir un registre correcte que mai es consulta per a aquest sufix. El túnel pot encaminar el resolutor perfectament i tot i així perdre la cursa. Un ping que funciona des de la memòria cau no diu res sobre la consulta que s’acaba de fer.

Hi ha una excepció documentada, i resol la majoria d’aquests casos: quan un enllaç declara aquest sufix com a domini de cerca o domini d’encaminament, el dimoni el manté al camí unicast i s’estalvia el cas especial del multicast. Això és política per enllaç i no una preferència global. Dues màquines amb el mateix servidor VPN poden comportar-se diferent quan un perfil de xarxa declara el domini i l’altre no, així que llegiu el perfil actiu i no el que recordeu haver editat.

L’excepció estreta guanya a una reordenació global

Per a una zona existent que no podeu reanomenar, feu que els propietaris del resolutor i del VPN declarin el domini a la connexió que el porta. Una entrada de domini d’encaminament per a aquest únic sufix més l’adreça de servidor prevista és un canvi petit amb un propietari nomenat, i viu amb l’enllaç en lloc d’en un fitxer editat a mà.

També sobreviu a una desconnexió, perquè la política de l’enllaç es torna a aplicar quan l’enllaç torna. Editar el nsswitch.conf compartit és l’alternativa temptadora i la més cara, perquè canvia el comportament de cerca de cada nom de la màquina, inclosa la descoberta local. Desactivar el dimoni multicast tampoc és equivalent: elimina el comportament local sense ensenyar res a cap resolutor sobre la zona corporativa. Si el servei és nou i no heretat, poseu-lo sota un subdomini que controli la vostra organització i salteu-vos la competició del tot. Trieu l’excepció estreta quan el nom està fixat al firmware o imprès en una etiqueta, i trieu un subdomini nou quan encara controleu el client.

Què cal demostrar després del canvi

Demostreu la solució amb la cerca pròpia de l’aplicació i no amb una eina que hàgiu instal·lat per provar, i buideu qualsevol memòria cau que hi pugui respondre. Després confirmeu el camí del resolutor i l’enllaç que ha servit la resposta. Finalment comproveu que la descoberta local es comporta com abans del canvi, perquè la impressora que deixa d’aparèixer és la part que la gent nota més tard. Aquestes tres ordres comproven el nom, el camí i la identitat TLS en aquest ordre:

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

Una adreça correcta amb el certificat equivocat encara fa fallar un client estricte, així que comproveu el nom que espera l’aplicació quan la resolució funcioni. Confirmeu que el servei accepta connexions des de l’adreça del VPN i no només des del rang de l’oficina. Escriviu l’abast del domini, el servidor i el propietari a la documentació de la connexió. Si no, la propera persona que trobi aquesta fallada recorrerà a la mateixa edició global que acabeu d’evitar.