dnsmasq aldomainenként/alhálózatonként más-más dns-t használjon. (főként openwrt)

Linux-kezdő

Van egy internetre kapcsolt otthoni router, amin openwrt fut.
Az otthoni halozat 10.2.1.0/24
local domain: otthon.local
Így lesz a nyomtatóból nyomtato.otthon.local

A routeren vpn fut, minden ami 10.0.0.0/8, az a vpn-en megy kifele.

Meg lehet oldani dnsmasq-al, hogy továbbra is az internetszolgáltató dns szerverét használja, kivéve ha:
- helyi cím:
valami.otthon.local, mert akkor a /etc/hosts file alapján, (és ezt fordítsa a 10.0.0.0/8-ból bárkinek)
- bármi más, de .local, mert akkor a 10.1.1.1-et használja dns-ként?

Hogyan?

Ezt folytatva tovább, ha felkapcsolódna meg egy alhálózat a vpn-be( openwrt/dnsmasq )
10.3.1.0/24
local domain: masodikotthon.local
akkor bármelyiken felvett saját domainbe tartozó dns bejegyzéseket tudni kellene használni a másikból is.
Szóval
10.2.1.0/24---vpn---10.1.1.1---vpn---10.3.1.0/24
a 10.2.1.1-en ami a router, felveszem a "nyomtato"-t adott ip-hez (mondjuk 10.2.1.12), ebbol mivel az alhalozat domainje "otthon.local", lesz "nyomtato.otthon.local" automatikusan.
A másik alhálózatból, mondjuk a 10.3.1.123 kiadom a host parancsot, akkor mivel ".local"-ra végzódik, de nem helyi (nem "masodikotthon.local", a router a 10.1.1.1-től kérdezze, ami meg a 10.2.1.1-től?

Persze ip alapjá is fordítani kellene a címeket!

A vpn serveren amire csatlakoznak az openwrt-k (ami mondjuk a 10.1.1.1), lehetne bind is (bár jobban örülnék ott is dnsmasq-nak), de az openwrt-ken, ahol amúgy is csak néhány host lenne felvéve, és a terhelés is kicsi, maradni szeretnék az alapban felrakott dnsmasq-nal, csak nem sikerül ezt megoldanom...

Binddel megoldható, bár nem csináltam még hasonlót se...
A vpn szerveren (vagy hát a központi dns szerveren), azt is lehetne szabályozni, hogy adott alhálózatból milyen tartományra/domainre vonatkozó kéréseket szolgáljon ki/továbbítson.
....de dnsmasq-al?

Utóbbi azért lenne szerencsésebb mint a bind, mert a szerveren amúgy is van bind más interface-en, és nem szívesen keverném a dolgaikat.

  • 8259 megtekintés

( gyuri2012 | 2013. 01. 25., p – 03:08 )

/etc/config/dhcp-ba (openwrt) a
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option resolvfile '/tmp/resolv.conf.auto'
list server '/local/10.10.10.1'
option domain 'otthon.local'

biztató..., tcpdump-al látszólag jó a kozponti szerveren (10.10.10.1), de
"nslookup: can't resolve 'valami.masikotthon.local': Name or service not known" az openwrt-n. Ezt a 'valami.masikotthon.local'-t felvettem most a 10.10.10.1-en a /etc/hosts-ba, ha direkt ezt allítom be dns-nek, működik is a fordítás.

( apostroph3 | 2013. 01. 25., p – 07:04 )

azt nem tudom, hogy az openwrtn hogy muxik ez, de a dnsmasqnál így:

# cat /tmp/dnsmasq.conf 

interface=br0
resolv-file=/tmp/resolv.dnsmasq
all-servers
dhcp-leasefile=/tmp/dnsmasq.leases
dhcp-lease-max=50
dhcp-option=lan,3,192.168.100.254
dhcp-option=44,192.168.100.10
dhcp-authoritative
dhcp-range=lan,192.168.100.100,192.168.100.149,255.255.255.0,1440m
expand-hosts
domain=mydomain.lan
local=/mydomain.lan/
# no-resolv
# stop-dns-rebind
addn-hosts=/jffs/etc/hosts
# addn-hosts=/tmp/hosts

server=/odher-kft.lan/192.168.2.10             # openvpn tuloldalán a dns
server=/2.168.192.in-addr.arpa/192.168.2.10    # reverse
dhcp-host=10:01:02:03:04:05,192.168.100.1,12h  # admin
dhcp-host=00:01:02:03:04:05,192.168.100.10,12h # server

mx-host=server.mydomain.lan,mail.mydomain.lan,10
cname=mydomain.lan,server.mydomain.lan

cname=home.mydomain.lan,server.mydomain.lan
cname=www.mydomain.lan,server.mydomain.lan
cname=ftp.mydomain.lan,server.mydomain.lan
cname=fax.mydomain.lan,server.mydomain.lan
cname=printer.mydomain.lan,server.mydomain.lan
cname=webmin.mydomain.lan,server.mydomain.lan
cname=usermin.mydomain.lan,server.mydomain.lan
cname=transmission.mydomain.lan,server.mydomain.lan
dhcp-boot=pxelinux.0,server,192.168.100.10

# address=/mail.odher-kft.lan/192.168.2.10

# cat /jffs/etc/hosts 

127.0.0.1	localhost

192.168.100.254	DD-WRT
192.168.100.254 router.mydomain.lan router
192.168.100.254 ns.mydomain.lan ns
192.168.100.254 dns.mydomain.lan dns

192.168.1.1 dsl321b.modem.lan #	dsl321b
192.168.100.5 freenash.mydomain.lan freenash
192.168.100.10 server.mydomain.lan server
192.168.100.10 mail.mydomain.lan mail
192.168.100.253 wifibridge.mydomain.lan wifibridge

Köszönöm, sikerült!
Nagyjából jó volt az általam bemásolt is, tcpdump ezért volt jó. A kérdés-válasz még elment a helyére, csak aztán "eldobta".

Arról tudnál valamit mondani, hogy hogyan lehetne szabályozni azt, hogy adott domainre, ip-re vonatkozó kérdést, melyik alhálózatokból szolgáljon ki?

Azaz a központi dnsmasq-al (amelyik a vpn szerveren van) hogyan lehetne szabályozni azt, hogy honnan jövő kéréseket hova továbbítson?

...ha mondjuk van 10 routerem, dnsmasq-al egy vpn szerverre csatlakozva..., akkor:
-legyen olyan router alatti alhálózat, ahonnan jövő dns kérdéseket az összes router kiszolgál. (ez megvan végülis)
-legyen olyan router alatti alhálózat, amiből jövő kéréseket csak a sajátja szolgál ki...:
---legyen olyan, amit a közpoti dnsmasq se (saját /etc/hosts-ja alapján)
---és legyen olyan, amit a központi igen, de tovább már nem továbbít kérést.
-...és legyen olyan, amit csak az általam beállított x,y,z router (dnsmaq) szolgál ki. Szóval csak erre továbbítja a kérdést a központi.

Akkor felmerül a cache problémája is, ami azért kellene, de fontosabbak a korlátozások..., bár lehet ezt alapbó kezeli a dns szerver, ha amúgy tud ilyen funkciót.

azt tudom, hogy a dnsmasq dhcp serverétnek meg lehet adni, hogy mely csatoló(ko)n figyeljen, és melyik csatolón milyen ipket osszon, de hogy ezt a dns-el is megcsinálja-e? fogalmam sincs. de gondolom igen. - sosem volt rá szükségem -

viszont dns cache az van, csak a memóriába cache-el. vagyis ha újraindítod a dnsmasqot a cache is törlődik.

a dhcp-vel kiosztott ipket is cache-eli, erre van a dhcp-leasefile=/tmp/dnsmasq.leases sor. vagyis !általában ugyanazt az ip-t osztja ugyanannak a gépnek.

szerintem, hogy melyik alhálózatból melyik alhálózat látható, azt inkább a routerben kellene szabályozni, pl vlan-nal, iptables-el, vagy ebtables-el... attól függően, hogy mire van lehetőség. innen már teljesen mindegy hogy a dnsmasq megadja-e egy nem elérhető hálózaton logó gép címét/nevét, vagy sem.

ha nem fér hozzá egy alhálózathoz egy adott hálózatban lévő gép, akkor az alhálózatban lévő dnsmasqhoz sem fér hozzá.

ha A hálózat nem látja B hálózatot, és viszont, akkor A hálózat dns servere sem látja B hálózat dns serverét, és viszont. ráadásul hogy A hálózzad dns servere egyáltalán megpróbáljon adatokat szerezni B hálózad dns serverétől, és viszont, ahhoz a dns serverknek tudniuk is kell egymásról.

lást: server=/A|B/x.x.x.x.

ha ez nincs, akkor nem fognak adatokat cserélni egymással, ha egyébként látják is egymást.

Nem.

Egy-egy alhálózat routerében (dns szerverében) nincs beállítva egyeséve az összes többi alhálózat dns szervere..., mivel így ha valahol változás van, mindent végig kellene járni (ami felesleges munka is), hanem csak a központi dns szerver van beállítva.

Azaz ha saját maga nem tudja fordítani a címet, akkor nem adott alhálózat dns szerveréhez fordul, hanem a központihoz. A központi meg továbbítja a kérést a megfelelő alhalózat dns szerveréhez.

Tehát egy-egy alhálózat dns szerverében csak az van megadva, hogy ha nem saját cím de belső, akkor a központi dns szerverhez forduljon..., a központiban pedig be van állítva hogy adott alhálózat címéért melyik dns szerverhez kell fordulni. (alapvetően mindig az adott alhálózatban levő dns szerverhez)
Azaz ha egy alhálózatból (A) olyan kérés érkezik, ami egy másik alhálózat címére vonatkozik (B címére), akkor az A dns szervere megkérdezi a központitól (K) hogy mi a cím. A központi nem tudja, de tudja honnan lehet megkérdezni..., és ő maga megkérdezi a B-ről, majd az eredményt megmondja az A-nak.
Azaz nincs kommunikáció A és B között, tűzfalazni ezt nem lehet. Csak A-K majd K-B, B-K és végül K-A között folyik csevej.

A cache csak külön "probléma"..., de már azért se lenne jó a tűzfalazás (ha amúgy nem így működne a dolog.

ezzel csak az a baj, hogy "ha mondjuk van 10 routerem, dnsmasq-al" és megdöglik 'k' akkor minden hálózatok közti kommunikáció megszakadhat.

persze ez csak akkor gázos, ha ez valami céges háló. ez esetben 'K'-nak kellene legalább 1 másodlagos dns server, ezt meg a dnsmasq már nem tudja. - nem mintha nem lehetne megoldani, de nem lenne elég korrekt:) -

Hat igen..., de mivel vpn, ha megdöglik a vpn szerver, úgyis szakadnak (amúgy jelenleg egy szerveren fut a vpn szerver és ez a központi dns szerver, de ha nem így lenne, akkor is ugyanaz a végeredmeny ha vpn szakad).
Tartalék lehetne asszem vpn-ből is (openvpn amúgy), meg dns-ből is, de annyira nem kritikus szolgáltatások, annak ellenére hogy céges.

Viszont nagyon úgy tűnik nekem, hogy ilyen dolgot sem lehet dnsmasq-al megoldani, úgyhogy a központin mégiscsak bindnek kell lennie.

Bár mivel jelenleg egy vpn szerver van..., nincs belőle tartalék ezért nem aktuális, de mennyire lenne "korrekt" szerinted a köv megoldás a dologra?

Alhálózati routereken marad a dnsmasq, mivel egyszerű, és mivel több helyen openwrt van..., gyári kis routereket nem szeretém binddel terheli.

Ha jól értettem/sejtem, dnsmasq-al a klienseken nem lehet megoldani hogy adott alhálózatra vonatkozóan beállítsak tartalék dns-t. ( a központi szerveren meg már más okból amúgy is bind.)
Illetve esetemben csak annyi van beállítva az alhálózati dnsmasq-okban, hogy ami 10.0.0.0/8, azt a 10.10.10.1-en keresse (vagy azon keresztül), de ilyen tartalékot se lehet dnsmasq-ban beállítani.
Ugye?

Szóval lenne egy tartalék openvpn szerver.
Ha elsődleges elszáll, alhálózati routerek csatlakoznak a másodikra.
Ezen a másodikon (is) lenne egy virtuális interface, aminek szintén 10.10.10.1 lenne az ip-je, mint az elsődleges központi dns-en.
A rajta lévő bind szinkronizálna az eredetivel a dolgokat (persze egy másik ip címeken keresztül).

Tehát ami nem elegáns az az, hogy ez a 10.10.10.1-es ip a hálózatban két helyen szerepel, de mivel kizárólag dns-nek használom (és mindkét dns szervernek adok másik címet is, két különbözőt), egyéb galiba nem lehet belőle.
Akkor sem, ha nem az openvpn szervereken van a két központi dns szerver, hanem másik két gépen..., de a két openvpn szerveren más-más irányba van routolva a 10.10.10.1.

Korrekt nem?
...tulajdonképpen (szerintem, most), elegáns is, mivel nem kell semmi dinamikus dolog hozzá, mondjuk ellenőrzés hogy elérhető-e, és aszerint routolást változtatni scriptből, vagy ilyesmi...

Mi a véleményed a dologról?
Asszem meg is csinálom, bár jelenleg nekem nem éri meg a belefektetett időt.

túlbonyolítod ezt a dolgot:))

