Hatiin ang DNS sa OpenVPN: ano ang dapat gawin ng domain na pangruta sa bawat sistema

Bawat kahilingan ng hating DNS ay nagsisimula sa parehong pangungusap: ang mga pangalan ng kumpanya ay pumupunta sa DNS ng kumpanya, at ang lahat ng iba ay patuloy na gumagana. Ang gawing konfigurasyon ang pangungusap na iyon ay nangangahulugang pagsagot sa tatlong tanong sa bawat sistema ng pagpapatakbo, at ang mga sagot ay gumagamit ng magkaibang mekanismo sa bawat isa. Ang mga profile na gumagana sa Linux laptop ay madalas na nabibigo sa Windows dahil sa mga dahilang walang kinalaman sa tunnel. Ang puwang ay karaniwang isang setting ng resolver na napagkamalang ruta.

Pangalanan muna ang patakaran, pagkatapos piliin ang primitive ng plataporma na nagpapahayag nito.

Tatlong setting na madaling malito

Ang suffix ng paghahanap ay nagpapalawak ng maikling pangalan: kapag nag-type ka ng files ito ay nagiging files.corp.example kapag sinusubukan ng resolver ang mga suffix ayon sa pagkakasunod-sunod. Ang domain na pangruta ay pumipili kung aling resolver ang sasagot sa mga query sa loob ng isang namespace. Ang ruta ng IP ay ginagawa lamang na maabot ang piniling resolver. Ang tatlong iyon ay nabubuhay sa magkaibang antas, at ang pagpapalit ng isa sa iba ay nagbubunga ng konfigurasyong mukhang tama at walang nire-resolve.

May bayad ang kalituhan: ang pagdaragdag ng suffix ng paghahanap ay nagpapadala ng bawat maikling pangalan sa resolver ng trabaho, kabilang ang mga pangalang pag-aari ng ibang lugar. Ang pagpili ng domain na pangruta ay nagpapanatili ng mga walang kaugnayang query sa lokal na resolver habang ipinapadala pa rin ang *.corp.example sa pamamagitan ng tunnel.

Linux: domain na pangruta lamang, hindi suffix ng paghahanap

Sa systemd-resolved, ang domain na may tilde sa unahan ay domain na pangruta lamang, ibig sabihin ang mga query para sa namespace na iyon ay pumupunta sa naka-link na resolver nang hindi rin nagiging suffix ng paghahanap. resolvectl domain tun0 '~corp.example' ang nagtatakda niyon, at resolvectl dns tun0 10.8.0.1 ang nagpangalan ng server. Ang dalawang setting ay kabilang sa interface, kaya nawawala sila kasama nito. Ang tilde ang bahaging iniiwan ng mga tao, at kung wala ito ang mga maikling pangalan ay nagsisimulang ma-resolve sa pamamagitan ng resolver ng trabaho.

Huwag ding i-install ang parehong domain bilang pangkalahatang suffix ng paghahanap. Ang dalawang setting ay hindi kalabisan; ang isa ay nagruruta at ang isa ay nagsusulat muli ng itinipa mo.

Kailangan ng Windows ng patakaran ng namespace, hindi suffix

Ang Windows ay nagtatago ng patakaran ng hating DNS sa talahanayan ng patakaran ng resolusyon ng pangalan, hindi sa DNS suffix ng adapter. Ang isang tuntunin ay nag-uugnay ng namespace sa mga partikular na server: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Ang pagtatakda ng suffix lamang ay nagbabago ng hitsura ng mga maikling pangalan; hindi nito itinuturo ang query sa ibang server.

Suriin ang epektibong patakaran gamit ang Get-DnsClientNrptPolicy pagkatapos kumonekta, dahil ang tuntunin mula sa naunang koneksyon ay maaaring mabuhay nang mas matagal kaysa sa tunnel. Alisin ang mga tuntunin sa pamamagitan ng pangalan kapag bumagsak ang tunnel, at panatilihing matatag ang display name upang ang paglilinis ay tumama sa tamang entry.

Panatilihin ang isang may-ari ng resolver sa bawat plataporma

Ang isang tagapamahala ng desktop, isang up script ng OpenVPN at isang lokal na daemon ng resolver ay maaaring lahat subukang isulat ang parehong konfigurasyon. Kapag hindi sila nagkasundo, ang huling sumulat ang nananalo at ang resulta ay nakadepende sa pagkakasunod-sunod ng pagtanggal. Pumili ng isang bahagi na magmamay-ari ng estado ng resolver, hayaan ang iba na mag-ulat sa halip na magsulat, at subukan ang muling pagkonekta: dapat mabuhay ang patakaran doon nang walang dobleng tuntunin. Subukan din ang pagdiskonekta, dahil ang natitirang estado ang dahilan kung bakit iba ang kilos ng susunod na koneksyon.

Ang mga application na may sariling naka-encrypt na resolver ay ganap na binabalewala ang patakaran ng sistema ng pagpapatakbo. Iyon ay katangian ng application, hindi depekto ng tunnel.

Patunayan ang resulta, hindi ang teksto ng profile

I-resolve ang isang pangalan na dapat dumaan sa tunnel at isa na hindi dapat, sa bawat plataporma, at kumpirmahin kung aling server ang sumagot. resolvectl query host.corp.example at Resolve-DnsName host.corp.example parehong nag-uulat ng server na tumugon. Ulitin pagkatapos ng muling pagkonekta. Pagkatapos kumpirmahin na maabot ang resolver ng tunnel sa address na ipinapadala ng profile, dahil ang tamang patakaran na tumuturo sa hindi maabot na server ay nabibigo tulad ng walang patakaran.

Itala ang nilalayong pag-uugali sa mga tala ng profile: aling suffix ang nagruruta, aling server ang sumasagot doon, at ano ang nangyayari sa lahat ng iba. Ang susunod na plataporma na susuportahan mo ay mangangailangan ng pangungusap na iyon nang higit kaysa sa file ng konfigurasyon.