WireGuard sender ikke DNS: betjene en privat BIND-sone

Håndtrykket bærer nøkler og tillatte IP-er, aldri en resolver. Her er en ferdig privat BIND 9-sone pluss klientpolicyen per lenke som får den til å slå opp.

Du har reist WireGuard, tunnelen slipper trafikk gjennom, og det interne navnet slår fortsatt ikke opp. Neste trekk er vanligvis å lete etter en DNS-innstilling i WireGuard-konfigurasjonen, som om en peer kunne skyve en resolver ut slik noen andre VPN-er gjør. Det kan den ikke. Håndtrykket bærer nøkler, grensesnittadresser og tillatte IP-er, og det har ingen felt for DNS-servere eller søkedomener. Resolverpolicyen bor på klienten, og det er der rettelsen hører hjemme.

Tunnelen og resolveren er separate kontrakter

WireGuard er med vilje lite. Det flytter pakker for adressene du lister opp og autentiserer peers; alt over det laget er ditt design. OpenVPN kan skyve ut en dhcp-option DNS fordi kontrollkanalen bærer konfigurasjon, og den forskjellen snubler folk som beveger seg mellom de to.

En fungerende tunnel sier altså ingenting om navneoppslag. Klienten kan ha en perfekt rute til 10.90.0.1 og likevel sende spørringene sine til en offentlig resolver, og derfor ser symptomet ut som “VPN-en ødela DNS”, selv om DNS aldri ble pekt mot VPN-en.

Betjen sonen uten å bli en rekursiv resolver

Serversiden er en liten autoritativ sone, ikke en generell resolver. I dette eksempelet er gatewayen 10.90.0.1, klientene er 10.90.0.0/24, og applikasjonen du bryr deg om svarer på 10.60.0.20.

Flett disse innstillingene inn i den eksisterende options-blokken i stedet for å lage en ny:

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;
};

Deklarer deretter sonen og filen dens:

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

Valider før du laster på nytt, for en syntaksfeil ved lasting tar ned hele serveren for hver sone den betjener:

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

Åpne UDP og TCP 53 kun mot VPN-grensesnittet. Å publisere en privat autoritet på det offentlige grensesnittet inviterer både spørringer og utlisting, og allow-transfer bør forbli lukket med mindre en sekundær virkelig trenger det.

Pek klienten mot den, per lenke

Anta at NetworkManager eier tilkoblingen og at systemd-resolved er resolveren. Les den eksisterende policyen først, særlig et eventuelt rot-rutedomene, for en ~.-oppføring vil overgå det du er i ferd med å legge til.

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

Tilden er det viktige tegnet. Den markerer domenet som kun-rute: navn under corp.example går til DNS-serveren for denne lenken, og domenet legges ikke til som suffiks for søk på korte navn. Uten den begynner skriving av portal å slå opp portal.corp.example, noe som er praktisk for deg og overraskende for alle andre. Hold tilden inne i anførselstegnene, for en uten anførselstegn er en shell-utvidelse som venter på å peke på hjemmekatalogen din.

Bruk endringen via behandleren som eier grensesnittet, og koble deretter tilkoblingen på nytt. Ikke start en annen wg-quick-instans for samme grensesnitt; to eiere vil slåss om ruter, og en av dem vinner på det verste tidspunktet.

Verifiser ruten før navnet

Spør serveren om navnet fra klienten og bekreft både svaret og serveren som produserte det:

resolvectl query portal.corp.example

Hvis det returnerer 10.60.0.20, er DNS-kontrakten oppfylt. Hvis det timer ut, sjekk først ruten til 10.90.0.1, deretter brannmurregelen, deretter allow-query på serveren. Feil i navneoppslag i dette oppsettet er nesten alltid tilgjengelighet eller en ACL, ikke sonefilen. Arbeid utover fra klienten, for serveren kan ikke fortelle deg hvorfor en spørring aldri kom frem.

Husk at applikasjonen fortsatt trenger sin egen rute og sin egen tjenestetillatelse. Et oppslått navn som peker på en uoppnåelig adresse er en annen feil i de samme klærne.

Hva som fortsatt ikke er automatisk

Applikasjoner med egen resolverlogikk ignorerer systemresolveren fullstendig, og ingen mengde nmcli endrer det. Installasjoner som validerer DNSSEC trenger et eksplisitt design av tillitsanker for den private sonen; svaret er ikke en generell instruks om å slå av validering. Test med samme klientprogramvare som brukerne dine kjører, ikke med et verktøy som tilfeldigvis bruker systemresolveren. Gapet mellom de to er hele feilrapporten.

Flåter kan automatisere denne klientpolicyen gjennom provisjoneringssystemet sitt, men policyen forblir et separat objekt med en eier. BIND 9-referansen dekker lytte- og spørringsinnstillingene som er brukt ovenfor, og det er riktig sted å bekrefte atferden for din installerte versjon.

Neste steg: legg til økningen av sonens serienummer og kontrollkommandoene i endringsprosedyren din, slik at en postredigering ikke kan nå produksjon ukontrollert.

Relaterte artikler