Il DNS della VPN funziona, ma i nomi .local falliscono ancora: chi li risolve?

Due macchine sulla stessa VPN, lo stesso nome host, e solo una lo risolve: la differenza di solito non è il tunnel ma quale resolver ha risposto. Su un desktop Linux quel nome può passare per lo switch dei servizi di nomi, per lo stub di systemd-resolved o per un resolver che l’applicazione ha portato con sé, e ognuno applica la propria regola allo stesso suffisso. È sul suffisso che le regole divergono, perché .local non è un’etichetta neutra. Scoprite quale percorso segue davvero il programma che fallisce prima di cambiare l’ordine in cui viene eseguito qualcosa.

Due resolver, due risposte diverse

Una ricerca glibc tradizionale percorre la riga hosts: di nsswitch.conf e interroga ogni modulo a turno finché uno risponde. Un client che parla con systemd-resolved tramite lo stub listener interroga invece un solo processo, e quel processo applica la politica per collegamento più i propri casi speciali. Un’applicazione che porta il proprio resolver, o che collega una libreria che lo fa, può aggirare entrambi. Un nome host può quindi avere tre proprietari su una sola macchina, e solo uno di loro sa cosa intendeva la VPN.

Identificate il proprietario prima di cambiare qualcosa, perché la correzione è diversa per ciascuno dei tre. Un browser e uno strumento da riga di comando sullo stesso desktop possono legittimamente non essere d’accordo, e quel disaccordo è l’indizio, non il bug. Se il browser risolve il nome e lo strumento no, state eseguendo il debug di un percorso del resolver e non di una rotta VPN. Confermate la rotta separatamente, così che un guasto di routing non venga scambiato per un guasto del servizio di nomi. Quando entrambi concordano, il guasto è a monte dell’host e la configurazione del resolver qui non vale un’altra modifica.

Quale comando ha davvero interrogato il vostro resolver

Due comandi di sola lettura rispondono a domande correlate, e confrontarli localizza il problema più in fretta che leggere la configurazione. Usate un nome interno reale e mantenete l’output privato, perché i record interni restano interni. Eseguite entrambi nella stessa sessione in cui gira il programma che fallisce:

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

Il primo interroga attraverso i moduli configurati, che è ciò che sperimenta un programma tipico. Il secondo interroga direttamente systemd-resolved e riporta il collegamento, il protocollo e il server che ha risposto. Interrogare il server aziendale per indirizzo dimostra solo che il server detiene il record, perché non dice nulla sul fatto che l’applicazione glielo abbia mai chiesto. Leggete il collegamento che trasporta la VPN e i domini che dichiara, poi confrontate quell’elenco con il suffisso nel nome che fallisce.

Perché .local salta la vostra zona unicast

la pagina di riferimento di systemd-resolved afferma che i nomi con più etichette che terminano in .local vanno normalmente verso DNS multicast quando mDNS è abilitato, invece che verso il normale DNS unicast. L’RFC 6762 riserva quello spazio di nomi al multicast link-local, quindi una zona aziendale può contenere un record corretto che non viene mai interrogato per quel suffisso. Il tunnel può instradare il resolver perfettamente e perdere comunque la corsa. Un ping che riesce dalla cache non dice nulla sulla ricerca appena avvenuta.

Esiste un’eccezione documentata, e risolve la maggior parte di questi casi: quando un collegamento dichiara quel suffisso come dominio di ricerca o dominio di routing, il daemon lo mantiene sul percorso unicast e salta il caso speciale multicast. È una politica per collegamento e non una preferenza globale. Due macchine con lo stesso server VPN possono comportarsi diversamente quando un profilo di rete dichiara il dominio e l’altro no, quindi leggete il profilo attivo e non quello che ricordate di aver modificato.

L’eccezione ristretta batte un riordino globale

Per una zona esistente che non potete rinominare, fate dichiarare il dominio ai proprietari del resolver e della VPN sulla connessione che lo trasporta. Una voce di dominio di routing per quell’unico suffisso più l’indirizzo del server previsto è una modifica piccola con un proprietario nominato, e vive con il collegamento invece che in un file modificato a mano.

Sopravvive anche a una disconnessione, perché la politica del collegamento viene riapplicata quando il collegamento torna. Modificare il nsswitch.conf condiviso è l’alternativa tentante e la più costosa, perché cambia il comportamento di ricerca per ogni nome della macchina, inclusa la scoperta locale. Disattivare il daemon multicast non è equivalente: rimuove il comportamento locale senza insegnare la zona aziendale a nessun resolver. Se il servizio è nuovo e non ereditato, mettetelo sotto un sottodominio controllato dalla vostra organizzazione e saltate del tutto la competizione. Scegliete l’eccezione ristretta quando il nome è fissato nel firmware o stampato su un’etichetta, e un nuovo sottodominio quando controllate ancora il client.

Cosa dimostrare dopo la modifica

Dimostrate la correzione con la ricerca propria dell’applicazione invece che con uno strumento installato per provare, e svuotate qualsiasi cache che potrebbe rispondere al posto suo. Poi confermate il percorso del resolver e il collegamento che ha servito la risposta. Infine verificate che la scoperta locale si comporti come prima della modifica, perché la stampante che smette di comparire è la parte che le persone notano per ultima. Questi tre comandi controllano il nome, il percorso e l’identità TLS in quest’ordine:

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 indirizzo corretto con il certificato sbagliato fa comunque fallire un client rigoroso, quindi controllate il nome atteso dall’applicazione una volta che la risoluzione funziona. Confermate che il servizio accetti connessioni dall’indirizzo VPN e non solo dall’intervallo dell’ufficio. Scrivete l’ambito del dominio, il server e il proprietario nella documentazione della connessione. Altrimenti la prossima persona che incontra questo guasto ricorrerà alla stessa modifica globale che avete appena evitato.