Quale collegamento risponde: domini di instradamento per il DNS di una VPN a tunnel diviso

Mantenete la navigazione ordinaria sul collegamento locale mentre i nomi aziendali si risolvono tramite il server DNS fornito dal tunnel. Disattivare la rotta predefinita della VPN dà la prima metà e lascia la seconda non costruita. Seguono l’impostazione mancante, la punteggiatura che ne cambia il significato e l’unico comando che mostra quale collegamento ha risposto davvero. NetworkManager e systemd-resolved sono presupposti in tutto il testo, perché è in questa coppia che di solito inizia la confusione.

Primo passo: separate la rotta dal resolver

ipv4.never-default risponde a una domanda di instradamento e impedisce a NetworkManager di installare questa connessione come percorso per tutto il traffico IPv4. Un dominio di instradamento DNS risponde a un’altra domanda: quali server dei nomi di quale collegamento ricevono una query per un suffisso corrispondente. Nessuno dei due implica l’altro, e un profilo può portarne uno per anni mentre manca l’altro. Solo rotta significa che il tunnel trasporta le sottoreti aziendali e il suo resolver risponde ai nomi aziendali, mentre tutto il resto resta intatto.

Impostate solo la proprietà della rotta e i nomi interni falliscono, di solito con un timeout che sembra un tunnel rotto. Impostate solo il dominio e avete aggiunto in silenzio un suffisso di ricerca a ogni nome breve della macchina. Entrambi gli errori mandano il ticket al server VPN, che raramente è la parte sbagliata.

Secondo passo: aggiungete un dominio solo di instradamento al profilo

Supponete che la connessione si chiami corp-vpn, che il suffisso aziendale sia internal.example e che il resolver del tunnel sia già raggiungibile. Leggete prima i valori attuali, perché i comandi sotto modificano proprietà che possono già contenere voci.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Sostituite con il vostro nome di connessione e il vostro suffisso, perché i valori sopra sono illustrativi. Il segno più conta più di quanto sembri: con esso il valore viene aggiunto all’elenco esistente, mentre senza di esso la proprietà viene sostituita e domini non correlati scompaiono da un profilo che ieri funzionava. La tilde cambia il comportamento, non lo stile, e il paragrafo sotto spiega cosa seleziona. Tenete la lettura prima della scrittura, così la forma di sostituzione non vi sorprenda mai.

Una tilde iniziale contrassegna un dominio solo di instradamento, quindi le query corrispondenti vanno ai server di questo collegamento e il suffisso non viene aggiunto ai nomi brevi. Togliete la tilde e la stessa stringa diventa anche un suffisso di ricerca, un risultato diverso che le persone raramente intendono. Entrambe le impostazioni sopra sono IPv4, quindi un profilo a doppio stack ha bisogno di ipv6.never-default e dello stesso dominio di instradamento in ipv6.dns-search, altrimenti il lato IPv6 continua a usare la rotta predefinita e i nomi interni falliscono lì.

Terzo passo: chiedete a resolvectl quale collegamento ha risposto

Eseguite resolvectl status e leggete i server DNS e i domini di ogni collegamento, poi eseguite resolvectl query host.internal.example su un vero nome interno che siete autorizzati a interrogare. Il secondo comando è l’unica prova diretta che il dominio di instradamento fa il suo lavoro, perché nomina il collegamento che ha risposto. Un elenco di stato da solo prova la configurazione; la query prova la risoluzione.

systemd-resolved sceglie il dominio di instradamento più corrispondente, quindi un dominio più specifico su un altro collegamento può ancora vincere la corsa. Se la query torna da un collegamento che non vi aspettavate, leggete gli elenchi dei domini prima di toccare il server DNS della VPN. Un dominio radice di ~. corrisponde a tutto, e se è già presente il vostro dominio specifico vince comunque per i suoi nomi mentre il collegamento risponde molto più di quanto avete chiesto. Rimuovete o restringete quella voce radice quando l’intenzione era solo i nomi aziendali.

Se il collegamento VPN non elenca alcun server DNS, il client non ne ha mai registrato uno. Un dominio di instradamento senza server dietro fallisce diversamente da un dominio assente, quindi correggete prima la registrazione.

Quarto passo: quando il nome si risolve ma il servizio no

Una risposta corretta prova solo che la risoluzione ha funzionato, e l’applicazione ha ancora bisogno di una rotta verso l’indirizzo ricevuto. Quella rotta deve sopravvivere alla rotta predefinita divisa appena configurata, quindi controllatela prima di dare di nuovo la colpa al DNS. Poi controllate la raggiungibilità sulla porta del servizio, perché una condivisione file o un servizio di directory fallisce nella risoluzione, nell’instradamento o nell’autenticazione e produce messaggi molto simili in ogni caso. Tenete separati questi tre livelli quando riportate l’esito, altrimenti la persona successiva ricontrolla un DNS che era già corretto.

La modifica a Samba che circola accanto a questa domanda riguarda il livello di accesso, non la scelta del DNS. Applicarla a un guasto di risoluzione dei nomi è il modo in cui un piccolo problema ne acquisisce un secondo.

Quinto passo: non sostituite il resolver per correggere un dominio mancante

Il consiglio che sovrascrive il file del resolver o installa un altro gestore del resolver risolve un problema diverso. Sono modifiche di integrazione del sistema con i propri modi di guasto, e nessuna aggiunge un dominio di instradamento mai configurato. Stabilite quale componente possiede la risoluzione dei nomi sulla macchina prima di sostituirlo, perché su un desktop NetworkManager con systemd-resolved quella proprietà è già definita. Combatterla è il modo in cui una configurazione funzionante diventa qualcosa che nessuno può riprodurre.

Ordine di lavoro: confermate che il tunnel fornisca un resolver, aggiungete il dominio solo di instradamento, riconnettetevi tramite i controlli del profilo, verificate il collegamento che risponde, poi provate il servizio sulla sua porta. Quella sequenza lascia un risultato che potete consegnare alla persona successiva senza una seconda intervista.