WireGuard no empeny DNS: servir una zona BIND privada
L'apretada de mans porta claus i IP permeses, mai un resolutor. Aquí tens una zona BIND 9 privada ja resolta més la política de client per enllaç que la fa resoldre.
Has aixecat WireGuard, el túnel passa trànsit i el nom intern encara no es resol. El següent moviment sol ser buscar un paràmetre DNS a la configuració de WireGuard, com si un pare pogués empènyer un resolutor tal com fan algunes altres VPN. No pot. L'apretada de mans porta claus, adreces d'interfície i IP permeses, i no té cap camp per a servidors DNS ni dominis de cerca. La política de resolutor viu al client, i és aquí on pertany la correcció.
El túnel i el resolutor són contractes separats
WireGuard és petit a propòsit. Mou paquets per a les adreces que llistes i autentica els parells; tot el que hi ha per sobre d'aquesta capa és el teu disseny. OpenVPN pot empènyer un dhcp-option DNS perquè el seu canal de control porta configuració, i aquesta diferència desconcerta qui es mou entre els dos.
Així, un túnel que funciona no et diu res sobre la resolució de noms. El client pot tenir una ruta perfecta cap a 10.90.0.1 i encara enviar les consultes a un resolutor públic, i per això el símptoma sembla “la VPN ha trencat el DNS” quan en realitat el DNS mai no s'havia apuntat a la VPN.
Serveix la zona sense convertir-te en un resolutor recursiu
El costat del servidor és una zona autoritativa petita, no un resolutor general. En aquest exemple la passarel·la és 10.90.0.1, els clients són 10.90.0.0/24, i l'aplicació que t'importa respon a 10.60.0.20.
Fusiona aquests paràmetres amb el bloc options existent en lloc de crear-ne un segon:
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;
};Després declara la zona i el seu fitxer:
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.20Valida abans de recarregar, perquè un error de sintaxi en recarregar tomba tot el servidor per a cada zona que serveix:
named-checkconf
named-checkzone corp.example /etc/bind/db.corp.exampleObre UDP i TCP 53 només a la interfície VPN. Publicar una autoritat privada a la interfície pública convida tant consultes com enumeració, i allow-transfer ha de romandre tancat tret que un secundari realment el necessiti.
Apunta-hi el client, per enllaç
Suposa que NetworkManager posseeix la connexió i que systemd-resolved és el resolutor. Llegeix primer la política existent, sobretot qualsevol domini d'encaminament arrel, perquè una entrada ~. superarà el que estàs a punt d'afegir.
nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'La titlla és el caràcter important. Marca el domini com a només-ruta: els noms sota corp.example van al servidor DNS d'aquest enllaç, i el domini no s'afegeix com a sufix de cerca de nom curt. Sense ella, escriure portal comença a resoldre portal.corp.example, cosa que és convenient per a tu i sorprenent per a tothom. Mantingues la titlla dins les cometes, perquè una de no entre cometes és una expansió del shell que espera apuntar al teu directori personal.
Aplica el canvi a través del gestor que posseeix la interfície, i després reconnecta la connexió. No iniciïs una segona instància de wg-quick per a la mateixa interfície; dos propietaris es barallaran per les rutes i un d'ells guanyarà en el pitjor moment.
Verifica el camí abans del nom
Consulta el nom des del client i confirma tant la resposta com el servidor que l'ha produïda:
resolvectl query portal.corp.exampleSi això retorna 10.60.0.20, el contracte DNS està fet. Si expira, comprova primer la ruta cap a 10.90.0.1, després la regla de tallafocs, i després allow-query al servidor. Els errors de resolució de noms en aquesta configuració són gairebé sempre abastabilitat o una ACL, no el fitxer de zona. Treballa cap enfora des del client, perquè el servidor no et pot dir per què una consulta no ha arribat mai.
Recorda que l'aplicació encara necessita la seva pròpia ruta i el seu propi permís de servei. Un nom resolt que apunta a una adreça inabastable és una altra fallada amb la mateixa roba.
Què encara no és automàtic
Les aplicacions amb lògica de resolutor pròpia ignoren del tot el resolutor del sistema, i cap quantitat de nmcli ho canvia. Els desplegaments que validen DNSSEC necessiten un disseny explícit d'àncora de confiança per a la zona privada; la resposta no és una instrucció genèrica de desactivar la validació. Prova amb el mateix programari client que fan servir els teus usuaris, no amb una eina que casualment faci servir el resolutor del sistema. La diferència entre tots dos és tot l'informe d'error.
Les flotes poden automatitzar aquesta política de client a través del seu sistema d'aprovisionament, però la política continua sent un objecte separat amb un propietari. La referència de BIND 9 cobreix els controls d'escolta i de consulta emprats més amunt, i és el lloc correcte per confirmar el comportament per a la versió que tens instal·lada.
Següent pas: afegeix l'increment del número de sèrie de la zona i les ordres de comprovació al teu procediment de canvis, perquè una edició de registre no pugui arribar a producció sense revisar.