BIND pār VPN: nosacīta pāradresācija vai stub zona?

Trīs veidi, kā atrisināt vienu privātu zonu caur VPN, un kad kurš ir piemērots: forward, stub vai secondary, kā arī avota adreses pārbaude, kas izšķir.

Jūsu biroja resolveris atbild uz visu, izņemot vienu korporatīvo vārdu telpu, un korporatīvais DNS serveris, kas to zina, atrodas aiz VPN. BIND var nodot šo vienīgo zonu upstreamam trīs dažādos veidos, un tie neizdodas atšķirīgi. Nosacīta pāradresācija ir mazākais saistību apjoms, stub zona saglabā deleģēšanas datus, un secondary saglabā pilnu kopiju. Izvēlieties pēc tā, ko atļaus upstreams un ko vēlaties, lai jūsu resolveris patur, nevis pēc tā, kuru fragmentu atradāt pirmo.

Trīs izkārtojumi vienai vārdu telpai

TypeWhat your resolver keepsUpstream mustFails when
forwarda forwarder listanswer queries from your source addressupstream is down and forward only is set
stubthe zone's NS records and addressesanswer NS queries for the zonedelegation data goes stale after an NS change
secondarya full copy of the zonepermit AXFR or IXFR from your sourcetransfer is blocked by ACL or firewall

Nosacīta pāradresācija: mazākais saistību apjoms

Pieņemsim, biroja resolveris ir 192.168.10.53, bet korporatīvais serveris ir 10.40.0.53 un ir sasniedzams caur apstiprinātu tuneli. Deklarācija ir trīs rindas, un interesantā ir forward only, jo tā maina atteices uzvedību, nevis ceļu.

zone "corp.example" {
    type forward;
    forward only;
    forwarders { 10.40.0.53; };
};

Ar forward only nesasniedzams upstreams šai zonai atgriež SERVFAIL, nevis atgriežas pie iteratīvas risināšanas. Privātai vārdu telpai parasti vēlaties tieši to, jo atgriešanās sūtītu privātos vārdus uz publisku resolveri un atgrieztu no interneta neizdevīgu atbildi. BIND rokasgrāmata dokumentē abas politikas, un atšķirība ir svarīgāka, nekā liek domāt fragmentam. Apvienojiet zonu ar esošo konfigurāciju, nevis aizstājiet zonu, kas jau pastāv tam pašam vārdam.

Stub vai secondary: kad deleģēšana ir svarīga

Stub zona jautā korporatīvajam serverim zonas NS ierakstus un pēc tam jautā autoritatīvajiem serveriem tieši. Izvēlieties to, ja upstream reģions ir liels vai sadalīts un vēlaties, lai jūsu resolveris seko deleģēšanai, nevis piespraustu visu pie vienas adreses. Cena ir atkarība no NS datu aktualitātes un no tā, ka katrs uzskaitītais vārdu serveris ir sasniedzams no jūsu resolvera avota adreses.

zone "corp.example" {
    type stub;
    masters { 10.40.0.53; };
};

zone "corp.example" {
    type secondary;
    primaries { 10.40.0.53; };
    file "corp.example.db";
};

Secondary atbild no lokāliem datiem un pārdzīvo upstream pārtraukumu, un tas ir iemesls pieņemt pārsūtīšanas atkarību. Tas nozīmē arī, ka jūsu resolveris tagad tur zonas kopiju, kas tam nepieder, tāpēc faila ceļš, primārā pārsūtīšanas ACL un atjaunināšanas taimeri kļūst par jūsu darbības virsmas daļu.

Pārbaude, kas izšķir starp tiem

BIND pats ģenerē savu izejošo vaicājumu, tāpēc jautājums nav, vai klēpjdators var sasniegt 10.40.0.53, bet vai to var resolvera saimnieks, no avota adreses, ko redzēs korporatīvais serveris. Jautājiet kodolam, pēc tam serverim, šajā secībā.

ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.example

Atļaujiet UDP un TCP ceļā: saīsināta atbilde piespiež TCP, un politika, kas atļauj tikai UDP, rada periodiskas kļūmes, kas izskatās kā pakešu zudums. Korporatīvajai pusei vajag gan pieņemšanas noteikumu jūsu resolvera avotam, gan atgriešanās maršrutu uz to; šis avots var būt resolvera maršrutētā adrese vai skaidri tulkota adrese, un reti tas ir klientu pūla adrese. Ja NS vaicājums neizdodas, stub zona nevar darboties neatkarīgi no tā, kā uzvedas forward zona.

Pārbaudiet atbildi, nevis tuneli

Vaicājiet caur biroja resolveri vārdu, pēc kura nekad neesat jautājis, un apskatiet atbildes authority sadaļu, lai redzētu, vai tā nāk no korporatīvās zonas. Kešatmiņā saglabāta atbilde neko nepierāda par pašreizējo ceļu, un veiksmīgs tiešs vaicājums upstreamam nepierāda, ka jūsu resolveris izvēlējās šo zonu. Atkārtojiet to pašu vaicājumu pa TCP, lai apstiprinātu, ka ceļš iztur saīsināšanu.

Turiet klientus vērstus uz biroja resolveri, un turiet DNSSEC validāciju ieslēgtu. Pārlūks, kas konfigurēts ar neatkarīgu šifrētu resolveri, pilnībā apiet šo izkārtojumu, un validācijas izslēgšana, lai negaidīta atbilde izskatītos pareiza, apmaina redzamu kļūmi pret neredzamu.

Pierakstiet, kuru no trim tipiem izvēlējāties un kāpēc. Nākamajam cilvēkam, kurš redzēs zonu neizdodoties, šis teikums būs vajadzīgs vairāk nekā konfigurācijas fails.

Saistītie raksti