Il nome host della LAN fallisce via VPN: suffisso, mDNS o zona?

Accanto al dispositivo, la stampante risponde a un nome breve e il file server risponde a un soprannome. Attraverso il tunnel, entrambi i nomi scadono mentre i loro indirizzi continuano a funzionare. La rotta fa il suo lavoro; il percorso di denominazione che faceva funzionare quei nomi brevi non ha mai attraversato il tunnel. Tre meccanismi producono questo comportamento, e ciascuno richiede una correzione diversa.

Iniziate identificando da quale meccanismo dipende il nome.

Tre tipi di nome che si comportano diversamente

Un nome a etichetta singola come fileserver di solito si basa su un suffisso di ricerca DNS aggiunto dal resolver. Quel suffisso arriva spesso con il lease DHCP locale, quindi un client remoto che ottiene l'indirizzamento dalla VPN non ha motivo di conoscerlo. Aggiungere una rotta non consegna il suffisso. Il nome breve semplicemente smette di esistere come nome, anche se l'indirizzo dietro di esso è raggiungibile.

Un nome che termina in .local di solito viene risolto tramite DNS multicast sul collegamento locale, come descrive la RFC 6762. Il multicast non attraversa un tunnel instradato a meno che qualcosa non lo colleghi in bridge o lo proxifichi deliberatamente, quindi il nome smette di risolversi nel momento in cui lasciate il segmento.

Un nome aziendale completamente qualificato appartiene a una zona interna servita dai resolver dell'organizzazione. Quello funziona da remoto quando la VPN spinge quei resolver e il client è configurato per usarli. E localhost è a uso speciale secondo la RFC 6761: si riferisce alla macchina davanti a voi, mai a un servizio remoto.

Leggete il resolver prima di cambiare la rotta

Chiedete quale server di nomi ha risposto e quale suffisso è stato aggiunto. La stessa query attraverso resolver diversi dà risposte diverse, e quella differenza è la prova che vi serve.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

Se la query completamente qualificata si risolve ma quella breve no, il guasto è nel suffisso, non nel server. Se nessuna delle due si risolve e l'indirizzo funziona, il client non sta affatto usando il resolver interno. Confrontate l'elenco dei resolver con ciò che la VPN dovrebbe spingere, perché un client che mantiene il proprio resolver locale per ogni query non vedrà mai la zona interna.

Portate il nome giusto al client

Chiedete all'amministratore il nome di accesso remoto documentato, per intero, e usatelo nel profilo invece di indovinare i suffissi. Se la distribuzione supporta lo split DNS, configurate il dominio interno perché sia risolto dai server interni mentre tutto il resto mantiene il resolver locale. Spingete il dominio di ricerca tramite la configurazione VPN dove il client lo supporta.

Verificate il risultato sul client anziché sul gateway. Un'impostazione applicata sul server che non raggiunge mai il client non cambia nulla.

Mantenete intatta l'identità del certificato

Un test basato sull'indirizzo che ignora l'errore del certificato dimostra solo che il socket si è aperto. Il certificato del servizio è emesso per un nome, e il client continuerà a rifiutare la discrepanza a ragione. Se il certificato elenca solo il nome interno, usate quel nome e correggete la risoluzione, oppure ottenete un certificato che copra l'indirizzo che intendete usare.

Annotate il nome, il resolver e il suffisso che hanno prodotto una connessione riuscita. Quell'appunto risparmia alla persona successiva di ripetere la soluzione provvisoria basata sull'indirizzo che nasconde il vero problema.