BIND per VPN: sąlyginis persiuntimas ar stub zona?

Trys būdai išspręsti vieną privačią zoną per VPN ir kada kuris tinka: forward, stub ar secondary, be to, šaltinio adreso patikra, kuri ir nusprendžia.

Jūsų biuro resolveris atsako į viską, išskyrus vieną įmonės vardų sritį, o įmonės DNS serveris, kuris ją žino, yra už VPN. BIND gali perduoti tą vieną zoną upstreamui trimis skirtingais būdais, ir jie nepavyksta skirtingai. Sąlyginis persiuntimas yra mažiausias įsipareigojimas, stub zona išlaiko delegavimo duomenis, o secondary išlaiko visą kopiją. Rinkitės pagal tai, ką leis upstreamas ir ką norite, kad jūsų resolveris laikytų, o ne pagal tai, kurį fragmentą radote pirmiausia.

Trys išdėstymai vienai vardų sričiai

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

Sąlyginis persiuntimas: mažiausias įsipareigojimas

Tarkime, biuro resolveris yra 192.168.10.53, o įmonės serveris – 10.40.0.53, pasiekiamas patvirtintu tuneliu. Deklaracija yra trys eilutės, o įdomiausia yra forward only, nes ji keičia ne kelią, o elgesį sutrikus.

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

Su forward only nepasiekiamas upstreamas šiai zonai grąžina SERVFAIL, o ne grįžta prie iteracinio sprendimo. Privačiai vardų sričiai paprastai to ir norite, nes grįžimas nusiųstų privačius vardus viešam resolveriui ir grąžintų nenaudingą atsakymą iš interneto. BIND žinynas dokumentuoja abi taisykles, o skirtumas svarbesnis, nei leidžia suprasti fragmentas. Sujunkite zoną su esama konfigūracija, o ne pakeiskite zoną, kuri tam pačiam vardui jau egzistuoja.

Stub ar secondary: kai delegavimas svarbus

Stub zona įmonės serverio klausia zonos NS įrašų ir tada tiesiogiai klausia autoritetingų serverių. Rinkitės ją, kai upstreamo regionas didelis ar suskaidytas ir norite, kad jūsų resolveris sektų delegavimą, o ne prikaltų viską prie vieno adreso. Kaina – priklausomybė nuo NS duomenų aktualumo ir nuo to, kad kiekvienas sąraše nurodytas vardų serveris būtų pasiekiamas iš jūsų resolverio šaltinio adreso.

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 atsako iš vietinių duomenų ir išgyvena upstreamo sutrikimą, ir tai yra priežastis priimti perdavimo priklausomybę. Tai taip pat reiškia, kad jūsų resolveris dabar laiko zonos, kuri jam nepriklauso, kopiją, todėl failo kelias, pirminio serverio perdavimo ACL ir atnaujinimo laikmačiai tampa jūsų operacinio paviršiaus dalimi.

Patikra, kuri nusprendžia tarp jų

BIND pats generuoja savo siunčiamą užklausą, tad klausimas ne ar nešiojamasis kompiuteris pasiekia 10.40.0.53, o ar pasiekia resolverio hostas, iš šaltinio adreso, kurį matys įmonės serveris. Klauskite branduolio, tada serverio, ta tvarka.

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

Leiskite UDP ir TCP kelyje: sutrumpintas atsakymas verčia naudoti TCP, o taisyklė, leidžianti tik UDP, sukelia periodiškus sutrikimus, kurie atrodo kaip paketų praradimas. Įmonės pusė turi turėti ir priėmimo taisyklę jūsų resolverio šaltiniui, ir grįžimo maršrutą į jį; tas šaltinis gali būti maršrutizuotas resolverio adresas arba aiškiai išverstas adresas, ir retai kada tai yra klientų telkinio adresas. Jei NS užklausa nepavyksta, stub zona negali veikti, nesvarbu, kaip elgiasi forward zona.

Tikrinkite atsakymą, o ne tunelį

Paklauskite per biuro resolverį vardo, kurio niekada neprašėte, ir pažiūrėkite į atsakymo authority sekciją, ar jis atėjo iš įmonės zonos. Podėlyje esantis atsakymas nieko neįrodo apie dabartinį kelią, o sėkminga tiesioginė užklausa upstreamui neįrodo, kad jūsų resolveris pasirinko tą zoną. Pakartokite tą pačią užklausą per TCP, kad patvirtintumėte, jog kelias atlaiko trumpinimą.

Laikykite klientus nukreiptus į biuro resolverį, ir palikite DNSSEC tikrinimą įjungtą. Naršyklė, sukonfigūruota su nepriklausomu šifruotu resolveriu, visiškai apeina šį išdėstymą, o tikrinimo išjungimas, kad netikėtas atsakymas atrodytų teisingas, keičia matomą sutrikimą į nematomą.

Užsirašykite, kurią iš trijų tipų pasirinkote ir kodėl. Kitas žmogus, kuris pamatys zoną nepavykstant, labiau reikės to sakinio nei konfigūracijos failo.

Susiję straipsniai