DDNS, DHCP und Firewall (mit Beispiel)
|
Hinweis: Bitte überprüfen, ob auch alles vom alten Beitrag übernommen wurde. Hier der Link zum alten Beitrag |
|
|
Hinweis: Es sind noch alte Links in diesem Wiki enthalten, bitte korrigieren |
|
|
Hinweis: Lizensen prüfen und festlegen |
Wann wird Bind benötigt?
Grundsätzlich ist das schwer zu beantworten. Hier ein paar herausstechende Features und Punkte:
- Man verwaltet ein Netzwerk mit mehreren Subnet's oder/und Domänen
- Das Netzwerk soll einen Backup-Namens-Server erhalten auch Slave genannt
- Es wird rekursive Namensauflösung benötigt
- DNSSEC, Verschlüsselung der Zonen
- TSIG Verschlüsselung von Kommunikation zwischen Slave- und Master-Namens-Servern
- Du bist Bastler und willst Dich damit einfach beschäftigen
Meine Netzwerkbeschreibung
Mein lokales Netzwerk beinhaltet einen Debian-Lenny-Client feld-bert und einen Windows-XP-Client feld-drizzt, ab und zu sind auch noch Gäste bei uns zu Hause, vorwiegend Windows Rechner. Also Router/Gateway/Server nutze ich einen ausrangierten Rechner mit Debian Lenny. Das Interface meines Servers zum lokalen Netzwerk heißt br0 und meine Schnittstelle zum Internet heißt ppp0.
Der dns-sec key
Damit dhcp und bind miteinander sprechen können, muss ein Schlüssel erzeugt werden. Dieser Schlüssel wird auch für das Programm nsupdate verwendet. Für rndc (Verwaltungs-Programm für Bind) kann ein eigener Schlüssel oder der gleiche Schlüssel wie für Bind/DHCP oder eben kein Schlüssel verwendet werden. Der Name der Datei die unseren Schlüssel enthält soll also nur den Domänen-Namen enthalten und nicht den Rechner-Namen, also in meinem Fall nur feldland.lan., somit ist es für Admins mit mehreren Domänen einfacher diese zuzuordnen.
cd /etc/bind
# Der DNS SEC Key für bind und dhcpd wird erzeugt
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST $(hostname -d)
# Falls der Schlüssel in einer Variablen weiterverarbeitet werden muss:
export DNSKEY=$(awk '/^Key/ {print $2}' K$(hostname -d).+157+*private) /etc/bind
\# Der DNS SEC Key für bind und dhcpd wird erzeugt
dnssec-keygen -a HMAC-MD5 -b 128 -n HOST $(hostname -d)
\# Falls der Schlüssel in einer Variablen weiterverarbeitet werden muss:
export DNSKEY=$(awk '/^Key/ {print $2}' K$(hostname -d).+157+*private)
Falls es mal länger dauern sollte, mit der Erstellung des Schlüssels, dann liegt es daran das auf dem PC nicht genügend Zufallszahlen produziert werde, die für die Generierung des Schlüssels verwendet werden. In diesem Falle ändern wir den Befehl wie folgt um.
dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 128 -n HOST $(hostname -d)
Dafür wird aber vorrausgesetzt, dass das Device /dev/urandom vorhanden ist. Wir haben nun einen 128 Bit Schlüssel erzeugt, es wäre aber auch möglich gewesen einen 512 Bit Schlüssel zu erzeugen, was sicherer gewesen wäre. Der Inhalt der Datei Kfeldland.lan.+157+34326.key sieht so aus:
feldland.lan. IN KEY 512 3 157 SNCrjhQV8NiY6bsA5GMIJg==
Und Kfeldland.lan.+157+34326.private sieht so aus:
Private-key-format: v1.2
Algorithm: 157 (HMAC_MD5)
Key: SNCrjhQV8NiY6bsA5GMIJg==
Bits: AAA=
Fehlersuche
Standardmäßig kommt Bind mit eingeschränkten Berechtigungen für das Verzeichnis /etc/bind/ daher.
stat --printf="%a %A %U %G \n" /etc/bind/
2755 drwxr-sr-x root bind
Damit Zonen-Updates durchgeführt werden können müssen diese erst angepasst werden. Der Benutzer bind oder die Gruppe bind sollte Schreibrechte haben wie folgt:
chmod g+w /etc/bind/
stat --printf="%a %A %U %G\n" /etc/bind/
2775 drwxrwsr-x root bind
Und für die Dateien in /etc/bind/ habe ich folgende Berechtigungen eingestellt:
-rw-r--r-- 1 root root 237 20. Dez 21:21 db.0 -rw-r--r-- 1 root root 271 20. Dez 21:21 db.127 -rw-r--r-- 1 bind bind 494 31. Mär 22:29 db.192.168.0 -rw-r--r-- 1 bind bind 4092 31. Mär 22:15 db.192.168.0.jnl -rw-r--r-- 1 root root 237 20. Dez 21:21 db.255 -rw-r--r-- 1 root root 353 20. Dez 21:21 db.empty -rw-r--r-- 1 bind bind 538 31. Mär 22:27 db.feldland.lan -rw-r--r-- 1 bind bind 6717 31. Mär 22:15 db.feldland.lan.jnl -rw-r--r-- 1 root root 270 20. Dez 21:21 db.local -rw-r--r-- 1 root root 2878 20. Dez 21:21 db.root -rw-r----- 1 root bind 68 26. Mär 00:18 Kfeldland.lan.+157+34326.key -rw-r----- 1 root bind 92 26. Mär 00:18 Kfeldland.lan.+157+34326.private -rw-r--r-- 1 root bind 567 31. Mär 23:02 named.conf -rw-r--r-- 1 root bind 350 31. Mär 23:02 named.conf.local -rw-r--r-- 1 root bind 282 31. Mär 18:35 named.conf.options -rw-r----- 1 bind root 282 31. Mär 17:29 rndc.key -rw-r--r-- 1 root root 1317 20. Dez 21:21 zones.rfc1918
Wichtig ist halt das der daemon bind, der ja als User bind und Gruppe bind läuft auf die wichtigsten Zonen Schreib- und Lese-Zugriff hat, alles andere kann aus Sicherheitsgründen nur Lesend bleiben.
Zum Verwalten von Bind wird das rndc Programm empfohlen, welches in meinem Fall einen Schlüssel benötigt. ich habe für das programm rndc den gleichen Schlüssel den auch DHCP nutzt verwendet, was nicht unbedingt nötig gewesen wäre, aber da ich faul bin und gerne Riskant lebe ....Beispiel zu rndc:
rndc -s localhost -k /etc/bind/rndc.key reload
Um ein Zonen-Update manuell auszuführen wechsel ich diesmal ins Bind-Verzeichnis und führe dann das Programm nsupdate mit dem Schlüssel Kfeldland.lan.+157+34326.key aus, der als Datei im Bind-Verzeichnis liegen muss.
cd /etc/bind/
nsupdate -k Kfeldland.lan.+157+34326.key
> server feld-server
> update add feld-test.feldland.lan 86400 A 192.168.0.150
> send
In diesem Fall haben wir nsupdate von einem Client ausgeführt. Auf dem Server hätte man feld-server durch localhost ersetzt. Wenn wir dann in /var/log/daemon.log reinschauen sollte etwas ähnliches stehen wie:
Mar 31 18:47:46 feld - server named [2994]: client 192.168.0.186 # 54151: signer " feld - server . feldland . lan " approved Mar 31 18:47:46 feld - server named [2994]: client 192.168.0.186 # 54151: updating zone ’ feldland . lan / IN ’: adding an RR at ’ feld - test . feldland . lan ’ A
Beenden tut man die interaktive Sitzung mit CTRL+D. Wichtig ist auch das der Bind-server auf der lokalen IP-Adresse horcht, also mindestens auf der Adresse 127.0.0.1. Wo der Bind horchen soll kann mit dem listen Statement eingestellt werden. Soll und Ist sind aber meistens verschiedene Geschichten, daher sollte mit dem folgenden Befehl überprüft werden worauf er wirklich horcht:
lsof -ni:53
> COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
> named 2979 bind 20u IPv4 6816 TCP 127.0.0.1:domain (LISTEN)
> named 2979 bind 21u IPv4 6818 TCP 192.168.0.186:domain (LISTEN)
> named 2979 bind 512u IPv4 6815 UDP 127.0.0.1:domain
> named 2979 bind 513u IPv4 6817 UDP 192.168.0.186:domain
Dort sollte zumindest 127.0.0.1 aufgeführt werden, sonst kann der DHCP den DNS-Server nicht mal über das interne Netzwerk ansprechen.
Vom Client kann man auch den ping Befehl zum testen nutzen. Sowohl mit oder FQDN sollte folgendes auf der Konsole erscheinen:
markus@feld-bert:~$ ping -c 1 feld-bert
PING feld-bert.feldland.lan (192.168.0.196) 56(84) bytes of data.
64 bytes from feld-bert.feldland.lan (192.168.0.196): icmp_seq=1 ttl=64 time=0.074 ms
markus@feld-bert:~$ ping -c 1 feld-bert.feldland.lan
PING feld-bert.feldland.lan (192.168.0.196) 56(84) bytes of data.
64 bytes from feld-bert.feldland.lan (192.168.0.196): icmp_seq=1 ttl=64 time=0.060 ms
Auf der Client Seite habe ich für den hostnamen nur feld-bert eingestellt, also nicht den FQDN. Und der DHCP-Client sollte den hostnamen zum DHCP-Server senden. Auf dem Server steht dann in der /var/lib/dhcp3/dhcpd.leases
. . .
lease 192.168.0.196 {
starts 3 2010/03/31 20:15:11;
ends 4 2010/04/01 00:15:11;
cltt 3 2010/03/31 20:15:11;
binding state active;
next binding state free;
hardware ethernet 00:1d:92:ab:35:9f;
uid "\000\035\222\2535\237";
set ddns-rev-name = "196.0.168.192.in-addr.arpa.";
set ddns-txt = "3115fa25750bc8e429a401b9bcd1959433";
set ddns-fwd-name = "feld-bert.feldland.lan";
client-hostname "feld-bert";
. . .
}
Die Zeilen die mit set beginnen machen deutlich das was gesetzt wurde und zwar in diesem Fall Einträge in meine Forward- und Reverse-Zonen meines lokalen Netzwerks. Bei einem Fehler, also wenn es kein Zonen-Update gab, sieht es wie folgt aus:
lease 192.168.0.188 {
starts 3 2010/03/31 20:58:41;
ends 4 2010/04/01 00:58:41;
cltt 3 2010/03/31 20:58:41;
binding state active;
next binding state free;
hardware ethernet 00:1e:8c:6d:00:6c;
uid "\001\000\036\214m\000l";
client-hostname "feld-drizzt";
}
Fehlersuche welche Namensserver werden wirklich befragt?
Um sicher zu gehen das auch wirklich die Namensanfragen an den DNS-Server geschickt werden, können Paket-Sniffer eingesetzt werden, sowohl auf dem Client als auch auf dem Server. Als Tools wären da zu empfehlen wireshark und tcpdump.
Fehlersuche Firewall
Ich habe lange überlegt, ob ich eine Fehlersuche zu meiner Firewall mit reinstellen sollte. Einige würden mich dafür am liebsten töten. :-) Ich tue es trotzdem, da die Firewall bei mir ein großes Problem war in Hinsicht auf die Ansprechbarkeit meines DHCP- und DNS/DDNS-Servers. Es ist wichtig das man seine Firewall nochmal mit dem Befehl iptables -L -v -n durchgeht, um zu sehen, ob es überhaupt möglich ist den Server zu kontaktieren. So sieht es zur Zeit bei mir aus:
feld-server:~/bin# iptables -L -v -n
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 LOG all -- !lo * 127.0.0.1 0.0.0.0/0 LOG flags 0 level 4 prefix `Loopback gespooft: '
0 0 DROP all -- !lo * 127.0.0.1 0.0.0.0/0
0 0 LOG tcp -- !lo * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 LOG flags 0 level 6 prefix `IDENT Anfrage: '
0 0 REJECT tcp -- !lo * 0.0.0.0/0 0.0.0.0/0 tcp dpt:113 reject-with icmp-port-unreachable
16 2499 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1428 123K states all -- ppp0 * 0.0.0.0/0 0.0.0.0/0
0 0 DROP udp -- * * 188.96.76.70 0.0.0.0/0 udp spts:137:139
0 0 DROP udp -- * * 188.96.76.70 0.0.0.0/0 udp dpts:137:139
0 0 DROP tcp -- * * 188.96.76.70 0.0.0.0/0 tcp spts:137:139
0 0 DROP tcp -- * * 188.96.76.70 0.0.0.0/0 tcp dpts:137:139
1 48 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 12
490 66358 dsl-in all -- ppp0 * 0.0.0.0/0 0.0.0.0/0
69884 98M int-in all -- br0 * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `INPUT: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 LOG all -- !lo * 127.0.0.1 0.0.0.0/0 LOG flags 0 level 4 prefix `Loopback gespooft: '
0 0 DROP all -- !lo * 127.0.0.1 0.0.0.0/0
21784 18M states all -- ppp0 * 0.0.0.0/0 0.0.0.0/0
0 0 DROP udp -- * * 188.96.76.70 0.0.0.0/0 udp spts:137:139
0 0 DROP udp -- * * 188.96.76.70 0.0.0.0/0 udp dpts:137:139
0 0 DROP tcp -- * * 188.96.76.70 0.0.0.0/0 tcp spts:137:139
0 0 DROP tcp -- * * 188.96.76.70 0.0.0.0/0 tcp dpts:137:139
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 0
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 3
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 11
21784 18M ext-fw all -- ppp0 br0 0.0.0.0/0 0.0.0.0/0
18777 3854K int-fw all -- br0 ppp0 0.0.0.0/0 0.0.0.0/0
229 31978 int-int-fw all -- br0 br0 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `FORWARD: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
16 2499 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
20 8782 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
496 37741 dsl-out all -- * ppp0 0.0.0.0/0 0.0.0.0/0
36838 2937K int-out all -- * br0 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `OUTPUT: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain dsl-in (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:123 dpt:123
0 0 ACCEPT tcp -- * * 0.0.0.0 0.0.0.0/0 tcp spt:53 dpts:1024:65535 flags:!0x17/0x02
0 0 ACCEPT udp -- * * 0.0.0.0 0.0.0.0/0 udp spt:53 dpts:1024:65535
0 0 ACCEPT tcp -- * * 195.50.140.114 0.0.0.0/0 tcp spt:53 dpts:1024:65535 flags:!0x17/0x02
243 30959 ACCEPT udp -- * * 195.50.140.114 0.0.0.0/0 udp spt:53 dpts:1024:65535
0 0 ACCEPT tcp -- * * 195.50.140.252 0.0.0.0/0 tcp spt:53 dpts:1024:65535 flags:!0x17/0x02
247 35399 ACCEPT udp -- * * 195.50.140.252 0.0.0.0/0 udp spt:53 dpts:1024:65535
0 0 ACCEPT tcp -- * * 195.50.140.114 0.0.0.0/0 tcp spt:53 dpts:1024:65535 flags:!0x17/0x02
0 0 ACCEPT udp -- * * 195.50.140.114 0.0.0.0/0 udp spt:53 dpts:1024:65535
0 0 ACCEPT tcp -- * * 195.50.140.252 0.0.0.0/0 tcp spt:53 dpts:1024:65535 flags:!0x17/0x02
0 0 ACCEPT udp -- * * 195.50.140.252 0.0.0.0/0 udp spt:53 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:21 dpts:1024:65535 flags:!0x17/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:20 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpts:1024:65535 flags:!0x17/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 dpts:1024:65535 flags:!0x17/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:443 dpts:1024:65535 flags:!0x17/0x02
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpt:4666
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:4666
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpt:4662
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:4662
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `DSLIN: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain dsl-out (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:123 dpt:123
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0 tcp spts:1024:65535 dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 195.50.140.114 tcp spts:1024:65535 dpt:53
244 18252 ACCEPT udp -- * * 0.0.0.0/0 195.50.140.114 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 195.50.140.252 tcp spts:1024:65535 dpt:53
252 19489 ACCEPT udp -- * * 0.0.0.0/0 195.50.140.252 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 195.50.140.114 tcp spts:1024:65535 dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 195.50.140.114 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 195.50.140.252 tcp spts:1024:65535 dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 195.50.140.252 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:21
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:20 flags:!0x17/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:443
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:6667:6668 dpts:6667:6668
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:4666 dpts:1024:65535
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `DSLOUT: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain ext-fw (1 references)
pkts bytes target prot opt in out source destination
207 15732 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:123 dpt:123
0 0 ACCEPT tcp -- * * 0.0.0.0 0.0.0.0/0 tcp spt:53 dpts:1024:65535
0 0 ACCEPT udp -- * * 0.0.0.0 0.0.0.0/0 udp spt:53 dpts:1024:65535
0 0 ACCEPT tcp -- * * 195.50.140.114 0.0.0.0/0 tcp spt:53 dpts:1024:65535
0 0 ACCEPT udp -- * * 195.50.140.114 0.0.0.0/0 udp spt:53 dpts:1024:65535
0 0 ACCEPT tcp -- * * 195.50.140.252 0.0.0.0/0 tcp spt:53 dpts:1024:65535
0 0 ACCEPT udp -- * * 195.50.140.252 0.0.0.0/0 udp spt:53 dpts:1024:65535
0 0 ACCEPT tcp -- * * 195.50.140.114 0.0.0.0/0 tcp spt:53 dpts:1024:65535
0 0 ACCEPT udp -- * * 195.50.140.114 0.0.0.0/0 udp spt:53 dpts:1024:65535
0 0 ACCEPT tcp -- * * 195.50.140.252 0.0.0.0/0 tcp spt:53 dpts:1024:65535
0 0 ACCEPT udp -- * * 195.50.140.252 0.0.0.0/0 udp spt:53 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:21 dpts:1024:65535 flags:!0x17/0x02
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:20 dpts:1024:65535
779 165K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpts:1024:65535 flags:!0x17/0x02
15753 14M ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 dpts:1024:65535
5045 3541K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:443 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:25 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:465 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:110 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:995 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:143 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:993 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:119 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:563 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:70 dpts:1024:65535
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:210 dpts:1024:65535
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpt:4666
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:4666
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpt:4662
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:4662
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:11235:11238 dpts:1024:65535
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:56158 dpt:56158
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:11239:11267 dpts:1024:65535
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:27732:27755 dpts:1024:65535
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:9963 dpts:1024:65535
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:7808 dpt:7808
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:7808 dpt:7808
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:7117 dpt:7117
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:7117 dpt:7117
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:1234 dpt:7808
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `EXTFW: '
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain int-fw (1 references)
pkts bytes target prot opt in out source destination
210 15960 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:123 dpt:123
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0 tcp spts:1024:65535 dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 195.50.140.114 tcp spts:1024:65535 dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 195.50.140.114 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 195.50.140.252 tcp spts:1024:65535 dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 195.50.140.252 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 195.50.140.114 tcp spts:1024:65535 dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 195.50.140.114 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 195.50.140.252 tcp spts:1024:65535 dpt:53
0 0 ACCEPT udp -- * * 0.0.0.0/0 195.50.140.252 udp spts:1024:65535 dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:21
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:20 flags:!0x17/0x02
702 144K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpts:1024:65535
13744 2335K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:80
4096 1358K ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:443
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:25
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:465
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:110
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:995
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:143
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:993
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:119
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:563
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:70
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:1024:65535 dpt:210
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spts:6667:6668 dpts:6667:6668
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpt:50945
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:4666 dpts:1024:65535
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:11235:11238 dpt:22340
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpts:11235:11238
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpts:11239:11267
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpts:27732:27755
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:9960 dpt:9960
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:9963 dpt:9963
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:27960 dpt:27960
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:27960 dpt:27950
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:27960 dpt:27951
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpt:7777
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:7808 dpt:7808
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:7808 dpt:7808
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:7117 dpt:7117
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:7117 dpt:7117
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:7808 dpt:1234
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:7808 dpt:1234
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpt:33001
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:5120:5300 dpt:6121
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:1024:65535 dpts:5120:5300
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:13139 dpt:13139
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spts:5120:5300 dpts:5120:5300
25 1400 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `INTFW: '
25 1400 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain int-in (1 references)
pkts bytes target prot opt in out source destination
69884 98M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain int-int-fw (1 references)
pkts bytes target prot opt in out source destination
229 31978 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
Chain int-out (1 references)
pkts bytes target prot opt in out source destination
36838 2937K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
Chain states (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmp type 8
938 56372 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW LOG flags 0 level 4 prefix `Unerwuenschte Verbindung: '
938 56372 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW
22274 18M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
Es gibt 3 Chains, die die Kette der Firewall repräsentieren, INPUT, FORWARD und OUTPUT. Alle Datenpackete die nur in meine Server rein aber nicht weiter gehen sollen kommen in die INPUT-Chain. Alles was von meinem Server nach draußen geht, egal ob Internet oder lokales Netzwerk, kommt in die OUTPUT-Chain. Und alle Datenpackete die mur meinen Server passieren gelangen in die FORWARD-Chain. Nun habe ich noch eigene Chains definiert um eine feinere Filterung vornehmen zu können.
Beispiel 1: feld-bert sendet eine Namensauflösungs-Anfrage an feld-server (Port 53). Das heißt das Datenpacket geht nur in meinen Server rein und nicht weiter, also kommt es in die INPUT-Chain. In der obigen Ausgabe sind mehrere Spalten zu erkennen unter anderem in und out, was mir Auskunft gibt über die Interfaces welches das Datenpacket passieren muss, damit diese Regel greift. Weitere Kriterien sind die genaue Quell- und Ziel-IP-Adresse, sowie die Port Nummer, die der letzten Spalte rechts entnommen werden kann und natürlich auch das verwendete Protokoll z.b. tcp, udp oder icmp.
Unser Packet durchläuft die regeln von oben nach unten und wird aber erst bei folgender Regel weiter verarbeitet:
69884 98M int-in all -- br0 * 0.0.0.0/0 0.0.0.0/0
Unser Packet ist über das Interface br0 rein gekommen und will dann zum DNS-Damonen direkt hin, was auch durch das Sternchen abgedeckt wird. Als Quell- und Ziel-IP-Adresse kann auch jede angegeben werden. Alles passt. Die Regeln darüber hatten immer irgendwo nicht gepasst, aber jetzt passt es. Nun wird dieses Packet an die selbst definierte Chain int-in weitergeleitet, die wiederum Regeln enthält. Wenn keine der Regeln der int-in-Chain greifen sollte, also das Paket am Ende der Chain angelangt ist, so wird die default Policy angewendet, in meinem Fall ist die default Policy auf DROP gestellt, daher würde das Paket verworfen werden. Daher habe ich am Ende meiner Chains immer LOG-Regeln die Pakete protokollieren, wenn das Paket auf keines der Regeln passt. Somit weiß ich immer wo der Schuh drückt, wenn mal irgendein Dienst nicht funktioniert und natürlich dient das Loggen zur Überprüfung von Hackern. Das bedeutet das die Reihenfolge der Regeln absolut wichtig sind. Können mehrere Regeln greifen, dann zählt immer die erste Regel die greift. Ein häufig nicht beachteter Punkt.
Da mein Packet nun in die int-in-Chain gelangt ist und die erste Regel dort besagt, das ALLES was hier rein kommt Akzeptiert wird, kann das Packet nun endgültig zum DNS-Daemonen gesendet werden. Für den Fall der Fälle baue ich immer eine DROP-Regel ein, falls ich einen Fehler bei meiner Firewall gemacht habe. Außerdem besagt dies auch gleich, dass Packete die hier rein kommen hier auch enden und nicht wieder in die INPUT-Chain gelangen. Wichtig !!!
Beispiel2: Mein DNS-Server hat das Packet empfangen und will nun drauf antworten. Also schickt er ein Packet and feld-bert zurück. Das Packet soll also aus den Server rauß, daher kommt dieses in die OUTPUT-Chain. Folgende Regel greift in diesem Fall:
36838 2937K int-out all -- * br0 0.0.0.0/0 0.0.0.0/0
Das Packet kommt vom lokalen Process/DNS-Daemonen was durch das Sternchen bei der Spalte in abgedeckt wird und will über das Interface br0 wieder rauß. An Protokollen, Quell- und Ziel-IP-Adressen sind alle zugelassen. Somit passt alles mal wieder. Als Target/Aktion wurde eine Weiterleitung an die eigene Chain int-out angegeben. Die int-out regel ist bei läßt alle Packete zu (ACCEPT), falls nicht wird es sofort in der nächsten Regel dieser eigenen Chain verworfen (DROP).
Man kann also zusammengefasst sagen, dass ich meinen lokalen Netzwerkverkehr nicht großartig blockiere, sondern alles zu lasse. Nur was den Verkehr ins Internet oder vom Internet ins lokale Netz betrifft, habe ich strenge Regeln.
Hier noch eine grafische Abbildung meines Netzwerks aus Sicht der Firewall.
DNS Server - BIND 9
/etc/bind/named.conf
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
// prime the server with knowledge of the root servers
zone "." {
type hint;
file "/etc/bind/db.root";
};
/etc/bind/named.conf.options
key "rndc-key" {
algorithm hmac-md5;
secret Aei1JRlz9M7RhNqEYYsGdg==; };
controls {inet 127.0.0.1 port 953 allow { localhost; } keys { "rndc-key"; }; };
options {
directory "/var/cache/bind";
forwarders {
195.50.140.114;
195.50.140.252;
};
listen-on { 127.0.0.1; 192.168/16; };
allow-query { 127.0.0.1/32; 192.168.0/24; 192.168.1/24; };
};
Das controls Statement gibt uns Auskunft wie wir Bind über das Administrations-Programm rndc anzusprechen haben. rndc muss also also auf der Konsole des Servers ausgeführt werden, zudem muss Bind über den Port 953 angesprochen werden und zu guter Letzt müssen wir auch noch einen Key angeben. Hier ein Beispiel:
feld-server:~# cd /etc/bind
feld-server:/etc/bind# rndc -s localhost -k rndc.key reload
server reload successful
Eigentlich ist meine Firewall gut genug und wenn man dann noch berücksichtigt, dass mein rndc sowieso nur auf dem Server selber ausgeführt werden kann, dann wäre zu überlegen ob ich auf einen extra Schlüssel für rndc verzichte. Ohne Schlüssel für rndc sehe unser controls-Statement wie folgt aus:
controls {inet 127.0.0.1 allow { localhost; } keys { }; };
Das ausdrückliche Angeben des Ports habe ich auch mal weggelassen, da dieser sowieso Standard ist. Empfohlen wird es nicht den Schlüssel weg zu lassen! Sicher ist sicher, wie meine Freundin sagen würde, aber die macht auch 3 Knoten in ihre Schuhe. :-)
Der Inhalt der Datei rndc.key sieht jedenfalls wie folgt aus:
key "rndc-key" {
algorithm hmac-md5;
secret Aei1JRlz9M7RhNqEYYsGdg==; };
Ich nutze also zur Zeit 2 Schlüssel. Einen den nsupdate,DHCP und das Programm BIND für Zonen-Updates nutzt und der zweite für das Administrations-Programm rndc. Den Schlüssel für rndc habe ich wie folgt erstellt:
feld-server:/etc/bind/test# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST $(hostname -d)
Kfeldland.lan.+157+46834
Die Dateien die dabei erzeugt werden, werden später nicht mehr benötigt, nachdem man das Passwort Aei1JRlz9M7RhNqEYYsGdg== in die Datei rndc.key und in die Key-Anweisung in der Datei named.conf.options eingetragen hat.
Noch was zur AllowQuery-Anweisung, hier sollten sowohl die IP-Bereiche des lokalen Netzes, als auch die loopback Adresse eingetragen sein, sonst kann man nur von Client zu Server oder von Server zu Client pingen. Mit unserem obigen Statement können die Clients den Server über seine FQDN anpingen und erhalten eine IP-Adresse zurück und vom Server kann man auch die Client's über ihre FQDN anpingen (FQDN = die Full Qualified Domain Name) und erhält die IP-Adresse des Servers. Ansonsten geht es nur Einseitig.
/etc/bind/named.conf.local
key feldland.lan. {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret SNCrjhQV8NiY6bsA5GMIJg==;
};
zone "feldland.lan" {
type master;
file "/etc/bind/db.feldland.lan";
notify yes;
allow-update { key feldland.lan.; };
forwarders {};
};
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.192.168.0";
notify yes;
allow-update { key feldland.lan.; };
forwarders {};
};
/etc/bind/db.192.168.0
$ORIGIN .
$TTL 86400 ; 1 day
0.168.192.in-addr.arpa IN SOA feld-server.feldland.lan. feldmann_markus.gmx.de. (
15 ; serial
28800 ; refresh (8 hours)
14400 ; retry (4 hours)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
NS feld-server.feldland.lan.
$ORIGIN 0.168.192.in-addr.arpa.
186 PTR feld-server.feldland.lan.
187 PTR feld-drizzt.feldland.lan.
188 PTR nbb.feldland.lan.
$TTL 7200 ; 2 hours
196 PTR feld-bert.feldland.lan.
/etc/bind/db.feldland.lan
$ORIGIN .
$TTL 86400 ; 1 day
feldland.lan IN SOA feld-server.feldland.lan. feldmann_markus.gmx.de. (
25 ; serial
28800 ; refresh (8 hours)
14400 ; retry (4 hours)
2419200 ; expire (4 weeks)
86400 ; minimum (1 day)
)
NS feld-server.feldland.lan.
$ORIGIN feldland.lan.
$TTL 7200 ; 2 hours
feld-bert A 192.168.0.196
TXT "3115fa25750bc8e429a401b9bcd1959433"
$TTL 86400 ; 1 day
feld-drizzt A 192.168.0.187
feld-server A 192.168.0.186
feld-test A 192.168.0.150
nbb A 192.168.0.188
/etc/bind/rndc.key
key "rndc-key" {
algorithm hmac-md5;
secret Aei1JRlz9M7RhNqEYYsGdg==; };
Hinweis
Unter /etc/bind gibt es jetzt für jede dynamische Zonendatei eine Datei, die auf jnl (=journaling) endet. Diese legt der bind an, um die dynamischen Updates zwischenzuspeichern. Sobald der bind gestoppt wird, schreibt er die Änderungen zurück in die Zonendatei. Um hier Inkonsistenzen zu vermeiden, solltest du niemals bei laufendem Bind das Zonenfile von Hand ändern. Nimm lieber nsupdate dafür.
Einen Host von Hand hinzufügen/löschen
nsupdate -k Kfeldland.lan.+157+34326.private
> update add sql.feldland.lan 86400 IN A 192.168.0.42
> server feld-server
> send
> update add 42.0.168.192.in-addr.arpa 86400 IN PTR sql.feldland.lan
> send
> quit
nsupdate -k Kfeldland.lan.+157+34326.private
> update delete sql.feldland.lan
> server feld-server
> send
> update delete 42.0.168.192.in-addr.arpa
> send
> quit
Das Kommando server feld-server wird dabei in meinem Fall vom Client ausgeführt. Wenn man nsupdate auf dem Server selber ausführen will, gibt man server localhost an, ansonsten könnte ein Fehler erscheinen, dass keine Kommunikation zum Server aufgebaut werden konnte.
DHCP 3 - Server
/etc/dhcp/dhcpd.conf
ddns-update-style interim;
ddns-updates on;
ddns-domainname "feldland.lan";
ddns-rev-domainname "in-addr.arpa.";
update-static-leases true;
deny client-updates;
#Unknown Clients sollen IP bekommen. Bin zu faul hosts zu definieren.
allow unknown-clients;
default-lease-time 14400;
max-lease-time 86400;
authoritative;
key feldland.lan. {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret SNCrihQV8NjY6bzA5GMJIg==;
};
zone feldland.lan. {
primary 127.0.0.1;
key feldland.lan.;
}
zone 0.168.192.in-addr.arpa. {
primary 127.0.0.1;
key feldland.lan.;
}
subnet 192.168.0.0 netmask 255.255.255.0 {
allow unknown-clients;
range 192.168.0.100 192.168.0.200;
option subnet-mask 255.255.255.0;
option routers 192.168.0.186;
option domain-name-servers 192.168.0.186;
option domain-name "feldland.lan";
}
|
|
Hinweis: In Debian Squeeze liegt die Konfiguration unter /etc/dhcp/ wobei sie bei älteren Versionen noch in einem ähnlich lautendem Verzeichnis liegen kann. |
Das Argument des Befehls option routers kann sowohl die IP-Adresse als auch den vollen Domänen-Namen des Servers enthalten. Die Angabe der IP-Adresse hat bei mir fehlerfrei funktioniert im Gegensatz zum Domänen-Namen, hängt aber wahrscheinlich davon ab wie gut die Namensauflösung konfiguriert ist.
Netzwerk allgemein des Servers
/etc/hostname
feld-server
/etc/resolv.conf
domain feldland.lan
nameserver 0.0.0.0
nameserver 195.50.140.114
nameserver 195.50.140.252
Client Einstellungen auf feld-bert
/etc/dhcp/dhclient.conf
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
send host-name "feld-bert";
send dhcp-client-identifier 00:1d:92:ab:35:9f;
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes;
timeout 10;
|
|
Hinweis: In Debian Squeeze liegt die Konfiguration unter /etc/dhcp/ wobei sie bei älteren Versionen noch in einem ähnlich lautendem Verzeichnis liegen kann. |
/etc/hostname
feld-bert
/etc/resolv.conf
domain feldland.lan
search feldland.lan
nameserver 192.168.0.186
/etc/network/interfaces
# The loopback network interface
auto lo
iface lo inet loopback
# Client sitzt hinter Router
allow-hotplug eth0
iface eth0 inet dhcp
#Client waehlt sich selber ins DSL-Modem ein
iface dsl-provider inet ppp
pre-up /sbin/ifconfig eth0 up # line maintained by pppoeconf
provider dsl-provider
Meine Client Konfiguration sieht ein wenig verwirrend aus, aber nicht so verwirrend wie die von meinem Server. Da mein Client-Rechner feld-bert sich bei Problemen/Ausfall meines Servers selber ins Internet einwählen muss, ist es sinnig hierfür vorzusorgen. Hierfür nutze ich die Software NetworkManager die nach Anmeldung des Benutzers alle Schnittstellen aktiviert die mit allow-hotplug gekennzeichnet sind. Wenn also mein Server läuft dann versucht das Programm Networkmanager die Schnittstelle eth0 zu aktivieren, diese fragt bei meinem DHCP-Server nach einer dynamischen IP-Adresse.