WireGuard neposílá DNS: jak obsloužit privátní zónu BIND

Rukování nese klíče a povolené IP adresy, nikdy resolver. Zde je hotová privátní zóna BIND 9 a klientská politika pro každé spojení, která ji nechá překládat.

Zvedli jste WireGuard, tunel propouští provoz a interní jméno se pořád nepřekládá. Dalším krokem obvykle bývá hledání nastavení DNS v konfiguraci WireGuard, jako by peer mohl protlačit resolver tak, jak to dělají některé jiné VPN. Nemůže. Rukování nese klíče, adresy rozhraní a povolené IP adresy a nemá pole pro DNS servery ani domény hledání. Politika resolveru žije na klientovi a tam patří i oprava.

Tunel a resolver jsou dvě oddělené smlouvy

WireGuard je záměrně malý. Přesouvá pakety pro adresy, které vypíšete, a autentizuje peery; vše nad tou vrstvou je váš návrh. OpenVPN umí protlačit dhcp-option DNS, protože jeho řídicí kanál nese konfiguraci, a tento rozdíl plete lidi, kteří přecházejí mezi oběma.

Fungující tunel vám tedy o překladu jmen neřekne nic. Klient může mít dokonalou trasu k 10.90.0.1 a přesto posílat dotazy veřejnému resolveru, a proto symptom vypadá jako “VPN rozbila DNS”, i když DNS na VPN nikdy nesměřoval.

Obslužte zónu, aniž byste se stali rekurzivním resolverem

Strana serveru je malá autoritativní zóna, ne obecný resolver. V tomto příkladu je brána 10.90.0.1, klienti jsou 10.90.0.0/24 a aplikace, na které vám záleží, odpovídá na 10.60.0.20.

Sloučte tato nastavení do existujícího bloku options, místo abyste vytvářeli druhý:

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

Pak deklarujte zónu a její soubor:

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

Před znovunačtením validujte, protože syntaktická chyba při načtení shodí celý server pro každou zónu, kterou obsluhuje:

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

Otevřete UDP a TCP 53 jen na rozhraní VPN. Zveřejnění privátní autority na veřejném rozhraní zve jak dotazy, tak výčet, a allow-transfer má zůstat zavřené, pokud sekundární skutečně nepotřebuje.

Namiřte klienta na něj, pro každé spojení

Předpokládejte, že spojení vlastní NetworkManager a resolverem je systemd-resolved. Nejdřív si přečtěte stávající politiku, zejména případnou kořenovou doménu směrování, protože záznam ~. převáží to, co se chystáte přidat.

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 jako pouze-směrovací: jména pod corp.example jdou na DNS server tohoto spojení a doména se nepřipojuje jako přípona hledání krátkých jmen. Bez ní začne psaní portal překládat portal.corp.example, což je pohodlné pro vás a překvapivé pro všechny ostatní. Vlnku držte uvnitř uvozovek, protože neocitovaná je expanze shellu, která čeká, až ukáže na váš domovský adresář.

Změnu aplikujte přes správce, který rozhraní vlastní, a pak spojení znovu připojte. Nespouštějte druhou instanci wg-quick pro stejné rozhraní; dva vlastníci se budou hádat o trasy a jeden z nich vyhraje v tu nejhorší chvíli.

Ověřte cestu dřív než jméno

Dotážete se na jméno z klienta a potvrďte jak odpověď, tak server, který ji vydal:

resolvectl query portal.corp.example

Pokud to vrátí 10.60.0.20, je DNS smlouva splněna. Pokud to vyprší, zkontrolujte nejdřív trasu k 10.90.0.1, pak pravidlo firewallu a pak allow-query na serveru. Selhání překladu jmen v tomto uspořádání jsou téměř vždy dostupnost nebo ACL, ne soubor zóny. Pracujte od klienta ven, protože server vám neřekne, proč dotaz nikdy nedorazil.

Pamatujte, že aplikace stále potřebuje vlastní trasu a vlastní oprávnění služby. Přeložené jméno ukazující na nedostupnou adresu je jiná porucha ve stejném kabátě.

Co stále není automatické

Aplikace s vlastní logikou resolveru ignorují systémový resolver úplně a žádné množství nmcli to nezmění. Nasazení, která validují DNSSEC, potřebují výslovný návrh důvěryhodné kotvy pro privátní zónu; odpovědí není plošný pokyn validaci vypnout. Testujte stejným klientským softwarem, který používají vaši uživatelé, ne nástrojem, který náhodou používá systémový resolver. Rozdíl mezi těmi dvěma je celé hlášení o chybě.

Flotily mohou tuto klientskou politiku automatizovat přes svůj systém zřizování, ale politika zůstává samostatný objekt s vlastníkem. Referenční příručka BIND 9 pokrývá ovládání naslouchání a dotazů použité výše a je správným místem pro potvrzení chování pro vaši nainstalovanou verzi.

Další krok: přidejte do postupu změn zvýšení sériového čísla zóny a kontrolní příkazy, aby se úprava záznamu nemohla dostat do produkce nezkontrolovaná.

Související články