ha 2 azonos ip van egy hálózatban az zavarokat okozhat, ami nem szerencsés.

én azt csinálnám, hogy 'k' hálózaton egy szerver és nem egy router v routerek fogadják a vpn klienseket.
a kliens hálózatok routerei feléptik a vpn kapcsolatot a vpnserver.k-val, a kliensek up scriptje pedig betesz egy/két plusz sort a /tmp/resolv.dnsmasq fájlba: 

nameserver 'ns1.k ip címe'
nameserver 'ns2.k ip címe'

"oszt jónapot" még a server= sorok sem kellenek, és minden hálózat routerén ugyanazt kell végrehajtani.

vpnserver.k-ban pedig bridgelhetsz, routolhatsz, v amit akarsz. 'k' hálózaton pedig felállíthatsz egy ns2.k gépet ha szükséges.

kérdés, hogy az internet szélessége, és vpnszerver.k teljesítménye elég lesz e a feladathoz.

Hát igen..., bonyolítom, de szeretem! :)

"egy/két plusz sort a /tmp/resolv.dnsmasq fájlba"
Ez azért nem jó szerintem, ( up scriptel vagy anélkül ), mert az hogy több sor van a resolv.conf-ban és sorban próbálja, és az hogy alhálózat szerint (mondjuk internet vagy 10.0.0.0/8 ) más-más dns-t hasznák..., nem mindegy a sebesség miatt sem, de azért sem, mert a sajátot nem akarom terhelni internetes ip-kkel, kifelé meg nem szeretném ha menne belső "adat".

