2012. április 23., hétfő

DDNS Ubuntu 12.04-en - harmadik rész

Az előző két alkalommal a már működő DHCP-szerverünk mellé telepítettünk DNS-szervert, majd megoldottuk, hogy a DNS-szerver a helyi hálózatról is tudomást szerezzen. Ma a DHCP-szervert bemutatjuk a DNS-szervernek: megoldjuk, hogy a kiosztott címek bekerüljenek a DNS-szerver információi közé.
Először a bind9-nek mondjuk meg, hogy hogy kitől kell elhinnie a dinamikusan érkező bejegyzéseket. Az /etc/bind/named.conf.local fájlba helyezzünk el két bejegyzést:
include "/etc/bind/rndc.key";
controls {
        inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
};
Az első sor a konfigurációs állományok közé felvesz egy, a BIND telepítésekor létrejött fájlt, amelyben egy kulcs található. A coltrols záradék pedig kábé ezt jelenti: a 127.0.0.1 címről érkező módosítási kérelmeket fogadjuk el, de azokat is csak akkor, ha bemutatja az rndc-key nevű kulcsot (a kulcs neve természetesen az rndc.key fájlban van megadva először).

Azoknak a zónáknak a végére, pedig, amelyekben engedélyezni akarjuk a DDNS-t, be kell tennünk, hogy:
allow-update { key "rndc-key"; };

A teljes /etc/bind/named.conf.local fájl:
include "/etc/bind/rndc.key";
controls {
        inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
};

zone "itthon.cucc" {
    type master;
    file "/var/lib/bind/itthon.cucc";
    allow-update { key "rndc-key"; };
};
zone "56.168.192.in-addr.arpa" {
    type master;
    file "/var/lib/bind/56.168.192";
    allow-update { key "rndc-key"; };
};

Adjuk ki a
sudo service bind9 reload
parancsot. Nézzük meg a syslog-ot, hogy minden oké-e. Ha igen, akkor gyerünk tovább a DHCP-szerverhez.

A dhcp démonnak is kelleni fog az rndc-kulcsot tartalmazó fájl. Elvileg kiolvashatná a bind9 könyvtárából, de nekem az istennek sem sikerült. Úgyhogy:
sudo cp /etc/bind/rndc.key /etc/dhcp/
sudo chown root:dhcpd /etc/dhcp/rndc.key

Szerkesszük az /etc/dhcp/dhcpd.conf fájlt (vastaggal az újdonság):
ddns-update-style interim;
include "/etc/dhcp/rndc.key";
authoritative;
log-facility local7;

subnet 192.168.168.0 netmask 255.255.255.0 {
    #A szerver külső kártyáján lévő háló.
    #Csak definiáljuk az alhálót, nem írunk bele semmit.
    #Azért tesszük ide, mert a DHCP-szerver szeret tudni az általa nem kezelt hálózatokról is.
}

subnet 192.168.56.0 netmask 255.255.255.0 {
    range 192.168.56.200 192.168.56.220;
    option routers 192.168.56.101;
    option domain-name-servers 192.168.56.101;
    option domain-name "itthon.cucc";
    default-lease-time 300;
    max-lease-time 600;
    zone itthon.cucc. {
        primary 192.168.56.101;
        key rndc-key;
    }
    zone 56.168.192.in-addr.arpa. {
        primary 192.168.56.101;
        key rndc-key;
    }
}
Az első sorban bekapcsoljuk a DDNS-t, a második betölti a kulcsot. A subnet megadásán túl immár zónát is definiálnunk kell, méghozzá külön a forward, külön a reverse zónát. Bennük megadjuk az elsődleges DNS-szervert (ezen kell végezni a frissítést), és a frissítéshez használandó kulcsot.

Ha most kiadjuk a
sudo service isc-dhcp-server reload
parancsot, akkor elvileg minden oké. Cattogjunk át a kliensre, és ha a kliens is Ubuntu, akkor nyomjunk olyat, hogy:
sudo dhclient -r
sudo dhclient eth0

