I nomi interni non si risolvono in VPN mentre i siti pubblici funzionano

Un utente segnala che il nome host dell’intranet non si risolve tramite la VPN. Una seconda segnalazione, dallo stesso portatile, dice che un test di perdita mostra ancora query a cui risponde il resolver locale. Sembrano un solo problema e sono due, con prove diverse, e la solita riparazione del primo peggiora il secondo. Separali prima di toccare un’impostazione.

Due sintomi che non sono un solo guasto

Non riuscire a risolvere un nome interno significa che la domanda è andata dove non esiste una risposta per essa. Query che escono dal tunnel significano che la domanda è andata nel posto sbagliato anche quando la risposta era disponibile. Sono guasti opposti: uno è una risposta mancante, l’altro una destinazione in più.

La trappola è che aggiungere il resolver dell’ufficio ovunque corregge il primo e garantisce il secondo. Aggiungere un resolver pubblico ovunque fa il contrario.

Annota entrambe le osservazioni con un timestamp, poi affronta i quattro controlli qui sotto in ordine.

Quale resolver dell’adattatore riceve la domanda

Su Windows il client DNS sceglie i server in base all’ordine di binding degli adattatori, e l’adattatore del tunnel non è automaticamente il primo. Apri le impostazioni avanzate dell’adattatore e sposta la connessione di accesso remoto sopra l’adattatore fisico, poi riconnettiti perché la modifica valga per una sessione nuova.

L’ordine di binding è solo la prima metà. Il client deve anche sapere quali nomi appartengono a quell’adattatore, e questa è una questione di suffisso, non di ordine.

Metti ipconfig /all della macchina che funziona accanto a quello del portatile, entrambi presi mentre il tunnel è attivo. La macchina che funziona mostrerà un suffisso DNS specifico della connessione sul suo adattatore dell’ufficio, e il portatile potrebbe non mostrarne nessuno sul tunnel. Questa differenza spiega un’intera classe di segnalazioni «il server è proprio lì e il nome continua a fallire», perché senza un suffisso il nome breve non viene mai completato nella zona servita dal resolver dell’ufficio.

Un nome breve ha bisogno di un suffisso prima che di una rotta

Digitare un nome host non qualificato chiede al resolver di indovinare un dominio. L’ipotesi viene dall’elenco dei suffissi collegato alla connessione, e se quell’elenco è vuoto la query esce come un’unica etichetta che nessuna zona privata saprà far corrispondere.

Copia il suffisso della macchina che funziona nelle proprietà IPv4 dell’adattatore VPN, nella scheda DNS, poi riconnettiti. Su Linux l’equivalente è il dominio di ricerca sul link del tunnel, che systemd-resolved espone per link anziché globalmente.

Tieni le due impostazioni separate nei tuoi appunti. Un suffisso cambia che cosa viene chiesto; l’indirizzo del resolver cambia a chi viene chiesto. Correggere l’una mentre l’altra è sbagliata produce un risultato che sembra casuale.

Chiedi direttamente al resolver, poi al nome

Una query diretta al resolver dell’ufficio separa un problema di nome da un problema di percorso, perché aggira del tutto la selezione del resolver del client.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Il primo comando chiede un nome completo a un server specifico. Se risponde, il resolver e la rotta verso di esso sono a posto e il guasto è nella selezione o nel suffisso. Se scade in timeout, l’indirizzo è sbagliato o irraggiungibile e il problema è di routing, non di DNS. Il secondo comando mostra che cosa succede con il nome breve, e il terzo stampa la configurazione del resolver per link su un host systemd.

Fai attenzione alle risposte wildcard, che alcune reti restituiscono per nomi sconosciuti. Una risposta che sembra plausibile non è prova che abbia risposto il server previsto, quindi confronta l’indirizzo restituito con quello che il servizio interno usa davvero. Se l’indirizzo appartiene a una pagina parcheggiata o a un proxy, il resolver ha risposto ma la risposta non era mai la tua. Questa distinzione fa risparmiare un’ora passata a inseguire un tunnel che funzionava per tutto il tempo.

Su Linux un client VPN che riscrive /etc/resolv.conf sostituisce del tutto i resolver locali. vpnc espone DNSUpdate no per impedirlo, e systemd-resolved può instradare solo i domini elencati verso il link del tunnel. Entrambi gli approcci tengono i nomi pubblici sul resolver locale e mandano i nomi interni all’ufficio.

Le perdite sono una regola, non una casella da spuntare

La risoluzione dei nomi è uno scambio UDP sulla porta 53, quindi un tunnel che trasporta traffico web ma non UDP lascia la query sul percorso fisico. Dimostralo catturando sulla NIC fisica mentre viene risolto un nome pubblico. Una query visibile su quell’interfaccia in forma leggibile significa che il tunnel non la trasporta.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Se la query compare su quell’interfaccia in forma leggibile, il tunnel non la trasporta. La riparazione è una regola che consente la porta 53 solo verso il resolver fornito dalla VPN e scarta le altre destinazioni, più una configurazione del client che non scarti in silenzio l’opzione fornita.

Quest’ultima parte conta più di quanto sembri. Avvia OpenVPN con route-nopull e l’opzione DNS fornita sparisce insieme alle rotte, a meno che il filtro di pull non venga allargato per conservarla. e un client che ignora dhcp-option DNS continuerà a usare quello che aveva prima. Qualsiasi modifica lato server richiede una sessione nuova per avere effetto, dato che l’elenco dei resolver viene consegnato quando il tunnel sale e una sessione vecchia continua a mostrare lo stato precedente.

Registra quale guasto hai davvero osservato prima di chiudere il ticket. Una risposta interna mancante e una query che sfugge al tunnel richiedono riparazioni diverse, e una modifica del suffisso che corregge la prima può peggiorare in silenzio la seconda. Chi prenderà in carico il ticket dopo di te si fiderà dell’etichetta, quindi rendi l’etichetta accurata.