Date alla vostra VPN domestica i suoi record DNS per nas.home.arpa

Una volta che il tunnel è attivo, l'ultimo passo è di solito un nome che funziona invece di un indirizzo da incollare in un segnalibro. Un record host di dnsmasq più un indirizzo di resolver che il client riesce a raggiungere fanno questo con due file e senza multicast. La decisione che richiede davvero riflessione è più stretta: il client invia tutto il DNS attraverso il resolver di casa, o solo i nomi sotto home.arpa? Tutto quanto segue presuppone un'installazione WireGuard approvata con un client Linux e un resolver di laboratorio che l'amministratore di casa già gestisce.

Tre modi per consegnare un resolver al client

Per un portatile che si unisce al tunnel occasionalmente, lo split-DNS è il valore predefinito migliore: mantiene i nomi Internet ordinari sul resolver di cui la macchina si fida già. Per una macchina che esiste per raggiungere i servizi di casa, spingere il resolver è più semplice e il costo dell'ambito non conta.

Pubblicate il record sul resolver che possiede la zona

Tenete separati i ruoli prima di scrivere la configurazione: l'indirizzo del client VPN, il resolver e il servizio sono tre host diversi con tre compiti diversi. In questo laboratorio sono 10.77.0.2 per il client, 192.168.50.53 per dnsmasq e 192.168.50.20 per il NAS, con il tunnel che instrada la LAN di casa.

listen-address=127.0.0.1,192.168.50.53
bind-interfaces
local=/home.arpa/
host-record=nas.home.arpa,192.168.50.20

La riga host-record fornisce l'indirizzo e la riga local= tiene le domande sconosciute su home.arpa dentro questo resolver invece di inoltrarle a monte. Leggete prima la vostra configurazione esistente e riconciliate tutto ciò che già definisce un server, un'interfaccia o lo stesso dominio locale; impilare un frammento su uno in conflitto produce un resolver che si carica felicemente e risponde male. Il manuale di dnsmasq definisce entrambe le direttive e i controlli di ascolto.

Poi verificate il servizio in esecuzione, non il file. Un test di configurazione più un riavvio è il minimo, e la risposta effettiva è ciò che restituisce una query.

Instradate il resolver, non solo la pagina web

L'AllowedIPs di WireGuard decide quali destinazioni entrano nel tunnel. Se l'indirizzo del resolver cade fuori, la query esce dalla rotta normale e non raggiunge mai dnsmasq, anche se il NAS stesso è raggiungibile. Includete l'indirizzo del resolver, o il prefisso LAN che lo contiene, e controllate la politica di inoltro del gateway dall'altra parte.

Consentite UDP e TCP sulla porta 53 dall'intervallo di tunnel autorizzato, con un percorso di ritorno verso l'indirizzo di tunnel del client. Non inoltrate la porta 53 dalla WAN per facilitare i test: un resolver ricorsivo aperto su una connessione domestica viene trovato nel giro di ore. Il binding a un'interfaccia non è di per sé una politica di accesso.

Controllate la risposta prima dell'applicazione

Interrogate prima il resolver direttamente, poi il sistema, poi l'applicazione. Ogni passo isola un anello della catena, e la differenza tra loro è la diagnosi.

dig @192.168.50.53 nas.home.arpa. A
dig +tcp @192.168.50.53 nas.home.arpa. A
getent ahostsv4 nas.home.arpa
curl -sS --max-time 5 http://nas.home.arpa/ -o /dev/null -w '%{http_code}\n'

Vale la pena eseguire la query TCP perché una risposta UDP troncata impone un nuovo tentativo, e una politica che scarta TCP 53 produce guasti che sembrano intermittenti. Il passo getent mostra cosa fa realmente la configurazione del resolver della macchina, che non è sempre ciò che avete spinto.

Decidete cosa succede quando il tunnel è giù

Se il DNS generale del client punta a 192.168.50.53, ogni risoluzione dei nomi smette di funzionare quando il tunnel non è attivo. È accettabile su una macchina utile solo con il tunnel, e inaccettabile su un portatile che usa anche il Wi-Fi di un bar. Lo split-DNS evita del tutto la questione, perché solo le ricerche di home.arpa dipendono dal resolver di casa.

Ricordate cos'è il nome: home.arpa è riservato alle reti residenziali e non è univoco a livello globale, quindi un'altra rete può usare legittimamente lo stesso nome. È una comodità locale, non un identificatore affidabile. Mantenete il record aggiornato quando il servizio si sposta, e rimuovete la politica del resolver quando il laboratorio viene dismesso invece di lasciare un portatile che punta a un indirizzo che può raggiungere solo attraverso un tunnel che non esiste più.