BIND juu ya VPN: uelekezaji wa masharti au eneo la stub?
Njia tatu za kutatua eneo moja la faragha kupitia VPN, na kila moja inafaa lini: forward, stub au secondary, pamoja na ukaguzi wa anwani ya chanzo unaoamua.
Resolver ya ofisi yako hujibu kila kitu isipokuwa nafasi moja ya majina ya shirika, na seva ya DNS ya shirika inayoijua iko nyuma ya VPN. BIND inaweza kukabidhi eneo hilo moja kwa upstream kwa njia tatu tofauti, na zinashindwa kwa namna tofauti. Uelekezaji wa masharti ni ahadi ndogo zaidi, eneo la stub huhifadhi data ya uwakilishi, na secondary huhifadhi nakala kamili. Chagua kwa kuzingatia kile upstream itaruhusu na kile unataka resolver yako ihifadhi, si kwa kuzingatia snippet gani uliipata kwanza.
Mipangilio mitatu kwa nafasi moja ya majina
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
Uelekezaji wa masharti: ahadi ndogo zaidi
Fikiria resolver ya ofisi iko 192.168.10.53 na seva ya shirika iko 10.40.0.53 inayofikika kupitia handaki iliyoidhinishwa. Tamko ni mistari mitatu, na inayovutia ni forward only, kwa sababu inabadilisha tabia ya kushindwa, si njia.
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};
Pamoja na forward only, upstream isiyofikika hutoa SERVFAIL kwa eneo hili badala ya kurudi kwenye utatuzi wa kurudia. Kwa kawaida hii ndiyo unayotaka kwa nafasi ya faragha ya majina, kwa sababu kurudi kungetuma majina ya faragha kwa resolver ya umma na kurudisha jibu lisilo na maana kutoka mtandao. Marejeo ya BIND inaeleza sera zote mbili, na tofauti ni muhimu zaidi kuliko snippet inavyodokeza. Unganisha eneo katika usanidi uliopo badala ya kubadilisha eneo ambalo tayari lipo kwa jina hilohilo.
Stub au secondary: wakati uwakilishi ni muhimu
Eneo la stub huuliza seva ya shirika kuhusu rekodi za NS za eneo kisha huuliza seva zenye mamlaka moja kwa moja. Ichague wakati eneo la upstream ni kubwa au limegawanywa na unataka resolver yako ifuate uwakilishi badala ya kubandika kila kitu kwenye anwani moja. Gharama ni utegemezi wa data ya NS kuwa ya sasa, na wa kila seva ya majina iliyoorodheshwa kufikika kutoka anwani ya chanzo ya resolver yako.
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 hujibu kutoka data ya ndani na hustahimili kukatika kwa upstream, na hiyo ndiyo sababu ya kukubali utegemezi wa uhamishaji. Inamaanisha pia resolver yako sasa inashikilia nakala ya eneo ambalo si lake, kwa hivyo njia ya faili, ACL ya uhamishaji kwenye seva ya msingi na vipima muda vya kuonyesha upya vyote vinakuwa sehemu ya uso wako wa uendeshaji.
Ukaguzi unaoamua baina yao
BIND huzalisha swali lake la kutoka lenyewe, kwa hivyo swali si kama kompyuta mpakato inaweza kufikia 10.40.0.53 bali kama mwenyeji wa resolver anaweza, kutoka anwani ya chanzo ambayo seva ya shirika itaona. Uliza kernel, kisha uliza seva, kwa mpangilio huo.
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
Ruhusu UDP na TCP kwenye njia: jibu lililokatwa hulazimisha TCP, na sera inayoruhusu UDP pekee huzalisha kushindwa kwa vipindi kunakoonekana kama upotevu wa pakiti. Upande wa shirika unahitaji kanuni ya kukubali kwa chanzo cha resolver yako na njia ya kurudi kwayo; chanzo hicho kinaweza kuwa anwani iliyoelekezwa ya resolver au iliyotafsiriwa waziwazi, na mara chache ni anwani ya kundi la wateja. Ikiwa swali la NS litashindwa, eneo la stub haliwezi kufanya kazi, bila kujali eneo la forward linafanyaje.
Thibitisha jibu, si handaki
Uliza kupitia resolver ya ofisi kwa jina ambalo hukuwahi kuliomba, na angalia sehemu ya authority ya jibu ili kuona kama lilitoka kwenye eneo la shirika. Jibu lililohifadhiwa kwenye kashe halithibitishi chochote kuhusu njia ya sasa, na swali la moja kwa moja lililofanikiwa kwa upstream halithibitishi kwamba resolver yako ilichagua eneo hilo. Rudia swali hilo hilo kupitia TCP ili kuthibitisha kwamba njia inastahimili kukatwa.
Weka wateja wakielekezwa kwa resolver ya ofisi, na weka uthibitishaji wa DNSSEC ukiwa umewashwa. Kivinjari kilichosanidiwa na resolver ya usimbaji fiche huru hukwepa mpangilio huu kabisa, na kuzima uthibitishaji ili jibu lisilotarajiwa lionekane sahihi hubadilisha kushindwa kunakoonekana kwa kusikoonekana.
Andika ni aina ipi kati ya tatu uliyochagua na kwa nini. Mtu anayefuata atakayeona eneo likishindwa atahitaji sentensi hiyo kuliko faili ya usanidi.