 |
ot Hapkoc(5-05-2006)
reiting (11)
[  dobre ]
[  zle ]
 Variant za otpechatvane
Rabota s izgledi v BIND9
Copyright (c) 2006 Aleksandur Iliev
Litsenz: CC Attribution-ShareAlike
Motivatsiia i auditoriia
Problemut
Reshenieto
Po-prostoto i elegantno reshenie
Realnoto prilozhenie na izgledite
Obrabotka na zaiavki ot lokalnata mashina
Motivatsiia i auditoriia
Motivatsiiata za statiiata e, che naposleduk niakolko choveka zadavat edin i sushti vupros vuv foruma na linux-bg.org, a otgovora edin ot vuzmozhnite otgovori na tozi vupros e imenno v razglezhdanata tema.
Statiiata e prednaznachena za hora, koito sa naiasno s osnovnite termini v oblastta na DNS i sa se zanimavali s konfigurirane na BIND.
Problemut
Na vse poveche mesta v posledno vreme imame slednata situatsiia - malka (firmena ili domashna) mrezha, obiknoveno izpolzvashta IP adresi ot RFC1918 imashta vhodno/izhodna tochka kum internet v litseto na mashina, koiato igrae roliata na marshrutizator, DNS survur, ognena stena i t.n.
DNS survurut mozhe da obsluzhva zaiavki samo ot vutreshnata mrezha, pri uslovie, che na nego ne se suhraniava zona, za koiato sushtiia tozi survur e otgovoren (authoritative [1]). Ako survura obsluzhva zaiavki po zona, za koiato e otgovoren, togava ima problem, t.k. obiknoveno ne e zhelatelno survura da obsluzhva rekursivno zaiavki ot hostove izvun lokalnata mrezha.
Reshenieto
Ili po-tochno edno ot vuzmozhnite resheniia na tozi problem sa t.nar. izgledi (views) v BIND9. Izgledite opredeliat razlichni nachini na obsluzhvane na zaiavkite v zavisimost ot iztochnika na zaiavkata i adresa, kum koito e nasochena.
Za naglednost shte izpolzvame slednata shema:
DNS survur, obsluzhvasht rekursivno mrezhata 192.168.1.0/24 s adres ot tazi mrezha 192.168.1.1 i adres kum internet dostavchik 10.0.0.1 (adresut e s tsel ilyustrirane na primera i faktut, che e ot adresnoto prostranstvo, definirano v RFC1918 niama otnoshenie).
Imame domein "some.domain", za koito vuprosiia survur e purvichen otgovoren survur (t.e. zonata na domeina se suhraniava na tozi survur i se redaktira vurhu nego). Iskame survura da obrabotva v rekursiven rezhim zaiavki ot mrezhata 192.168.1.0/24, a za vsichki ostanali da otkazva izvurshvaneto na rekursiia.
SHTe definirame dva izgleda - edin za zaiavki ot 192.168.1.0/24 i edin za vsichki ostanali. Tova stava chrez direktivata view v named.conf. Za vseki izgled se zadava ime i klas, koito mozhe da se propusne, kato v takuv sluchai se priema klasa IN po podrazbirane. Klyuchovite direktivi pri izpolzvane na izgledi sa match-clients i match-destinations. CHrez tiah definirame kakvi kombinatsii ot adres na iztochnika i adres na poluchatelia v DNS zaiavkite ot koi izgled shte se obsluzhvat. I dvete direktivi priemat za parametri spisuk ot address_match_element. V primera po-dolu shte izpolzvame za udobstvo acl, koito sme definirali za vutreshnata mrezha.
Izvadkata ot named.conf ilyustrira definiraneto na dvata izgleda - local i public. Izgledut local shte obsluzhva zaiavki za lokalnata mrezha v rekursiven rezhim, a izgledut public shte obsluzhva nerekursivno zaiavkite kum domeina some.domain.
------ named.conf ------
acl local { 192.168.1.0/24; };
options {
listen-on port 53 { 127.0.0.1; 192.168.1.1; 10.0.0.1; };
};
view "local" {
match-clients { local; };
match-destinations { 192.168.1.1; };
recursion yes;
allow-query { local; };
zone "." {
type hint;
file "standard/root.hint";
};
zone "com" { type delegation-only; };
zone "net" { type delegation-only; };
zone "localhost" {
type master;
file "standard/localhost";
allow-transfer { localhost; };
};
zone "127.in-addr.arpa" {
type master;
file "standard/loopback";
allow-transfer { localhost; };
};
};
view "public" {
match-clients { any; };
match-destinations { 10.0.0.1; };
recursion no;
allow-query { any; };
zone "some.domain" {
type master;
file "public/master/some.domain";
...
};
};
(zabelezhka: propusnati sa niakoi direktivi ot named.conf kato controls i logging)
Pri takava konfiguratsiia named slusha na dvata adresa - 192.168.1.1 i 10.0.0.1. Kakvo se sluchva pri zaiavka kum survura? Purvo se proveriava adresa na izprashtacha na zaiavkata (ip source address) i adresa, do koito e izpratena (ip destination address) i tezi adresi se sravniavat suotvetno s adresite, opisani v match-clients i match-destinations direktivite na vseki izgled. Izpolzva se purviia izgled, za koito adresite na izprashtacha i poluchatelia v zaiavkata sa v ramkite na spisuka ot address_match_elements v match-clients i match-destinations direktivite, koeto znachi, che e ot sushtestveno znachenie v kakuv red shte budat opisani izgledite v named.conf.
I taka - ako se poluchi zaiavka ot host v mrezhata 192.168.1.0/24 adresirana do 192.168.1.1, to tia shte bude obsluzhena ot izgleda local, v koito e razresheno izpulnenieto na rekursivni zaiavki. Ako zaiavkata e ot iztochnik s adres, izvun lokalnata mrezha i e adresirana do 10.0.0.1, to tia shte se obsluzhi ot izgleda public.
Ima oshte edna direktiva, svurzana s izgledite - match-recursive-only. CHrez neia mozhe da se definira izgled, koito da obsluzhva samo rekursivni zaiavki.
Po-prostoto e elegantno reshenie
Kakto podskaza Georgi Aleksandrov, obache, izgledite dalech ne sa nai-dobroto reshenie v sluchaia. Mnogo po-udachno e za takava konfiguratsiia da se prilozhi slednoto - v optsiite na BIND (options v named.conf) se dobavia ogranichenie za izpulnenie na rekursivni zaiavki samo ot lokalnata mrezha. Dobre e sushto da se razreshat zaiavkite kum survura samo ot lokalnata mrezha v options, i za vsiaka zona, za koiato survura e otgovoren da se razreshat zaiavkite otvsiakude:
------ named.conf ------
options {
...
allow-recursion { local; };
allow-query { local; };
};
...
zone "some.domain" {
type master;
allow-query { any; };
...
};
V protiven sluchai hostove izvun lokalnata mrezha shte mogat da poluchavat otgovori na zaiavki, za koito ne se iziskva rekursiia, kato naprimer keshirani zapisi, koito obache sa izvun zonite, za koito otgovaria BIND.
Realnoto prilozhenie na izgledite
Izgledite, razbira se, mogat da se izpolzvat po posocheniia po-gore nachin, no tova ne e osnovnata im funktsiia.
Da kazhem, che v domeina "some.domain" ot gorniia primer ima opisani tri hosta - www, mail i pop. Priemame, che v primera edinstveniia publichen adres na razpolozhenie e 10.0.0.1 (i pak se abstrahirame ot fakta, che toi suvsem ne e publichen :) ). Tezi imena ot zonata "some.domain" v izgleda "public" shte izglezhdat gore-dolu taka:
------ public/some.domain ------
$ORIGIN some.domain.
www IN A 10.0.0.1
mail IN A 10.0.0.1
pop IN A 10.0.0.1
Za nashiia primer shte priemem, che na mashinata, koiato se iaviava DNS survur i marshrutizator, sa prenasocheni tcp/udp portovete na suotvetnite uslugi kum mashini ot vutreshnata mrezha, naprimer:
10.0.0.1:80 -> 192.168.1.5:80
10.0.0.1:25 -> 192.168.1.6:25
10.0.0.1:101 -> 192.168.1.8:101
Ako iskame ot vutreshnata mrezha da polzvame tezi uslugi sus sushtite imena to izgledite sa (pak ne edinstvenoto) reshenie. Definirame otnovo izgledite "local" i "public", kato tozi put i dvata vklyuchvat domeina "some.domain".
V "local" shte e neshto ot roda na:
------ local/some.domain ------
$ORIGIN some.domain.
www IN A 192.168.1.5
mail IN A 192.168.1.6
pop IN A 192.168.1.8
------ local/some.domain ------
V named.conf prosto dobaviame zonata "some.domain" v izgleda "local" kato master i posochvame, che failut s opisanieto na zonata e local/some.domain. Po tozi nachin klientite ot lokalnata mrezha shte poluchavat www.some.domain otgovor 192.168.1.5, dokato klientite izvun lokalnata mrezha shte poluchavat 10.0.0.1.
Obrabotka na zaiavki ot lokalnata mashina
Veroiatno e korektno konfiguratsiiata na izgledite da se promeni malko, taka che da pozvoliava obrabotka na zaiavki ot lokalnata mashina (tazi, na koiato raboti named). Tova stava po sledniia nachin:
------ named.conf ------
...
view "local" {
match-clients { local; 127.0.0.1; };
match-destinations { 192.168.1.1; 127.0.0.1; };
...
};
...
Drug variant e, vmesto da se dobavia v match-clients direktivata, 127.0.0.1 da se dobavi v acl local spisuka. Dokolkoto tselta na statiiata e da pokazhe kak mozhe da se realizira takava shema v malka mrezha, to i dvata varianta sa ednakvo udachni spored men. Pri po-slozhni konfiguratsii mozhe bi purviia e za predpochitane, pri uslovie che triabva da se pravi niakakvo razgranichenie mezhdu lokalnata mashina i klientite ot lokalnata mrezha, vupreki che tochno v momenta ne mi hrumva takuv stsenarii.
Nezavisimo koi ot dvata varianta se prilozhi, zaiavkite ot localhost kum localhost shte se obrabotvat po sushtiia nachin kato zaiavkite ot lokalnata mrezha (v sluchaia - rekursivno).
Tazi promiana mozhe da ne se prilaga, pri uslovie, che v konfiguratsiiata na lokalniia resolver figurira IP adresa ot lokalnata mrezha, a ne 127.0.0.1:
$ cat /etc/resolv.conf
nameserver 192.168.1.1
Vse pak e za predpochitane zaiavkite ot 127.0.0.1 da se razreshat po posocheniia nachin, dori i pri taka konfiguriran resolver.
[1] Ako niakoi ima po-dobra ideia za prevod da kazva
<< Modulna poddruzhka na XFS za RHEL i derivatite mu | BIND9 v mnogonodov rezhim na rabota >>
|
|
