Katrs sadalītā DNS pieprasījums sākas ar vienu un to pašu teikumu: uzņēmuma nosaukumi dodas uz uzņēmuma DNS, viss pārējais turpina darboties. Pārvērst šo teikumu konfigurācijā nozīmē atbildēt uz trim jautājumiem katrai operētājsistēmai, un atbildes katrā izmanto atšķirīgus mehānismus. Profili, kas darbojas Linux klēpjdatorā, bieži neizdodas Windows vidē tādu iemeslu dēļ, kuriem nav nekāda sakara ar tuneli. Atšķirība parasti ir maršrutam noturēts risinātāja iestatījums.

Vispirms nosauciet politiku, pēc tam izvēlieties platformas primitīvu, kas to izsaka.

Trīs iestatījumi, kurus viegli sajaukt

Meklēšanas sufikss paplašina īsu nosaukumu: ierakstot files, tas kļūst par files.corp.example, kad risinātājs pēc kārtas izmēģina sufiksus. Maršrutēšanas domēns izvēlas, kurš risinātājs atbild uz vaicājumiem nosaukumu telpā. IP maršruts tikai padara izvēlēto risinātāju sasniedzamu. Šie trīs dzīvo dažādos slāņos, un, aizstājot vienu ar otru, iegūst konfigurāciju, kas izskatās pareiza un neko neatrisina.

Sajukumam ir cena: pievienojot meklēšanas sufiksu, katrs īsais nosaukums tiek sūtīts uz darba risinātāju, tostarp nosaukumi, kas pieder citur. Izvēloties maršrutēšanas domēnu, nesaistītie vaicājumi paliek vietējā risinātājā, un tomēr *.corp.example tiek sūtīts pa tuneli.

Linux: tikai maršruta domēns, nevis meklēšanas sufikss

Systemd-resolved gadījumā domēns ar tildu priekšā ir tikai maršruta domēns, kas nozīmē, ka šīs nosaukumu telpas vaicājumi dodas uz saistīto risinātāju, nekļūstot arī par meklēšanas sufiksu. resolvectl domain tun0 '~corp.example' to iestata, un resolvectl dns tun0 10.8.0.1 nosauc serveri. Abi iestatījumi pieder saskarnei, tāpēc tie pazūd kopā ar to. Tilde ir tā daļa, ko cilvēki izlaiž, un bez tās īsie nosaukumi sāk risināties caur darba risinātāju.

Neinstalējiet to pašu domēnu arī kā globālu meklēšanas sufiksu. Abi iestatījumi nav lieki; viens maršrutē, otrs pārraksta to, ko ierakstījāt.

Windows vajag nosaukumu telpas politiku, nevis sufiksu

Windows sadalītā DNS politiku glabā Name Resolution Policy Table, nevis adaptera DNS sufiksā. Noteikums saista nosaukumu telpu ar konkrētiem serveriem: Add-DnsClientNrptRule -Namespace .corp.example -NameServers 10.8.0.1. Tikai sufika iestatīšana maina to, kā izskatās īsie nosaukumi; tā nenovieto vaicājumu citā serverī.

Pēc savienojuma pārbaudiet spēkā esošo politiku ar Get-DnsClientNrptPolicy, jo iepriekšējā savienojuma noteikums var pārdzīvot tuneli. Noņemiet noteikumus pēc nosaukuma, kad tunelis krīt, un saglabājiet attēlojamo nosaukumu stabilu, lai tīrīšana trāpītu pareizajam ierakstam.

Viens risinātāja īpašnieks katrai platformai

Darbvirsmas pārvaldnieks, OpenVPN up skripts un vietējais risinātāja dēmons visi var mēģināt rakstīt vienu un to pašu konfigurāciju. Kad tie nepiekrīt, uzvar pēdējais rakstītājs, un rezultāts atkarīgs no demontāžas secības. Izvēlieties vienu komponentu, kam pieder risinātāja stāvoklis, ļaujiet pārējiem ziņot, nevis rakstīt, un pārbaudiet atkārtotu savienojumu: politikai tas jāpārdzīvo, nedublējot noteikumus. Pārbaudiet arī atvienošanu, jo tieši atlikušais stāvoklis liek nākamajam savienojumam uzvesties citādi.

Lietojumprogrammas, kas līdzi nes savu šifrēto risinātāju, pilnībā ignorē operētājsistēmas politiku. Tā ir lietojumprogrammas īpašība, nevis tuneļa defekts.

Pārbaudiet rezultātu, nevis profila tekstu

Atrisiniet vienu nosaukumu, kam jāiet caur tuneli, un vienu, kam nav, katrā platformā, un apstipriniet, kurš serveris atbildēja. resolvectl query host.corp.example un Resolve-DnsName host.corp.example abi ziņo atbildējušo serveri. Atkārtojiet pēc atkārtota savienojuma. Pēc tam apstipriniet, ka tuneļa risinātājs ir sasniedzams adresē, ko profils pieprasa, jo pareiza politika, kas norāda uz nesasniedzamu serveri, neizdodas tāpat kā nekāda politika.

Pierakstiet paredzēto uzvedību profila piezīmēs: kurš sufikss maršrutē, kurš serveris uz to atbild un kas notiek ar visu pārējo. Nākamajai atbalstītajai platformai šis teikums būs vajadzīgs vairāk nekā konfigurācijas fails.

Saistītie raksti