WireGuard neposúva DNS: obsluha privátnej zóny BIND

Rukovanie prenáša kľúče a povolené IP adresy, nikdy resolvér. Tu je hotová privátna zóna BIND 9 a klientska politika pre každé spojenie, ktorá ju nechá prekladať.

Zvýšili ste WireGuard, tunel prepúšťa prevádzku a interné meno sa stále neprekladá. Ďalším krokom zvyčajne býva hľadanie nastavenia DNS v konfigurácii WireGuard, akoby partner mohol pretlačiť resolvér tak, ako to robia iné VPN. Nemôže. Rukovanie prenáša kľúče, adresy rozhrania a povolené IP adresy a nemá pole pre DNS servery ani domény hľadania. Politika resolvéra žije na klientovi a tam patrí aj oprava.

Tunel a resolvér sú dve oddelené zmluvy

WireGuard je zámerne malý. Presúva pakety pre adresy, ktoré uvediete, a autentizuje peerov; všetko nad tou vrstvou je váš návrh. OpenVPN dokáže pretlačiť dhcp-option DNS, pretože jeho riadiaci kanál prenáša konfiguráciu, a tento rozdiel potkýna ľudí, ktorí prechádzajú medzi oboma.

Fungujúci tunel vám teda o preklade mien nepovie nič. Klient môže mať dokonalú trasu k 10.90.0.1 a napriek tomu posielať dopyty verejnému resolvéru, a preto symptóm vyzerá ako “VPN pokazila DNS”, hoci DNS na VPN nikdy nesmeroval.

Obslúžte zónu bez toho, aby ste sa stali rekurzívnym resolvérom

Strana servera je malá autoritatívna zóna, nie všeobecný resolvér. V tomto príklade je brána 10.90.0.1, klienti sú 10.90.0.0/24 a aplikácia, na ktorej vám záleží, odpovedá na 10.60.0.20.

Zlúčte tieto nastavenia do existujúceho bloku options namiesto vytvárania druhého:

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

Potom deklarujte zónu a jej súbor:

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

Pred opätovným načítaním validujte, pretože syntaktická chyba pri načítaní zhodí celý server pre každú zónu, ktorú obsluhuje:

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

Otvorte UDP a TCP 53 len na rozhraní VPN. Zverejnenie privátnej autority na verejnom rozhraní pozýva dopyty aj výpis, a allow-transfer by malo zostať zatvorené, ak sekundárny naozaj nepotrebuje.

Nasmerujte klienta na ňu, pre každé spojenie

Predpokladajte, že spojenie vlastní NetworkManager a resolvérom je systemd-resolved. Najprv si prečítajte existujúcu politiku, najmä akúkoľvek koreňovú doménu smerovania, pretože záznam ~. preváži to, čo sa chystáte pridať.

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

Vlnka je ten dôležitý znak. Označuje doménu ako iba-smerovaciu: mená pod corp.example idú na DNS server tohto spojenia a doména sa nepripája ako prípona hľadania krátkych mien. Bez nej začne písanie portal prekladať portal.corp.example, čo je pohodlné pre vás a prekvapivé pre všetkých ostatných. Vlnku držte v úvodzovkách, pretože neocitovaná je expanzia shellu, ktorá čaká, kým ukáže na váš domovský adresár.

Zmenu aplikujte cez správcu, ktorý rozhranie vlastní, a potom spojenie znova pripojte. Nespúšťajte druhú inštanciu wg-quick pre to isté rozhranie; dvaja vlastníci sa budú hádať o trasy a jeden z nich vyhrá v najhoršej chvíli.

Overte cestu skôr než meno

Opýtajte sa na meno z klienta a potvrďte aj odpoveď, aj server, ktorý ju vydal:

resolvectl query portal.corp.example

Ak to vráti 10.60.0.20, DNS zmluva je splnená. Ak to vyprší, skontrolujte najprv trasu k 10.90.0.1, potom pravidlo firewallu a potom allow-query na serveri. Zlyhania prekladu mien v tomto usporiadaní sú takmer vždy dostupnosť alebo ACL, nie zónový súbor. Pracujte od klienta von, pretože server vám nemôže povedať, prečo dopyt nikdy nedorazil.

Pamätajte, že aplikácia stále potrebuje vlastnú trasu a vlastné povolenie služby. Preložené meno ukazujúce na nedostupnú adresu je iná porucha v tom istom kabáte.

Čo stále nie je automatické

Aplikácie s vlastnou logikou resolvéra ignorujú systémový resolvér úplne a žiadne množstvo nmcli to nezmení. Nasadenia, ktoré validujú DNSSEC, potrebujú výslovný návrh dôveryhodnej kotvy pre privátnu zónu; odpoveďou nie je plošný pokyn vypnúť validáciu. Testujte rovnakým klientskym softvérom, ktorý používajú vaši používatelia, nie nástrojom, ktorý náhodou používa systémový resolvér. Rozdiel medzi tými dvoma je celé hlásenie o chybe.

Flotily môžu túto klientsku politiku automatizovať cez svoj systém zriaďovania, ale politika zostáva samostatný objekt s vlastníkom. Referenčná príručka BIND 9 pokrýva ovládanie počúvania a dopytov použité vyššie a je správnym miestom na potvrdenie správania pre vašu nainštalovanú verziu.

Ďalší krok: pridajte zvýšenie sériového čísla zóny a kontrolné príkazy do svojho postupu zmien, aby sa úprava záznamu nemohla dostať do produkcie neoverená.

Súvisiace články