Az alhálózati routereken a dnsmasq és a központin (tartalékkal együtt, csak a tartalék még nincs használva) a bind megvan. Működik jól, beleértve a jogosultságokat, azaz hogy melyik alhálózatból melyik másik alhálózatra vonatkozó kéréseket szolgáljon ki (vagy továbbítson).
Ez így szép szerintem. (bind-view a központikon).

Azt a kérdést hogy hogyan használják az alhálózati routerek a tartalék k.dns-t, ha szükséges..., egyelőre elnapolom, elöbb utána kell néznem hogy openvpn redunancia hogyan.
Viszont jobban belegondolva a dologba, szerintem nem kell kétségbeesni attól hogy egy ip több helyen szerepel a hálózatban... (vagy kétségbeesés helyett inkább kevésbe nevezhető rondának mint eddig gondoltam), mivel pl. a 128.0.0.1 is pont ilyen.

hm.
Tulajdonképpen az a legjobb és magától értetődő megoldás, hogy a két rendes k.dns mellé az openvpn szerverekre is csinálok egy-egy dns szervert (ilyen virtuális interface-re, ami lehet hogy az openvpn-é is egyben), ami csak továbbítja a kéréseket az elsődleges vagy a másodlagos k.dns szerver felé..., azaz amiben be lehet állítani tartalékot.

