WireGuard non spinge il DNS: servire una zona BIND privata

Lo handshake trasporta chiavi e IP consentiti, mai un resolver. Ecco una zona BIND 9 privata già pronta più la politica client per collegamento che la fa risolvere.

Avete alzato WireGuard, il tunnel fa passare traffico, e il nome interno continua a non risolversi. Il passo successivo di solito è cercare un'impostazione DNS nella configurazione di WireGuard, come se un peer potesse spingere un resolver come fanno altre VPN. Non può. Lo handshake trasporta chiavi, indirizzi di interfaccia e IP consentiti, e non ha alcun campo per server DNS o domini di ricerca. La politica del resolver vive sul client, ed è lì che va la correzione.

Il tunnel e il resolver sono contratti separati

WireGuard è piccolo di proposito. Sposta pacchetti per gli indirizzi che elencate e autentica i peer; tutto ciò che sta sopra quello strato è il vostro progetto. OpenVPN può spingere un dhcp-option DNS perché il suo canale di controllo trasporta configurazione, e questa differenza fa inciampare chi passa dall'uno all'altro.

Un tunnel che funziona quindi non dice nulla sulla risoluzione dei nomi. Il client può avere una rotta perfetta verso 10.90.0.1 e comunque inviare le sue query a un resolver pubblico, ed è per questo che il sintomo sembra “la VPN ha rotto il DNS” quando in realtà il DNS non era mai stato puntato alla VPN.

Servite la zona senza diventare un resolver ricorsivo

Il lato server è una piccola zona autoritativa, non un resolver generico. In questo esempio il gateway è 10.90.0.1, i client sono 10.90.0.0/24, e l'applicazione che vi interessa risponde su 10.60.0.20.

Unite queste impostazioni nel blocco options esistente invece di crearne un secondo:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Poi dichiarate la zona e il suo file:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

Validate prima di ricaricare, perché un errore di sintassi al ricaricamento abbatte l'intero server per ogni zona che serve:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

Aprite UDP e TCP 53 solo sull'interfaccia VPN. Pubblicare un'autorità privata sull'interfaccia pubblica invita sia query sia enumerazione, e allow-transfer dovrebbe restare chiuso a meno che un secondario ne abbia davvero bisogno.

Puntate il client lì, per collegamento

Supponete che NetworkManager possieda la connessione e che systemd-resolved sia il resolver. Leggete prima la politica esistente, soprattutto un eventuale dominio di routing radice, perché una voce ~. supererà ciò che state per aggiungere.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

La tilde è il carattere importante. Marca il dominio come solo-rotta: i nomi sotto corp.example vanno al server DNS di questo collegamento, e il dominio non viene aggiunto come suffisso di ricerca per nomi brevi. Senza di essa, digitare portal inizia a risolvere portal.corp.example, cosa comoda per voi e sorprendente per tutti gli altri. Tenete la tilde tra virgolette, perché una senza virgolette è un'espansione della shell che attende di puntare alla vostra directory home.

Applicate la modifica tramite il gestore che possiede l'interfaccia, poi ricollegate la connessione. Non avviate una seconda istanza di wg-quick per la stessa interfaccia; due proprietari litigheranno sulle rotte e uno dei due vincerà nel momento peggiore.

Verificate il percorso prima del nome

Interrogate il nome dal client e confermate sia la risposta sia il server che l'ha prodotta:

resolvectl query portal.corp.example

Se questo restituisce 10.60.0.20, il contratto DNS è soddisfatto. Se va in timeout, controllate prima la rotta verso 10.90.0.1, poi la regola del firewall, poi allow-query sul server. I fallimenti di risoluzione in questa configurazione sono quasi sempre raggiungibilità o una ACL, non il file di zona. Lavorate dal client verso l'esterno, perché il server non può dirvi perché una query non è mai arrivata.

Ricordate che l'applicazione ha ancora bisogno della propria rotta e del proprio permesso di servizio. Un nome risolto che punta a un indirizzo irraggiungibile è un altro guasto con gli stessi panni.

Ciò che non è ancora automatico

Le applicazioni con una propria logica di risoluzione ignorano del tutto il resolver di sistema, e nessuna quantità di nmcli cambia questo. Le installazioni che validano DNSSEC hanno bisogno di un progetto esplicito di trust anchor per la zona privata; la risposta non è un'istruzione generale a disattivare la validazione. Fate test con lo stesso software client che eseguono i vostri utenti, non con uno strumento che usa per caso il resolver di sistema. La distanza tra i due è tutto il bug report.

Le flotte possono automatizzare questa politica client tramite il loro sistema di provisioning, ma la politica resta un oggetto separato con un proprietario. La referenza di BIND 9 copre i controlli di ascolto e di query usati sopra, ed è il posto giusto per confermare il comportamento per la versione installata.

Passo successivo: aggiungete l'incremento del numero di serie della zona e i comandi di controllo alla vostra procedura di cambiamento, così che una modifica a un record non possa arrivare in produzione senza verifica.

Articoli correlati