WireGuard sender ikke DNS: betjening af en privat BIND-zone

Håndtrykket bærer nøgler og tilladte IP'er, aldrig en resolver. Her er en gennemarbejdet privat BIND 9-zone plus klientpolitikken pr. link, der får den til at slå op.

Du har rejst WireGuard, tunnelen sender trafik, og det interne navn slår stadig ikke op. Det næste træk er som regel at lede efter en DNS-indstilling i WireGuard-konfigurationen, som om en peer kunne skubbe en resolver ud, ligesom nogle andre VPN'er gør. Det kan den ikke. Håndtrykket bærer nøgler, interface-adresser og tilladte IP'er, og det har intet felt til DNS-servere eller søgedomæner. Resolverpolitik ligger på klienten, og det er der, rettelsen hører hjemme.

Tunnelen og resolveren er separate kontrakter

WireGuard er med vilje lille. Det flytter pakker for de adresser, du angiver, og autentificerer peers; alt over det lag er dit design. OpenVPN kan skubbe en dhcp-option DNS ud, fordi dens kontrolkanal bærer konfiguration, og den forskel snubler folk, der flytter mellem de to.

En fungerende tunnel fortæller altså intet om navneopløsning. Klienten kan have en perfekt rute til 10.90.0.1 og stadig sende sine forespørgsler til en offentlig resolver, og derfor ser symptomet ud som “VPN'en ødelagde DNS”, selvom DNS aldrig blev peget mod VPN'en.

Betjen zonen uden at blive en rekursiv resolver

Serversiden er en lille autoritativ zone, ikke en generel resolver. I dette eksempel er gatewayen 10.90.0.1, klienterne er 10.90.0.0/24, og applikationen, du bekymrer dig om, svarer på 10.60.0.20.

Flet disse indstillinger ind i den eksisterende options-blok i stedet for at oprette 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;
};

Deklarér derefter zonen og dens 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

Validér før du genindlæser, for en syntaksfejl ved genindlæsning tager hele serveren ned for hver zone, den betjener:

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

Åbn UDP og TCP 53 kun mod VPN-interfacet. At udgive en privat autoritet på det offentlige interface indbyder både forespørgsler og optælling, og allow-transfer bør forblive lukket, medmindre en sekundær virkelig har brug for det.

Peg klienten mod den, pr. link

Antag, at NetworkManager ejer forbindelsen, og at systemd-resolved er resolveren. Læs den eksisterende politik først, især et eventuelt rodrutningsdomæne, for en ~.-post vil overgå det, du er ved at tilføje.

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

Tilden er det vigtige tegn. Den markerer domænet som kun-rute: navne under corp.example går til dette links DNS-server, og domænet tilføjes ikke som suffiks til søgning af korte navne. Uden den begynder skrivning af portal at slå portal.corp.example op, hvilket er bekvemt for dig og overraskende for alle andre. Hold tilden inde i citationstegnene, for en uden citationstegn er en shell-ekspansion, der venter på at pege på din hjemmemappe.

Anvend ændringen via den manager, der ejer interfacet, og genopret derefter forbindelsen. Start ikke en anden wg-quick-instans til det samme interface; to ejere vil slås om ruterne, og en af dem vinder på det værst tænkelige tidspunkt.

Verificér ruten før navnet

Forespørg navnet fra klienten, og bekræft både svaret og den server, der gav det:

resolvectl query portal.corp.example

Hvis det returnerer 10.60.0.20, er DNS-kontrakten opfyldt. Hvis det timer ud, så tjek først ruten til 10.90.0.1, derefter firewall-reglen, derefter allow-query på serveren. Fejl i navneopløsning i dette setup er næsten altid rækkevidde eller en ACL, ikke zonefilen. Arbejd udad fra klienten, for serveren kan ikke fortælle dig, hvorfor en forespørgsel aldrig nåede frem.

Husk, at applikationen stadig har brug for sin egen rute og sin egen servicetilladelse. Et opløst navn, der peger på en uopnåelig adresse, er en anden fejl i de samme klæder.

Hvad stadig ikke er automatisk

Applikationer med deres egen resolverlogik ignorerer systemets resolver helt, og ingen mængde nmcli ændrer det. Installationer, der validerer DNSSEC, har brug for et eksplicit design af tillidsanker til den private zone; svaret er ikke en blanket instruks om at slå validering fra. Test med den samme klientsoftware, som dine brugere kører, ikke med et værktøj, der tilfældigvis bruger systemets resolver. Kløften mellem de to er hele fejlrapporten.

Flåder kan automatisere denne klientpolitik via deres provisioning-system, men politikken forbliver et separat objekt med en ejer. BIND 9-reference dækker de lytter- og forespørgselsindstillinger, der bruges ovenfor, og det er det rigtige sted at bekræfte adfærden for din installerede version.

Næste skridt: føj zonens serienummerforhøjelse og kontrolkommandoerne til din ændringsprocedure, så en postredigering ikke kan nå produktion uden kontrol.

Relaterede artikler