WireGuard ne puŝas DNS: servi privatan BIND-zonon

La manpremo portas ŝlosilojn kaj permesitajn IP-ojn, neniam solvilon. Jen ellaborita privata BIND 9-zono plus la klienta politiko por ĉiu ligo, kiu igas ĝin solviĝi.

Vi starigis WireGuard, la tunelo pasigas trafikon, kaj la interna nomo ankoraŭ ne solviĝas. La sekva movo kutime estas serĉi DNS-agordon en la WireGuard-konfiguro, kvazaŭ samtavolano povus puŝi solvilon kiel faras kelkaj aliaj VPN-oj. Ĝi ne povas. La manpremo portas ŝlosilojn, interfacajn adresojn kaj permesitajn IP-ojn, kaj ĝi havas neniun kampon por DNS-serviloj aŭ serĉaj domajnoj. Solvila politiko loĝas ĉe la kliento, kaj tien apartenas la korekto.

La tunelo kaj la solvilo estas apartaj kontraktoj

WireGuard estas intence malgranda. Ĝi movas pakaĵojn por la adresoj, kiujn vi listigas, kaj aŭtentigas samtavolanojn; ĉio super tiu tavolo estas via dezajno. OpenVPN povas puŝi dhcp-option DNS ĉar ĝia rega kanalo portas konfiguron, kaj tiu diferenco faligas homojn, kiuj moviĝas inter la du.

Do funkcianta tunelo diras al vi nenion pri nom-solvado. La kliento povas havi perfektan itineron al 10.90.0.1 kaj tamen sendi siajn demandojn al publika solvilo, kaj tial la simptomo aspektas kiel “la VPN rompis DNS”, kvankam DNS neniam estis direktita al la VPN.

Servu la zonon sen fariĝi rekursiva solvilo

La servila flanko estas malgranda aŭtoritata zono, ne ĝenerala solvilo. En ĉi tiu ekzemplo la enirejo estas 10.90.0.1, la klientoj estas 10.90.0.0/24, kaj la aplikaĵo, kiu gravas al vi, respondas ĉe 10.60.0.20.

Kunfandu ĉi tiujn agordojn en la ekzistantan blokon options anstataŭ krei duan:

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

Poste deklaru la zonon kaj ĝian dosieron:

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

Validigu antaŭ ol reŝargi, ĉar sintaksa eraro ĉe reŝarĝo faligas la tutan servilon por ĉiu zono, kiun ĝi servas:

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

Malfermu UDP kaj TCP 53 nur al la VPN-interfaco. Publikigi privatan aŭtoritaton sur la publika interfaco invitas kaj demandojn kaj enumeradon, kaj allow-transfer devus resti fermita krom se sekundara vere bezonas ĝin.

Direktu la klienton al ĝi, por ĉiu ligo

Supozu, ke NetworkManager posedas la konekton kaj ke systemd-resolved estas la solvilo. Unue legu la ekzistantan politikon, precipe ajnan radikan enkursigan domajnon, ĉar rikordo ~. superos tion, kion vi ĵus aldonos.

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

La tildo estas la grava signo. Ĝi markas la domajnon kiel nur-itinera: nomoj sub corp.example iras al la DNS-servilo de ĉi tiu ligo, kaj la domajno ne estas aldonita kiel sufikso por mallongnoma serĉado. Sen ĝi, tajpado de portal komencas solvi portal.corp.example, kio estas oportuna por vi kaj surpriza por ĉiuj aliaj. Tenu la tildon ene de la citiloj, ĉar unu sen citiloj estas ŝel-ekspansio, kiu atendas montri al via hejma dosierujo.

Apliku la ŝanĝon per la administranto, kiu posedas la interfacon, poste rekonektu la konekton. Ne startigu duan wg-quick-instancon por la sama interfaco; du posedantoj kverelos pri itineroj kaj unu el ili gajnos en la plej malbona momento.

Validigu la vojon antaŭ la nomo

Demandu la nomon de la kliento kaj konfirmu kaj la respondon kaj la servilon, kiu produktis ĝin:

resolvectl query portal.corp.example

Se tio redonas 10.60.0.20, la DNS-kontrakto estas plenumita. Se ĝi tempolimas, kontrolu unue la itineron al 10.90.0.1, poste la fajroŝirmilan regulon, poste allow-query ĉe la servilo. Nom-solvaj malsukcesoj en ĉi tiu aranĝo preskaŭ ĉiam estas atingeblo aŭ ACL, ne la zona dosiero. Laboru eksteren de la kliento, ĉar la servilo ne povas diri al vi, kial demando neniam alvenis.

Memoru, ke la aplikaĵo ankoraŭ bezonas sian propran itineron kaj sian propran servpermeson. Solvita nomo, kiu montras al neatingebla adreso, estas alia malsukceso en la samaj vestaĵoj.

Kio ankoraŭ ne estas aŭtomata

Aplikaĵoj kun propra solvila logiko tute ignoras la sisteman solvilon, kaj neniu kvanto da nmcli ŝanĝas tion. Instalaĵoj, kiuj validigas DNSSEC, bezonas eksplicitan dezajnon de fida ankro por la privata zono; la respondo ne estas ĝenerala instrukcio malŝalti validigon. Testu per la sama klienta programaro, kiun viaj uzantoj ruligas, ne per ilo, kiu hazarde uzas la sisteman solvilon. La breĉo inter tiuj du estas la tuta cimraporto.

Flotoj povas aŭtomatigi ĉi tiun klientan politikon per sia proviza sistemo, sed la politiko restas aparta objekto kun posedanto. La BIND 9-referenco kovras la aŭskultajn kaj demandajn regilojn uzitajn supre, kaj ĝi estas la ĝusta loko por konfirmi konduton por via instalita versio.

Sekva paŝo: aldonu la pliigon de la seria numero de la zono kaj la kontrolkomandojn al via ŝanĝproceduro, por ke rikorda redakto ne povu atingi produktadon nekontrolite.

Rilataj artikoloj