VPN аркылуу BIND: шарттуу өткөрүүбү же stub аймагыбы?

VPN аркылуу бир жеке аймакты чечүүнүн үч жолу жана кайсы качан ылайыктуу: forward, stub же secondary, ошондой эле тандоону чечүүчү баштапкы даректи текшерүү.

Кеңсеңиздин resolver бир корпоративдик ат мейкиндигинен башка бардыгына жооп берет, ал эми аны билген корпоративдик DNS сервери VPNдин артында турат. BIND ошол бир аймакты upstreamке үч түрдүү жол менен бере алат жана алар ар башкача ишке ашпайт. Шарттуу өткөрүү – эң кичине милдеттенме, stub аймагы делегация маалыматтарын сактайт, ал эми secondary толук көчүрмөнү сактайт. Биринчи тапкан үзүндүгө карап эмес, upstream эмнеге жол берээрин жана resolverиңиз эмнени сакташын каалайарыңызга карап тандаңыз.

Бир ат мейкиндиги үчүн үч түзүлүш

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

Шарттуу өткөрүү: эң кичине милдеттенме

Кеңсе resolverи 192.168.10.53 дарегинде, корпоративдик сервер 10.40.0.53 дарегинде жана бекитилген туннел аркылуу жетүүгө болот деп болжолдойлу. Декларация үч сап, ал эми кызыктуусу forward only, анткени ал жолду эмес, ишке ашпоо жүрүмүн өзгөртөт.

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

forward only менен жеткиликсиз upstream бул аймак үчүн кайталанма чечимге кайтуунун ордуна SERVFAIL берет. Жеке ат мейкиндиги үчүн адатта ушуну каалайсыз, анткени кайтуу жеке аттарды коомдук resolverге жиберип, интернеттен пайдасыз жооп алып келет. BIND маалымдамасы эки саясатты тең сүрөттөйт жана айырма үзүндү көрсөткөндөн маанилүүрөөк. Аймакты ошол ат үчүн мурунтан бар аймакты алмаштыруунун ордуна учурдагы конфигурацияга кошуңуз.

stub же secondary: делегация маанилүү болгондо

stub аймагы корпоративдик серверден аймактын NS жазууларын сурайт, анан ыйгарым укуктуу серверлерден түз сурайт. Аны upstream аймагы чоң же бөлүнгөн учурда жана resolverиңиз баарын бир дарекке кадап койгондун ордуна делегацияны ээрчишин каалаганда тандаңыз. Баасы – NS маалыматтарынын актуалдуулугуна жана тизмедеги ар бир ат серверине resolverиңиздин баштапкы дарегинен жетүүгө көз карандылык.

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 жергиликтүү маалыматтардан жооп берет жана upstream үзгүлтүгүнө чыдайт, ошондуктан өткөрүүгө көз карандылыкты кабыл алууга болот. Бул ошондой эле resolverиңиз эми өзүнө таандык эмес аймактын көчүрмөсүн сактайрын билдирет, ошондуктан файл жолу, баштапкы сервердеги өткөрүү ACL жана жаңыртуу таймерлери операциялык бетиңиздин бөлүгүнө айланат.

Алардын ортосунда чечүүчү текшерүү

BIND өзүнүн чыгуучу суроосун өзү түзөт, ошондуктан суроо ноутбук 10.40.0.53 дарегине жете алабы дегенде эмес, resolver хост корпоративдик сервер көрө турган баштапкы даректен жете алабы дегенде. Адегенде ядродон, анан серверден сураңыз, ушундай тартипте.

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

Жолдо UDP жана TCPге жол бериңиз: кесилген жооп TCPни мажбурлайт, ал эми UDPге гана жол берген саясат пакет жоготуусуна окшош үзгүлтүктүү каталарды жаратат. Корпоративдик тарапка resolverиңиздин баштапкысы үчүн кабыл алуу эрежеси да, ага кайтуу маршруту да керек; бул баштапкы resolverдин маршрутталган дареги же так которулган дарек болушу мүмкүн жана сейрек клиент пулунун дареги болот. Эгер NS суроосу ишке ашпаса, forward аймагы кандай жүрүм көрсөтсө да, stub аймагы иштей албайт.

Туннелди эмес, жоопту текшериңиз

Кеңсе resolverи аркылуу эч качан сурабаган атты сурап, жооптун authority бөлүгүн карап, ал корпоративдик аймактан келгенин текшериңиз. Кэштелген жооп учурдагы жол тууралуу эч нерсени далилдебейт, ал эми upstreamке түз ийгиликтүү суроо resolverиңиз ошол аймакты тандаганын далилдебейт. Ошол эле суроону TCP аркылуу кайталап, жолдун кесүүгө чыдаарын тастыктаңыз.

Кардарларды кеңсе resolverине багыттап кармаңыз, жана DNSSEC текшерүүсүн күйүк тутуңуз. Көз карандысыз шифрленген resolver менен конфигурацияланган браузер бул түзүлүштү толугу менен айланып өтөт, ал эми күтүлбөгөн жооп туура көрүнүшү үчүн текшерүүнү өчүрүү көрүнүүчү катаны көрүнбөгөн катага алмаштырат.

Үч түрдүн кайсынысын тандаганыңызды жана эмне үчүн экенин жазып коюңуз. Аймактын иштебей калганын көрө турган кийинки адамга конфигурация файлынан көрө ошол сүйлөм көбүрөөк керек болот.

Тектеш макалалар