Jūs pacēlāt WireGuard, tunelis laiž cauri satiksmi, un iekšējais nosaukums joprojām neatrisinās. Nākamais solis parasti ir meklēt DNS iestatījumu WireGuard konfigurācijā, it kā partneris varētu nosūtīt risinātāju, kā to dara dažas citas VPN. Nevar. Rokas rokas nesa atslēgas, saskarnes adreses un atļautās IP, un tam nav lauka DNS serveriem vai meklēšanas domēniem. Risinātāja politika dzīvo klientā, un tur arī ir labojuma vieta.

Tunelis un risinātājs ir atsevišķi līgumi

WireGuard ir apzināti mazs. Tas pārvieto paketes jūsu uzskaitītajām adresēm un autentificē partnerus; viss virs šī slāņa ir jūsu dizains. OpenVPN var nosūtīt dhcp-option DNS, jo tā vadības kanāls nesa konfigurāciju, un šī atšķirība paklūp tiem, kas pārvietojas starp abiem.

Tātad strādājošs tunelis neko nepasaka par nosaukumu atrisināšanu. Klientam var būt ideāls maršruts uz 10.90.0.1 un tas joprojām sūtīt vaicājumus publiskam risinātājam, tāpēc simptoms izskatās kā “VPN salauza DNS”, lai gan DNS nekad nav bijis vērsts uz VPN.

Apkalpojiet zonu, nekļūstot par rekursīvu risinātāju

Servera puse ir maza autoritatīva zona, nevis vispārīgs risinātājs. Šajā piemērā vārteja ir 10.90.0.1, klienti ir 10.90.0.0/24, un lietojumprogramma, kas jums svarīga, atbild uz 10.60.0.20.

Apvienojiet šos iestatījumus esošajā options blokā, nevis veidojiet otru:

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

Pēc tam deklarējiet zonu un tās failu:

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ārbaudiet pirms pārlādes, jo sintakses kļūda ielādes laikā nogāž visu serveri katrai zonai, kuru tas apkalpo:

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

Atveriet UDP un TCP 53 tikai VPN saskarnē. Privātas autoritātes publicēšana publiskajā saskarnē aicina gan vaicājumus, gan uzskaitīšanu, un allow-transfer jāpaliek aizvērtam, ja vien sekundārais to tiešām neprasa.

Vērsiet klientu uz to, katrai saitei

Pieņemiet, ka savienojumu pārvalda NetworkManager un risinātājs ir systemd-resolved. Vispirms izlasiet esošo politiku, jo īpaši jebkuru saknes maršrutēšanas domēnu, jo ~. ieraksts pārspēs to, ko gatavojaties pievienot.

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

Tilde ir svarīgā rakstzīme. Tā atzīmē domēnu kā tikai-maršruts: nosaukumi zem corp.example iet uz šīs saites DNS serveri, un domēns netiek pievienots kā īsa nosaukuma meklēšanas sufikss. Bez tās, ierakstot portal, sāk atrisināties portal.corp.example, kas ir ērti jums un pārsteidzoši visiem pārējiem. Turiet tildi pēdiņās, jo bez pēdiņām tā ir čaulas paplašinājums, kas gaida norādi uz jūsu mājas direktoriju.

Piemērojiet izmaiņas caur pārvaldnieku, kuram pieder saskarne, pēc tam atkārtoti pievienojiet savienojumu. Nepalaidiet otru wg-quick eksemplāru tai pašai saskarnei; divi īpašnieki strīdēsies par maršrutiem, un viens no tiem uzvarēs sliktākajā brīdī.

Pārbaudiet ceļu pirms nosaukuma

Vaicājiet nosaukumu no klienta un apstipriniet gan atbildi, gan serveri, kas to radīja:

resolvectl query portal.corp.example

Ja tas atgriež 10.60.0.20, DNS līgums ir izpildīts. Ja laiks beidzas, vispirms pārbaudiet maršrutu uz 10.90.0.1, pēc tam ugunsmūra noteikumu, pēc tam allow-query serverī. Nosaukumu atrisināšanas kļūmes šajā konfigurācijā gandrīz vienmēr ir sasniedzamība vai ACL, nevis zonas fails. Strādājiet no klienta uz āru, jo serveris nevar pateikt, kāpēc vaicājums nekad neatnāca.

Atcerieties, ka lietojumprogrammai joprojām ir vajadzīgs savs maršruts un sava pakalpojuma atļauja. Atrisināts nosaukums, kas norāda uz nesasniedzamu adresi, ir cita kļūme tajās pašās drēbēs.

Kas joprojām nav automātisks

Lietojumprogrammas ar savu risinātāja loģiku pilnībā ignorē sistēmas risinātāju, un nekāds nmcli daudzums to nemaina. Izvietojumiem, kas validē DNSSEC, privātajai zonai vajadzīgs skaidrs uzticības enkura dizains; atbilde nav vispārīga instrukcija izslēgt validāciju. Testējiet ar to pašu klienta programmatūru, ko lieto jūsu lietotāji, nevis ar rīku, kas nejauši izmanto sistēmas risinātāju. Atšķirība starp šiem diviem ir viss kļūdas ziņojums.

Flotes var automatizēt šo klienta politiku ar savu nodrošināšanas sistēmu, bet politika paliek atsevišķs objekts ar īpašnieku. BIND 9 uzziņa aptver iepriekš izmantotās klausīšanās un vaicājumu vadības, un tā ir īstā vieta, lai apstiprinātu uzvedību jūsu instalētajai versijai.

Nākamais solis: pievienojiet zonas sērijas numura palielināšanu un pārbaudes komandas savai izmaiņu procedūrai, lai ieraksta rediģēšana nevarētu nesekmīgi sasniegt ražošanu.

Saistītie raksti