BIND праз VPN: умоўная перадача ці 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-запыт не ўдаецца, stub-зона не можа працаваць, незалежна ад паводзін forward-зоны.

Правярайце адказ, а не тунель

Запытайце праз офісны resolver імя, пра якое вы ніколі не пыталіся, і паглядзіце на секцыю authority адказу, каб зразумець, ці прыйшоў ён з карпаратыўнай зоны. Кэшаваны адказ нічога не даказвае пра бягучы шлях, а паспяховы прамы запыт да upstream не даказвае, што resolver выбраў менавіта гэтую зону. Паўтарыце той жа запыт праз TCP, каб пацвердзіць, што шлях вытрымлівае ўсячэнне.

Трымайце кліентаў накіраванымі на офісны resolver, і пакіньце ўключанай праверку DNSSEC. Браўзер, наладжаны з незалежным шыфраваным resolver, цалкам абыходзіць гэтае ўладкаванне, а адключэнне праверкі, каб нечаканы адказ выглядаў правільным, мяняе бачны збой на нябачны.

Запішыце, які з трох тыпаў вы выбралі і чаму. Наступнаму чалавеку, які ўбачыць збой зоны, гэты сказ спатрэбіцца больш, чым файл канфігурацыі.

Падобныя артыкулы