Perché i nomi DNS privati falliscono sui client VPN e dove controllare

Apri un portatile in una camera d’albergo, avvii il client, digiti il nome del file server interno e non ottieni nulla. Il tunnel dice connesso, e un ping verso un indirizzo nella stessa sottorete risponde ancora, quindi il trasporto in sé va bene. Solo il nome fallisce, e quel vuoto restringe il problema a due punti: quale resolver ha interrogato il client e se la risposta ottenuta può tornare indietro attraverso il tunnel. Azzecca l’uno e trascura l’altro, e il guasto si sposta semplicemente.

Prima di modificare un profilo, verifica cosa fa il client con il nome. Su Linux, resolvectl query files.corp.example mostra quale collegamento e quale resolver hanno prodotto la risposta. Su Windows, Resolve-DnsName files.corp.example mostra il server che ha risposto e l’indirizzo che ha restituito.

Leggi la risposta prima di cambiare qualsiasi cosa

Se il nome torna come NXDOMAIN in pochi millisecondi, la query non ha mai raggiunto la tua zona e ha risposto un resolver pubblico o dell’albergo. Se torna dopo una lunga pausa, qualcosa sta scartando la porta UDP 53 lungo il percorso e il client alla fine è ripiegato. Se risponde con l’indirizzo giusto ma la connessione resta bloccata, la risoluzione va bene e il problema è l’instradamento o il servizio stesso.

Quella suddivisione in tre risparmia un’ora di congetture. Ti dice anche se devi toccare la VPN: un nome che si risolve nell’indirizzo privato corretto ha già dimostrato il percorso del resolver, quindi il lavoro che resta è sul percorso dei dati.

Distribuisci il resolver dall’interno del tunnel

I client si dividono in due gruppi. A uno il server può indicare un resolver durante l’instaurazione della connessione; l’altro tiene l’impostazione in un file locale che nessun gateway può cambiare da remoto.

OpenVPN appartiene al primo gruppo. Sul server, push "dhcp-option DNS 10.8.0.53" e push "dhcp-option DOMAIN corp.example" scendono lungo il canale di controllo, ma solo se la configurazione del client ha ancora pull attivo. Un client modificato a mano che porta pull-filter ignore "dhcp-option" non li vedrà mai, e quella singola riga spiega un numero sorprendente di casi in cui «il server lo spinge ma il mio portatile non è d’accordo».

WireGuard appartiene al secondo gruppo, perché il protocollo non ha alcuna negoziazione delle opzioni. Il resolver e il dominio di ricerca vanno nel blocco [Interface] del client come DNS = 10.8.0.53, corp.example. wg-quick lo applica tramite resolvconf o systemd-resolved, e su Windows il client ufficiale installa regole NRPT che esistono solo finché il tunnel è attivo: Get-DnsClientNrptPolicy le elenca, il che lo rende un modo rapido per vedere se il client ha mai applicato il tuo file.

IPsec/IKEv2 sta nel mezzo. Il plugin attr di strongSwan può restituire un server DNS preso da un pool, e un client Windows di norma lo accetta, ma un profilo che fissa il proprio server di nomi vince su qualunque cosa offra il gateway. Su un client Linux il passaggio manuale equivalente è resolvectl dns wg0 10.8.0.53 seguito da resolvectl domain wg0 '~corp.example'; entrambi svaniscono con l’interfaccia, che è esattamente ciò che vuoi per un’impostazione limitata al tunnel.

Delimita il suffisso invece di inghiottire ogni query

Puntare l’intera lista di resolver del client sul tuo server interno è facile e di solito sbagliato. Ogni nome pubblico viene allora risolto dall’uscita del tuo datacenter, le CDN restituiscono indirizzi lontani e un singolo guasto del resolver porta giù la navigazione dell’utente.

Manda verso l’interno solo il suffisso privato. Su systemd-resolved, un dominio che inizia con ~ serve solo all’instradamento, quindi ~corp.example significa che le query sotto quel suffisso vanno ai server di quel collegamento mentre tutto il resto continua a usare la rete fisica. Windows fa lo stesso con regole NRPT limitate a uno spazio dei nomi, e macOS con un file di resolver supplementare sotto /etc/resolver/.

I nomi multicast meritano una risposta propria. I nomi .local sono link-local per progetto (RFC 6762) e un’interfaccia tun punto a punto non trasporta quel gruppo multicast, quindi aggiungere un resolver pubblico non li pubblica e chiedere di loro a un resolver interno unicast restituisce NXDOMAIN. Un riflettore come avahi in modalità riflettore può collegare due segmenti, ma è una decisione lato server che nessun client può richiedere. Se una stampante o un NAS deve essere raggiungibile per nome, dagli invece un record A nella tua zona.

Dimostra che la risposta può tornare indietro

Una risposta corretta che punta a un indirizzo irraggiungibile sembra esattamente un problema di resolver finché non controlli la rotta. Chiedi al kernel dove andrebbe la risposta: ip route get 10.20.5.20 nomina l’interfaccia e, più utilmente, l’indirizzo sorgente che userebbe.

Osserva l’indirizzo del resolver stesso. Un client con DNS = 10.8.0.53 accanto a AllowedIPs = 10.20.0.0/16 manda le sue query fuori dalla NIC fisica, dove muoiono in silenzio, perché il resolver non sta dentro nessun prefisso che il tunnel rivendichi. Quella discrepanza è il guasto a causa singola più comune in tutta questa area, ed è invisibile se non confronti l’impostazione DNS con i prefissi consentiti riga per riga.

Intervalli sovrapposti causano il guasto opposto. La risposta è giusta, la rotta esiste e punta all’host sbagliato, perché 192.168.0.0/24 a casa è più specifico della rotta del tunnel verso lo stesso intervallo. Rinumera un lato o spingi una rotta più stretta, poi conferma il firewall e il percorso di ritorno dell’host del servizio; le note di strongSwan sul inoltro coprono il lato sysctl di quel percorso.

I certificati sono un controllo d’identità separato che la gente imputa al DNS. Se il browser segnala una discordanza di nome invece di un errore di risoluzione, la ricerca ha già funzionato e da sistemare è il SAN del certificato. Prova HTTPS sul nome, mai sull’IP nudo.

Riprova dal client, non dal gateway

Prova dentro l’applicazione di cui l’utente si lamenta, perché una ricerca da riga di comando non dimostra che il browser segua lo stesso percorso. Il DNS sicuro di Chrome e network.trr.mode di Firefox possono aggirare del tutto il resolver di sistema, e quando lo fanno un nome privato fallisce o finisce su un resolver pubblico. Confrontare resolvectl query con un dig @10.8.0.53 files.corp.example eseguito a mano ti dice quale dei due è successo.

Poi disconnetti e riconnetti prima di dichiararlo risolto. Le impostazioni applicate a mano a un’interfaccia spariscono con l’interfaccia, e un profilo che sembrava corretto solo per una modifica locale dimenticata fallirà al prossimo avvio.

Una breve lista per la macchina successiva: il nome si risolve tramite il resolver del tunnel, il suffisso è delimitato invece che globale, l’indirizzo del resolver sta dentro i prefissi consentiti, l’host della risposta risponde sulla porta del servizio e il certificato copre il nome digitato dall’utente.