WireGuard skickar inte DNS: att betjäna en privat BIND-zon

Handskakningen bär nycklar och tillåtna IP-adresser, aldrig en resolver. Här är en färdig privat BIND 9-zon plus klientpolicyn per länk som får den att slå upp.

Du har rest WireGuard, tunneln släpper igenom trafik, och det interna namnet slår fortfarande inte upp. Nästa drag är oftast att leta efter en DNS-inställning i WireGuard-konfigurationen, som om en peer kunde skjuta ut en resolver som vissa andra VPN gör. Det kan den inte. Handskakningen bär nycklar, gränssnittsadresser och tillåtna IP-adresser, och den har inget fält för DNS-servrar eller sökdomäner. Resolverpolicy bor på klienten, och det är där rättelsen hör hemma.

Tunneln och resolvern är separata avtal

WireGuard är medvetet litet. Det flyttar paket för adresserna du listar och autentiserar peers; allt ovanför det lagret är din design. OpenVPN kan skjuta ut en dhcp-option DNS eftersom dess kontrollkanal bär konfiguration, och den skillnaden snubblar folk som rör sig mellan de två.

En fungerande tunnel säger alltså ingenting om namnuppslagning. Klienten kan ha en perfekt rutt till 10.90.0.1 och ändå skicka sina frågor till en offentlig resolver, och därför ser symtomet ut som “VPN:en förstörde DNS” fast DNS aldrig pekades mot VPN:en.

Betjäna zonen utan att bli en rekursiv resolver

Serversidan är en liten auktoritativ zon, inte en allmän resolver. I det här exemplet är gatewayen 10.90.0.1, klienterna är 10.90.0.0/24, och programmet du bryr dig om svarar på 10.60.0.20.

Slå ihop de här inställningarna i det befintliga options-blocket i stället för att skapa ett nytt:

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

Deklarera sedan zonen och dess fil:

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

Validera innan du laddar om, för ett syntaxfel vid omladdning tar ner hela servern för varje zon den betjänar:

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

Öppna UDP och TCP 53 bara mot VPN-gränssnittet. Att publicera en privat auktoritet på det publika gränssnittet bjuder in både frågor och uppräkning, och allow-transfer bör förbli stängt om inte en sekundär verkligen behöver det.

Peka klienten mot den, per länk

Anta att NetworkManager äger anslutningen och att systemd-resolved är resolvern. Läs den befintliga policyn först, särskilt en eventuell rot-routingdomän, för en ~.-post kommer att gå före det du är på väg att lägga till.

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

Tilden är det viktiga tecknet. Den markerar domänen som endast-rutt: namn under corp.example går till DNS-servern för den här länken, och domänen läggs inte till som suffix för sökning på korta namn. Utan den börjar skrivandet av portal slå upp portal.corp.example, vilket är praktiskt för dig och förvånande för alla andra. Håll tilden innanför citattecknen, för en utan citattecken är en shell-expansion som väntar på att peka på din hemkatalog.

Tillämpa ändringen via hanteraren som äger gränssnittet och återanslut sedan anslutningen. Starta inte en andra wg-quick-instans för samma gränssnitt; två ägare kommer att slåss om rutter och en av dem vinner i det sämsta ögonblicket.

Verifiera vägen före namnet

Fråga efter namnet från klienten och bekräfta både svaret och servern som producerade det:

resolvectl query portal.corp.example

Om det returnerar 10.60.0.20 är DNS-avtalet uppfyllt. Om det tar timeout, kontrollera först rutten till 10.90.0.1, sedan brandväggsregeln, sedan allow-query på servern. Fel i namnuppslagning i den här uppsättningen är nästan alltid nåbarhet eller en ACL, inte zonfilen. Arbeta utåt från klienten, för servern kan inte berätta varför en fråga aldrig kom fram.

Kom ihåg att programmet fortfarande behöver sin egen rutt och sitt eget tjänstetillstånd. Ett uppslaget namn som pekar på en onåbar adress är ett annat fel i samma kläder.

Vad som fortfarande inte är automatiskt

Program med egen resolverlogik ignorerar systemresolvern helt, och ingen mängd nmcli ändrar det. Installationer som validerar DNSSEC behöver en uttrycklig design av trust anchor för den privata zonen; svaret är inte en allmän instruktion att stänga av valideringen. Testa med samma klientprogramvara som dina användare kör, inte med ett verktyg som råkar använda systemresolvern. Gapet mellan de två är hela felrapporten.

Flottor kan automatisera den här klientpolicyn via sitt provisioning-system, men policyn förblir ett separat objekt med en ägare. BIND 9-referensen täcker de lyssnings- och frågekontroller som används ovan, och det är rätt plats att bekräfta beteendet för din installerade version.

Nästa steg: lägg till zonens serienummerhöjning och kontrollkommandona i din ändringsprocedur, så att en postredigering inte kan nå produktion okontrollerad.

Relaterade artiklar