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 целосно ја заобиколува оваа поставка, а исклучувањето на проверката за неочекуван одговор да изгледа точен разменува видлива грешка за невидлива.

Запишете кој од трите типа го избравте и зошто. Следниот човек што ќе види зоната да пропадне повеќе ќе му треба таа реченица отколку конфигурациската датотека.

Поврзани статии