WireGuard sender ikkje DNS: tena ei privat BIND-sone

Handtrykket ber nøklar og tillatne IP-ar, aldri ein resolvar. Her er ei ferdig privat BIND 9-sone pluss klientpolitikken per lenkje som får ho til å slå opp.

Du har reist WireGuard, tunnelen slepp trafikk gjennom, og det interne namnet slår framleis ikkje opp. Neste trekk er vanlegvis å leite etter ei DNS-innstilling i WireGuard-konfigurasjonen, som om ein peer kunne skyve ein resolvar ut slik nokre andre VPN gjer. Det kan han ikkje. Handtrykket ber nøklar, grensesnittadresser og tillatne IP-ar, og det har ingen felt for DNS-tenarar eller søkjedomene. Resolvarpolitikken bur på klienten, og det er der rettinga høyrer heime.

Tunnelen og resolvaren er separate kontraktar

WireGuard er med vilje lite. Det flyttar pakkar for adressene du listar opp og autentiserer peerar; alt over det laget er ditt design. OpenVPN kan skyve ut ein dhcp-option DNS fordi kontrollkanalen ber konfigurasjon, og den skilnaden snublar folk som flyttar seg mellom dei to.

Ein fungerande tunnel seier altså ingenting om namneoppslag. Klienten kan ha ei perfekt rute til 10.90.0.1 og likevel sende spørjefrågå til ein offentleg resolvar, og difor ser symptomet ut som “VPN-en øydela DNS”, sjølv om DNS aldri vart peika mot VPN-en.

Ten sone utan å bli ein rekursiv resolvar

Tenarsida er ei lita autoritativ sone, ikkje ein generell resolvar. I dette dømet er gatewayen 10.90.0.1, klientane er 10.90.0.0/24, og applikasjonen du bryr deg om svarar på 10.60.0.20.

Flett desse innstillingane inn i den eksisterande options-blokka i staden for å lage ei 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;
};

Deretter erklærer du sona og fila hennar:

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 lastar på nytt, for ein syntaksfeil ved lasting tek ned heile tenaren for kvar sone han tener:

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

Opne UDP og TCP 53 berre mot VPN-grensesnittet. Å publisere ein privat autoritet på det offentlege grensesnittet inviterer både spørjefrågå og utlisting, og allow-transfer bør halde seg stengd med mindre ein sekundær verkeleg treng det.

Pek klienten mot ho, per lenkje

Gå ut frå at NetworkManager eig tilkoplinga og at systemd-resolved er resolvaren. Les den eksisterande politikken først, særleg eit eventuelt rot-rutedomene, for ein ~.-oppføring vil gå framom det du er i ferd med å leggje 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 teiknet. Han merkar domenet som berre-rute: namn under corp.example går til DNS-tenaren for denne lenkja, og domenet vert ikkje lagt til som suffiks for søk på korte namn. Utan han byrjar skriving av portal å slå opp portal.corp.example, noko som er praktisk for deg og overraskande for alle andre. Hald tilden inne i hermeteikna, for ein utan hermeteikn er ei skal-utviding som ventar på å peike på heimemappa di.

Bruk endringa via behandlaren som eig grensesnittet, og kople deretter tilkoplinga på nytt. Ikkje start ein annan wg-quick-instans for same grensesnitt; to eigarar vil slåst om ruter, og ein av dei vinn på det verste tidspunktet.

Stadfest ruta før namnet

Spør tenaren om namnet frå klienten og stadfest både svaret og tenaren som produserte det:

resolvectl query portal.corp.example

Viss det returnerer 10.60.0.20, er DNS-kontrakten oppfylt. Viss det fell på tid, sjekk først ruta til 10.90.0.1, deretter brannmurregelen, deretter allow-query på tenaren. Feil i namneoppslag i dette oppsettet er nesten alltid tilgjenge eller ein ACL, ikkje sonefila. Arbeid utover frå klienten, for tenaren kan ikkje fortelje deg kvifor ei spørjefråg aldri kom fram.

Hugs at applikasjonen framleis treng si eiga rute og si eiga tenesteløyve. Eit oppslått namn som peikar på ei utilgjengeleg adresse er ein annan feil i dei same kleda.

Kva som framleis ikkje er automatisk

Applikasjonar med eigen resolvarlogikk ignorerer systemresolvaren fullstendig, og inga mengd nmcli endrar det. Installasjonar som validerer DNSSEC treng eit eksplisitt design av tillitsanker for den private sona; svaret er ikkje ein generell instruks om å slå av validering. Test med same klientprogramvare som brukarane dine køyrer, ikkje med eit verktøy som tilfeldigvis brukar systemresolvaren. Gapet mellom dei to er heile feilrapporten.

Flåtar kan automatisere denne klientpolitikken gjennom provisjoneringssystemet sitt, men politikken er framleis eit separat objekt med ein eigar. BIND 9-referansen dekkjer lytt- og spørjeinnstillingane som er brukte ovanfor, og det er rett stad å stadfeste åtferd for den installerte versjonen din.

Neste steg: legg til auken av serienummeret til sona og kontrollkommandoane i endringsprosedyren din, slik at ei postredigering ikkje kan nå produksjon ukontrollert.

Relaterte artiklar