...hogy ez eddig miért nem jutott eszembe!? ...vagy van ezzel a megoldással valami baj? (már túlságosan belebonyolódtam a dologba ahhoz, hogy minden részletére gondoljak.)

utólag: hm, ez sem jó..., mivel elveszne az eredeti kérdező..., és már nem működne a jogosultsági dolog. :(

Amúgy könnyen lehet hogy ilyen azonos ip-jű interface már eleve van ha redundáns openvpn.

Hát asszem marad a valamiféle ellenőrző script, leginkább olyan, hogy egy ilyen virtuális interface-t állítok be dns-nek az alhálózati routereken. ...ellenőrzöm a scriptel a k.vpn szervereken hogy elérhető-e az elsődleges k.dns, amire a virtuális interface 53-as portja továbbítva van. Ha igen, akkor ok. Ha nem, akkor a másodlagosra irányítja a portot.

Nincs ip kétszer a hálózatban és rugalmasabb is (redundánsabb)..., csak nem szeretem ilyen célra a scripteket (vagy aktív-dinamikus dolgokat. (ahol ellenőrizni kell valamit, és aszerint változtatni.)
...de nekem tetsző megoldást nem tudok kitalálni. :(

arra van egy beallitas (fejbol nemtudom a nevet) a dnsmasq-ban hogy a belsohalos feloldasokat elfogadjon-e vagy sem. tehat megkerdezi egy kulso dns-tol hogy mi a cime a izeize.bigyo.hu-nak, es ha egy belsohalos cim jon valasznak akkor megtartsa-e vagy sem. ezert latod hogy tcpdump-ban megjon a valasz, de megis errort kapsz nslookuppal.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!