WireGuard stuur nie DNS nie: hoe om 'n private BIND-sone te bedien

Die handskud dra sleutels en toegelate IP's, nooit 'n resolver nie. Hier is 'n uitgewerkte private BIND 9-sone plus die kliëntbeleid per skakel wat dit laat oplos.

Jy het WireGuard opgestel, die tonnel stuur verkeer deur, en die interne naam los steeds nie op nie. Die volgende stap is gewoonlik om na 'n DNS-instelling in die WireGuard-konfigurasie te soek, asof 'n peer 'n resolver kan stoot soos sommige ander VPN's doen. Dit kan nie. Die handskud dra sleutels, koppelvlakadresse en toegelate IP's, en dit het geen veld vir DNS-bediener of soekdomeine nie. Resolver-beleid woon op die kliënt, en dit is waar die regstelling hoort.

Die tonnel en die resolver is aparte kontrakte

WireGuard is doelbewus klein. Dit beweeg pakkette vir die adresse wat jy lys en dit verifieer peers; alles bo daardie laag is jou ontwerp. OpenVPN kan 'n dhcp-option DNS stoot omdat sy beheerkanaal konfigurasie dra, en daardie verskil laat mense struikel wat tussen die twee beweeg.

Dus 'n werkende tonnel sê niks oor naamresolusie nie. Die kliënt kan 'n perfekte roete na 10.90.0.1 hê en steeds sy navrae na 'n publieke resolver stuur, en daarom lyk die simptoom soos “die VPN het DNS gebreek” terwyl DNS nooit na die VPN gewys is nie.

Bedien die sone sonder om 'n rekursiewe resolver te word

Die bedienerkant is 'n klein gesaghebbende sone, nie 'n algemene resolver nie. In hierdie voorbeeld is die gateway 10.90.0.1, kliënte is 10.90.0.0/24, en die toepassing waarvoor jy sorg antwoord op 10.60.0.20.

Voeg hierdie instellings by die bestaande options-blok eerder as om 'n tweede een te skep:

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

Verklaar dan die sone en sy lêer:

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

Valideer voordat jy herlaai, want 'n sintaksfout tydens herlaai neem die hele bediener af vir elke sone wat dit bedien:

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

Maak UDP en TCP 53 net op die VPN-koppelvlak oop. Om 'n private gesag op die publieke koppelvlak te publiseer, nooi beide navrae en enumerasie uit, en allow-transfer moet gesluit bly tensy 'n sekondêre dit werklik nodig het.

Wys die kliënt daarheen, per skakel

Aanvaar NetworkManager besit die verbinding en systemd-resolved is die resolver. Lees eers die bestaande beleid, veral enige wortelroeteringsdomein, want 'n ~.-inskrywing sal voorrang kry bo wat jy op die punt is om by te voeg.

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

Die tilde is die belangrike karakter. Dit merk die domein as slegs-roete: name onder corp.example gaan na hierdie skakel se DNS-bediener, en die domein word nie as 'n kortnaam-soekagtervoegsel bygevoeg nie. Sonder dit begin die tik van portal om portal.corp.example op te los, wat gerieflik vir jou is en verrassend vir almal anders. Hou die tilde binne die aanhalingstekens, want een sonder aanhalingstekens is 'n dop-uitbreiding wat daarop wag om na jou tuisgids te wys.

Pas die verandering toe deur die bestuurder wat die koppelvlak besit, en herverbind dan die verbinding. Moenie 'n tweede wg-quick-instansie vir dieselfde koppelvlak begin nie; twee eienaars sal oor roetes veg en een van hulle sal op die slegste oomblik wen.

Verifieer die pad voor die naam

Vra die naam by die kliënt en bevestig beide die antwoord en die bediener wat dit gelewer het:

resolvectl query portal.corp.example

As dit 10.60.0.20 teruggee, is die DNS-kontrak klaar. As dit uittyd, kontroleer eers die roete na 10.90.0.1, dan die firewall-reël, dan allow-query op die bediener. Naamresolusie-foute in hierdie opstelling is byna altyd bereikbaarheid of 'n ACL, nie die sone-lêer nie. Werk van die kliënt af uitwaarts, want die bediener kan jou nie sê waarom 'n navraag nooit aangekom het nie.

Onthou die toepassing het steeds sy eie roete en sy eie diensreg nodig. 'n Opgeloste naam wat na 'n onbereikbare adres wys, is 'n ander fout in dieselfde klere.

Wat steeds nie outomaties is nie

Toepassings met hul eie resolver-logika ignoreer die stelselresolver heeltemal, en geen hoeveelheid nmcli verander dit nie. Ontplooiings wat DNSSEC valideer, het 'n eksplisiete trust anchor-ontwerp vir die private sone nodig; die antwoord is nie 'n algemene opdrag om validering af te skakel nie. Toets met dieselfde kliëntsagteware wat jou gebruikers gebruik, nie met 'n hulpmiddel wat toevallig die stelselresolver gebruik nie. Die gaping tussen daardie twee is die hele foutverslag.

Vlote kan hierdie kliëntbeleid deur hul voorsieningstelsel outomatiseer, maar die beleid bly 'n aparte objek met 'n eienaar. Die BIND 9-verwysing dek die luisteraars en navraagkontroles hierbo gebruik, en dit is die regte plek om gedrag vir jou geïnstalleerde weergawe te bevestig.

Volgende stap: voeg die sone se serienommer-verhoging en die kontrole-opdragte by jou veranderingsprosedure, sodat 'n rekordwysiging nie ongemerk produksie kan bereik nie.

Verwante artikels