Inangat mo ang WireGuard, dumadaan ang trapiko sa tunnel, at hindi pa rin nareresolba ang panloob na pangalan. Ang susunod na hakbang ay karaniwang paghahanap ng setting ng DNS sa konfigurasyon ng WireGuard, na parang makakapagtulak ang peer ng resolver gaya ng ginagawa ng ibang VPN. Hindi nito kaya. Ang handshake ay nagdadala ng mga susi, address ng interface at pinapayagang IP, at wala itong field para sa mga DNS server o search domain. Ang patakaran ng resolver ay nasa kliyente, at doon nararapat ang pagwawasto.

Ang tunnel at ang resolver ay magkahiwalay na kontrata

Sadyang maliit ang WireGuard. Naglilipat ito ng packet para sa mga address na ililista mo at nagpapatunay ng mga peer; lahat ng nasa itaas ng layer na iyon ay disenyo mo. OpenVPN ay makakapagtulak ng dhcp-option DNS dahil nagdadala ng konfigurasyon ang control channel nito, at ang pagkakaibang iyon ay nagpapadapa sa mga lumilipat sa pagitan ng dalawa.

Kaya ang gumaganang tunnel ay walang sinasabi tungkol sa resolusyon ng pangalan. Maaaring may perpektong ruta ang kliyente patungo sa 10.90.0.1 at ipadala pa rin ang mga query nito sa pampublikong resolver, kaya mukhang “sinira ng VPN ang DNS” ang sintomas gayong hindi kailanman itinuro ang DNS sa VPN.

Pagsilbihan ang zone nang hindi nagiging recursive resolver

Ang panig ng server ay isang maliit na authoritative zone, hindi pangkalahatang resolver. Sa halimbawang ito ang gateway ay 10.90.0.1, ang mga kliyente ay 10.90.0.0/24, at ang aplikasyong mahalaga sa iyo ay sumasagot sa 10.60.0.20.

Pagsamahin ang mga setting na ito sa umiiral na bloke ng options sa halip na gumawa ng pangalawa:

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

Pagkatapos ay ideklara ang zone at ang file nito:

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

Patunayan bago mag-reload, dahil ang error sa syntax sa pag-load ay nagbabagsak sa buong server para sa bawat zone na pinaglilingkuran nito:

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

Buksan ang UDP at TCP 53 sa interface ng VPN lamang. Ang paglalathala ng pribadong awtoridad sa pampublikong interface ay nag-aanyaya ng mga query at enumerasyon, at ang allow-transfer ay dapat manatiling sarado maliban kung talagang kailangan ito ng isang sekondarya.

Ituro ang kliyente roon, sa bawat link

Ipagpalagay na ang koneksyon ay pag-aari ng NetworkManager at ang resolver ay systemd-resolved. Basahin muna ang umiiral na patakaran, lalo na ang anumang root routing domain, dahil lalampas ang entry na ~. sa idadagdag mo.

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

Ang tilde ang mahalagang karakter. Minamarkahan nito ang domain bilang ruta lamang: ang mga pangalan sa ilalim ng corp.example ay pumupunta sa DNS server ng link na ito, at hindi idinadagdag ang domain bilang suffix ng paghahanap ng maiikling pangalan. Kung wala ito, ang pag-type ng portal ay magsisimulang iresolba ang portal.corp.example, na maginhawa para sa iyo at nakakagulat para sa lahat. Panatilihin ang tilde sa loob ng mga panipi, dahil ang walang panipi ay expansion ng shell na naghihintay na ituro sa iyong home directory.

Ilapat ang pagbabago sa pamamagitan ng manager na may-ari ng interface, pagkatapos ay ikonekta muli ang koneksyon. Huwag magsimula ng pangalawang instance ng wg-quick para sa parehong interface; mag-aaway ang dalawang may-ari sa mga ruta at isa sa kanila ang mananalo sa pinakamasamang sandali.

Patunayan ang landas bago ang pangalan

Tanungin ang pangalan mula sa kliyente at kumpirmahin ang sagot at ang server na gumawa nito:

resolvectl query portal.corp.example

Kung nagbabalik ito ng 10.60.0.20, tapos na ang kontrata ng DNS. Kung nag-time out, tingnan muna ang ruta patungo sa 10.90.0.1, pagkatapos ang patakaran ng firewall, pagkatapos ang allow-query sa server. Ang mga pagkabigo sa resolusyon ng pangalan sa setup na ito ay halos palaging abot o isang ACL, hindi ang zone file. Magtrabaho palabas mula sa kliyente, dahil hindi masasabi ng server kung bakit hindi kailanman dumating ang isang query.

Tandaan na kailangan pa rin ng aplikasyon ang sariling ruta at sariling pahintulot sa serbisyo. Ang naresolbang pangalan na tumuturo sa isang address na hindi maabot ay ibang pagkabigo sa parehong damit.

Ano ang hindi pa awtomatiko

Ang mga aplikasyong may sariling lohika ng resolver ay ganap na binabalewala ang system resolver, at walang dami ng nmcli ang makakabago niyon. Ang mga deployment na nagpapatunay ng DNSSEC ay nangangailangan ng malinaw na disenyo ng trust anchor para sa pribadong zone; ang sagot ay hindi isang pangkalahatang utos na patayin ang pagpapatunay. Subukan gamit ang parehong client software na pinapatakbo ng iyong mga user, hindi gamit ang tool na nagkataong gumagamit ng system resolver. Ang agwat sa pagitan ng dalawa ay ang buong ulat ng bug.

Maaaring i-automate ng mga fleet ang patakarang ito ng kliyente sa pamamagitan ng kanilang provisioning system, ngunit ang patakaran ay nananatiling hiwalay na bagay na may may-ari. Ang sanggunian ng BIND 9 ay sumasaklaw sa mga kontrol sa pakikinig at pagtatanong na ginamit sa itaas, at ito ang tamang lugar upang kumpirmahin ang pag-uugali para sa naka-install na bersyon mo.

Susunod na hakbang: idagdag ang pagtaas ng serial number ng zone at ang mga command sa pag-verify sa iyong pamamaraan ng pagbabago, upang ang pag-edit ng record ay hindi makarating sa produksyon nang hindi nasusuri.

Kaugnay na mga artikulo