WireGuard duwt geen DNS: een privé-BIND-zone bedienen

De handshake draagt sleutels en toegestane IP's, nooit een resolver. Hier is een uitgewerkte privé-BIND 9-zone plus het clientbeleid per link dat hem laat resolveren.

Je hebt WireGuard opgezet, de tunnel laat verkeer door, en de interne naam resolvet nog steeds niet. De volgende stap is meestal zoeken naar een DNS-instelling in de WireGuard-configuratie, alsof een peer een resolver kan duwen zoals sommige andere VPN's doen. Dat kan niet. De handshake draagt sleutels, interfaceadressen en toegestane IP's, en heeft geen veld voor DNS-servers of zoekdomeinen. Resolverbeleid woont op de client, en daar hoort de correctie.

De tunnel en de resolver zijn aparte contracten

WireGuard is bewust klein. Het verplaatst pakketten voor de adressen die je opgeeft en authenticeert peers; alles boven die laag is jouw ontwerp. OpenVPN kan een dhcp-option DNS duwen omdat het controlekanaal configuratie draagt, en dat verschil struikelt mensen die tussen de twee wisselen.

Een werkende tunnel zegt dus niets over naamresolutie. De client kan een perfecte route naar 10.90.0.1 hebben en zijn queries nog steeds naar een publieke resolver sturen, waardoor het symptoom lijkt op “de VPN heeft DNS gesloopt” terwijl DNS nooit naar de VPN wees.

Bedien de zone zonder een recursieve resolver te worden

De serverkant is een kleine autoritatieve zone, geen algemene resolver. In dit voorbeeld is de gateway 10.90.0.1, zijn de clients 10.90.0.0/24, en antwoordt de applicatie die je belangrijk vindt op 10.60.0.20.

Voeg deze instellingen samen in het bestaande options-blok in plaats van een tweede te maken:

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 daarna de zone en het bestand:

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 je herlaadt, want een syntaxisfout bij het herladen haalt de hele server neer voor elke zone die hij bedient:

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

Open UDP en TCP 53 alleen op de VPN-interface. Een privé-autoriteit publiceren op de publieke interface nodigt zowel queries als enumeratie uit, en allow-transfer kan beter dicht blijven tenzij een secundaire het echt nodig heeft.

Wijs de client erop, per link

Neem aan dat NetworkManager de verbinding bezit en dat systemd-resolved de resolver is. Lees eerst het bestaande beleid, vooral een eventueel root-routingdomein, want een ~.-vermelding gaat vóór wat je gaat toevoegen.

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

De tilde is het belangrijkste teken. Hij markeert het domein als alleen-route: namen onder corp.example gaan naar de DNS-server van deze link, en het domein wordt niet toegevoegd als zoekachtervoegsel voor korte namen. Zonder tilde begint het typen van portal portal.corp.example te resolven, wat handig is voor jou en verrassend voor iedereen. Houd de tilde binnen de aanhalingstekens, want een zonder aanhalingstekens is een shell-expansie die staat te wachten om naar je thuismap te wijzen.

Pas de wijziging toe via de beheerder die de interface bezit, en verbind daarna de verbinding opnieuw. Start geen tweede wg-quick-instantie voor dezelfde interface; twee eigenaren vechten om routes en een van hen wint op het slechtste moment.

Verifieer het pad vóór de naam

Vraag de naam op vanaf de client en bevestig zowel het antwoord als de server die het produceerde:

resolvectl query portal.corp.example

Als dat 10.60.0.20 teruggeeft, is het DNS-contract vervuld. Als het een time-out geeft, controleer dan eerst de route naar 10.90.0.1, dan de firewallregel, dan allow-query op de server. Naamresolutiefouten in deze opzet zijn bijna altijd bereikbaarheid of een ACL, niet het zonebestand. Werk van de client naar buiten, want de server kan je niet vertellen waarom een query nooit aankwam.

Onthoud dat de applicatie nog steeds zijn eigen route en zijn eigen diensttoestemming nodig heeft. Een geresolvede naam die naar een onbereikbaar adres wijst is een andere storing in dezelfde kleren.

Wat nog steeds niet automatisch is

Applicaties met hun eigen resolverlogica negeren de systeemresolver volledig, en geen enkele hoeveelheid nmcli verandert dat. Implementaties die DNSSEC valideren hebben een expliciet ontwerp van een trust anchor voor de privé-zone nodig; het antwoord is geen algemene instructie om validatie uit te schakelen. Test met dezelfde clientsoftware die je gebruikers draaien, niet met een hulpmiddel dat toevallig de systeemresolver gebruikt. Het gat tussen die twee is het hele bugrapport.

Vloten kunnen dit clientbeleid automatiseren via hun provisioning-systeem, maar het beleid blijft een apart object met een eigenaar. De BIND 9-referentie behandelt de luister- en querybesturingen hierboven, en het is de juiste plek om gedrag voor je geïnstalleerde versie te bevestigen.

Volgende stap: voeg de verhoging van het serienummer van de zone en de controlecommando's toe aan je wijzigingsprocedure, zodat een recordwijziging ongecontroleerd productie niet kan bereiken.

Gerelateerde artikelen