A DHCP-szerver syslogjában ilyesmit kell látnunk (vastaggal a lényeg):
Apr 20 16:32:59 u3 dhcpd: DHCPDISCOVER from 08:00:27:bc:b1:32 via eth1
Apr 20 16:32:59 u3 dhcpd: DHCPOFFER on 192.168.56.200 to 08:00:27:bc:b1:32 (u4) via eth1
Apr 20 16:33:00 u3 named[2229]: client 192.168.56.101#44149: signer "rndc-key" approved
Apr 20 16:33:00 u3 named[2229]: client 192.168.56.101#44149: updating zone 'itthon.cucc/IN': adding an RR at 'u4.itthon.cucc' A
Apr 20 16:33:00 u3 named[2229]: client 192.168.56.101#44149: updating zone 'itthon.cucc/IN': adding an RR at 'u4.itthon.cucc' TXT
Apr 20 16:33:00 u3 dhcpd: Added new forward map from u4.itthon.cucc to 192.168.56.200
Apr 20 16:33:00 u3 named[2229]: client 192.168.56.101#42806: signer "rndc-key" approved
Apr 20 16:33:00 u3 named[2229]: client 192.168.56.101#42806: updating zone '56.168.192.in-addr.arpa/IN': deleting rrset at '200.56.168.192.in-addr.arpa' PTR
Apr 20 16:33:00 u3 named[2229]: client 192.168.56.101#42806: updating zone '56.168.192.in-addr.arpa/IN': adding an RR at '200.56.168.192.in-addr.arpa' PTR
Apr 20 16:33:00 u3 dhcpd: added reverse map from 200.56.168.192.in-addr.arpa. to u4.itthon.cucc
Apr 20 16:33:00 u3 dhcpd: DHCPREQUEST for 192.168.56.200 (192.168.56.101) from 08:00:27:bc:b1:32 (u4) via eth1
Apr 20 16:33:00 u3 dhcpd: DHCPACK on 192.168.56.200 to 08:00:27:bc:b1:32 (u4) via eth1

Egy-két host paranccsal érdemes ellenőrizni az eredményt. A DDNS beállításával ezzel végeztünk, de ha jót akarunk magunknak, akkor nem felejtjük el a magával a DNS-szerverrel is ezt használtatni, különben ő nem fog tudni a belső hálózatról. A dolgunk, hogy az /etc/network/interfaces fájlban az egyik kártyánál állítsuk be, hogy
dns-nameservers 127.0.0.1
dns-search itthon.cucc
Ezt követően pedig adjuk ki a
sudo /etc/init.d/networking restart
parancsot és egy-két jól irányzott host paranccsal teszteljük az eredményt.

Irodalom:
http://www.zytrax.com/books/dns/ch7/controls.html

5 megjegyzés:

dessant írta...

Szia
Nagíon jó a leírás, szépen csinálom is, folyamatosan. Kérdésem az lenne, hogy itt már szerintem kellene lenni netnek a kliens gépen igaz? Minden hiba nélkül lement idáig, de firefoxozni nem lehet a kliensen.
Virtualboxban van minden, a serverben két háló kártya nálam, első bridgelt másik belső csatoló fisx mind a kettő.
a klensen belső csatoló, ip-t kap a dhcp től, meg minden lement hiba nélkül, de nincs net sajna, van valam ötleted? Előre is köszi G.

raerek írta...

Hahó!
Igen, kéne lennie eddigre net-nek - belsőnek. Külső majd akkor lesz, ha iptables-szel megoldod a címfordítást. Keress az internetmegosztás, NAT, iptables kulcsszavakra, és neked nem a MASQUARADE-es leírások a jók - ezek azt feltételezik, hogy a szervered külső lába változó IP-t kap, pedig elvileg te azt fixre állítottad be.

dessant írta...

Szia
kicsit amatőr vagyok, de mi az a belső net?::)Nem csak belső hálózat?Ip címet kap,az jó, dns szerver fut, az felel a címrögzítésekért. Fordításért meg a NAT? És akkor lesz majd csak internet?

Előre is köszi G

raerek írta...

De, csak az. Azaz a szerver mögött csücsülő gépek látják egymást, de az internetre kifelé nem tudnak menni. Gondold át kicsit azt, hogy ez ugyanaz a szitu, mint amikor van otthon egy routered, meg két géped és a két gép látja egymást és a routert, de hogy a router mögött mi van, azt nem tudják. Nézz utánna, hogy mit csinál a routered, és érteni fogod. Na ugyanazt kell most megoldanod a szervereden is.

dessant írta...

Köszönöm a segítséget, keresek valami normális magyar leírást, aztán folytatom:)

Üdv