WireGuard ne potiska DNS: strežba zasebne cone BIND

Rokovanje prenaša ključe in dovoljene IP-je, nikoli razreševalnika. Tu je pripravljena zasebna cona BIND 9 in politika odjemalca za vsako povezavo, ki jo prisili k razrešitvi.

Dvignili ste WireGuard, tunel prepušča promet, notranje ime pa se še vedno ne razreši. Naslednja poteza je običajno iskanje nastavitve DNS v konfiguraciji WireGuard, kot da bi partner lahko potisnil razreševalnik, kakor to počnejo druge VPN. Ne more. Rokovanje prenaša ključe, naslove vmesnika in dovoljene IP-je ter nima polja za strežnike DNS ali iskalne domene. Politika razreševalnika živi na odjemalcu in tja sodi popravek.

Tunel in razreševalnik sta ločeni pogodbi

WireGuard je namerno majhen. Premešča pakete za naslove, ki jih naštejete, in preverja partnerje; vse nad tem slojem je vaša zasnova. OpenVPN lahko potisne dhcp-option DNS, ker njegov krmilni kanal prenaša konfiguracijo, in ta razlika spotakne tiste, ki se selijo med obema.

Delujoč tunel torej ne pove ničesar o razreševanju imen. Odjemalec ima lahko popolno pot do 10.90.0.1 in vseeno pošilja poizvedbe javnemu razreševalniku, zato je simptom videti kot “VPN je pokvaril DNS”, čeprav DNS ni bil nikoli usmerjen na VPN.

Strežite cono, ne da bi postali rekurzivni razreševalnik

Stran strežnika je majhna avtoritativna cona, ne splošni razreševalnik. V tem primeru je prehod 10.90.0.1, odjemalci so 10.90.0.0/24, aplikacija, ki vas zanima, pa odgovarja na 10.60.0.20.

Te nastavitve združite v obstoječi blok options, namesto da ustvarite novega:

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

Nato razglasite cono in njeno datoteko:

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

Preverite pred ponovnim nalaganjem, ker sintaktična napaka pri nalaganju podre celoten strežnik za vsako cono, ki jo streže:

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

Odprite UDP in TCP 53 le na vmesniku VPN. Objava zasebne avtoritete na javnem vmesniku vabi poizvedbe in naštevanje, allow-transfer pa naj ostane zaprt, razen če sekundarni res potrebuje.

Usmerite odjemalca nanjo, za vsako povezavo

Predpostavite, da povezavo poseduje NetworkManager in da je razreševalnik systemd-resolved. Najprej preberite obstoječo politiko, zlasti morebitno korensko usmerjevalno domeno, ker bo vnos ~. presegel to, kar boste dodali.

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

Tilda je pomemben znak. Označuje domeno kot samo-pot: imena pod corp.example gredo na strežnik DNS te povezave, domena pa se ne doda kot pripona za iskanje kratkih imen. Brez nje tipkanje portal začne razreševati portal.corp.example, kar je priročno za vas in presenetljivo za vse druge. Tildo držite v narekovajih, ker je brez narekovajev razširitev lupine, ki čaka, da pokaže na vaš domači imenik.

Spremembo uporabite prek upravitelja, ki ima vmesnik, nato povezavo znova povežite. Ne zaženite drugega primerka wg-quick za isti vmesnik; dva lastnika se bosta prepirala o poteh in eden od njiju bo zmagal v najslabšem trenutku.

Preverite pot pred imenom

Povprašajte po imenu z odjemalca in potrdite tako odgovor kot strežnik, ki ga je ustvaril:

resolvectl query portal.corp.example

Če to vrne 10.60.0.20, je pogodba DNS izpolnjena. Če poteče čas, najprej preverite pot do 10.90.0.1, nato pravilo požarnega zidu, nato allow-query na strežniku. Napake pri razreševanju imen v tej postavitvi so skoraj vedno dosegljivost ali ACL, ne datoteka cone. Delajte od odjemalca navzven, ker strežnik ne more povedati, zakaj poizvedba ni nikoli prispela.

Ne pozabite, da aplikacija še vedno potrebuje svojo pot in svoje dovoljenje za storitev. Razrešeno ime, ki kaže na nedosegljiv naslov, je druga okvara v istih oblačilih.

Kaj še vedno ni samodejno

Aplikacije z lastno logiko razreševalnika popolnoma prezrejo sistemski razreševalnik in nobena količina nmcli tega ne spremeni. Namestitve, ki preverjajo DNSSEC, potrebujejo izrecno zasnovo sidra zaupanja za zasebno cono; odgovor ni splošno navodilo, naj se preverjanje izklopi. Preizkusite z isto odjemalsko programsko opremo, ki jo poganjajo vaši uporabniki, ne z orodjem, ki slučajno uporablja sistemski razreševalnik. Razlika med tema dvema je celotno poročilo o napaki.

Flote lahko to politiko odjemalca avtomatizirajo prek svojega sistema za pripravo, vendar politika ostaja ločen objekt z lastnikom. Referenca BIND 9 pokriva uporabljene nadzore poslušanja in poizvedb zgoraj in je pravo mesto za potrditev vedenja za vašo nameščeno različico.

Naslednji korak: v svoj postopek sprememb dodajte povišanje serijske številke cone in preveritvene ukaze, da ureditev zapisa ne more priti v produkcijo nepreverjena.

Sorodni članki