Der DHCP Server teilt IP-Adressen im Heimnetz zu, bestimmt die Laufzeit eines solchen „Lease“ ( Zuteilung ) und übergibt auch alle weiteren relevanten Informationen über das Heimnetz.
gateway: ~ #apt install isc-dhcp-server
was nach der Installation mit einem Start des Dienstes und, aufgrund unserer Systemkonfiguration wahrscheinlich mit einem Fehlstart quittiert wird.
Schauen wir uns die Konfig an:
gateway: ~ #nano /etc/dhcp/dhcpd.conf
dhcpd.conf
#
# Sample configuration file for ISC dhcpd
#
# option definitions common to all supported networks...
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;
default-lease-time 600;
max-lease-time 7200;
# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
#authoritative;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
#log-facility local7;
# No service will be given on this subnet, but declaring it helps the
# DHCP server to understand the network topology.
#subnet 10.152.187.0 netmask 255.255.255.0 {
#}
# This is a very basic subnet declaration.
#subnet 10.254.239.0 netmask 255.255.255.224 {
# range 10.254.239.10 10.254.239.20;
# option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
#}
# This declaration allows BOOTP clients to get dynamic addresses,
# which we don't really recommend.
#subnet 10.254.239.32 netmask 255.255.255.224 {
# range dynamic-bootp 10.254.239.40 10.254.239.60;
# option broadcast-address 10.254.239.31;
# option routers rtr-239-32-1.example.org;
#}
# A slightly different configuration for an internal subnet.
#subnet 10.5.5.0 netmask 255.255.255.224 {
# range 10.5.5.26 10.5.5.30;
# option domain-name-servers ns1.internal.example.org;
# option domain-name "internal.example.org";
# option routers 10.5.5.1;
# option broadcast-address 10.5.5.31;
# default-lease-time 600;
# max-lease-time 7200;
#}
# Hosts which require special configuration options can be listed in
# host statements. If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.
#host passacaglia {
# hardware ethernet 0:0:c0:5d:bd:95;
# filename "vmunix.passacaglia";
# server-name "toccata.example.com";
#}
# Fixed IP addresses can also be specified for hosts. These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP. Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
#host fantasia {
# hardware ethernet 08:00:07:26:c0:a5;
# fixed-address fantasia.example.com;
#}
# You can declare a class of clients and then do address allocation
# based on that. The example below shows a case where all clients
# in a certain class get addresses on the 10.17.224/24 subnet, and all
# other clients get addresses on the 10.0.29/24 subnet.
#class "foo" {
# match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
#}
#shared-network 224-29 {
# subnet 10.17.224.0 netmask 255.255.255.0 {
# option routers rtr-224.example.org;
# }
# subnet 10.0.29.0 netmask 255.255.255.0 {
# option routers rtr-29.example.org;
# }
# pool {
# allow members of "foo";
# range 10.17.224.10 10.17.224.250;
# }
# pool {
# deny members of "foo";
# range 10.0.29.10 10.0.29.230;
# }
#}
Wir sehen sofort, die einzigen aktiven Einträge sind für uns nicht zutreffend, weiter ist hier nichts als Erläuterungen zu den Möglichkeiten aufgezählt.
So kann das auch nicht laufen.
Die für uns interressanten Passagen:
# A slightly different configuration for an internal subnet.
#subnet 10.5.5.0 netmask 255.255.255.224 {
# range 10.5.5.26 10.5.5.30;
# option domain-name-servers ns1.internal.example.org;
# option domain-name "internal.example.org";
# option routers 10.5.5.1;
# option broadcast-address 10.5.5.31;
# default-lease-time 600;
# max-lease-time 7200;
#}
und
# Fixed IP addresses can also be specified for hosts. These addresses
# should not also be listed as being available for dynamic assignment.
# Hosts for which fixed IP addresses have been specified can boot using
# BOOTP or DHCP. Hosts for which no fixed address is specified can only
# be booted with DHCP, unless there is an address range on the subnet
# to which a BOOTP client is connected which has the dynamic-bootp flag
# set.
#host fantasia {
# hardware ethernet 08:00:07:26:c0:a5;
# fixed-address fantasia.example.com;
#}
Stricken wir uns daraus eine lauffähige Konfig:
gateway: ~ #mv /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.orig
und, obwohl wir offensichtlich hier nichts kaputt machen können, verschieben wir die Datei mal in eine Sicherung, dann
gateway: ~ #nano /etc/dhcp/dhcpd.conf
erstellen wir diese wieder neu, diesmal leer und tragen unsere Wünsche ein:
# Sample configuration file for ISC dhcpd for Debian
#
#
# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none; # es findet kein automatischer Abgleich mit unserem Nameserver statt, Zonendateien für unser Heimnetz verwalten wir manuell.
# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.
authoritative; #genau das ist sie, der CHEF der IP-Adressen
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.180 10.0.0.189;
option domain-name-servers 10.0.0.1;
option domain-name "erstes.netz";
option domain-search "erstes.netz";
option routers 10.0.0.1;
option ntp-servers 10.0.0.1;
option broadcast-address 10.0.0.255;
default-lease-time 14400;
max-lease-time 17200;
}
Das Subnetz erstes.netz. Damit kennt der DHCP jetzt alle wichtigen Informationen zu diesem Netz und wird diese auch an die Clients weitergeben.
range - alle Clients, die ins Netz kommen, ohne als "host NAME mit MAC" definiert zu sein, erhalten eine IP-Adresse zwischen 180 und 189. Ist dieser Bereich ausgeschöpft, weil mehr als 10 Clients so eingebunden sind, verweigert DHCP dem 11. Client den Dienst.
Die Optionen werden dem Client übergeben:
option - domain-name-servers, hier läuft der Nameserver, das kann dieser Server sein, muss aber nicht
- domain-name, die Domain dieses Subnetzes
- domain-search, dort suchst du bitte intern statt im Internet
- routers, setze hier deine default Route, also die IP von gateway für dieses Subnetz
- ntp-servers, hier bekommst du meine Zeit
- broadcast-address, hier darfst du rundrufen
default-lease-time, frage nach 14400 Sekunden nach einer neuen IP-Adresse, denn
max-lease-time, in 17200 Sekunden verfällt sie
subnet 10.0.1.0 netmask 255.255.255.0 {
range 10.0.1.180 10.0.1.189;
option domain-name-servers 10.0.1.1;
option domain-name "erstes.netz";
option domain-search "erstes.netz";
option routers 10.0.1.1;
option ntp-servers 10.0.1.1;
option broadcast-address 10.0.1.255;
default-lease-time 14400;
max-lease-time 17200;
}
Jetzt kennt der DHCP auch unser zweites.netz.
# Hosts which require special configuration options can be listed in
# host statements. If no address is specified, the address will be
# allocated dynamically (if possible), but the host-specific information
# will still come from the host declaration.
#host passacaglia {
# hardware ethernet 0:0:c0:5d:bd:95;
# filename "vmunix.passacaglia";
# server-name "toccata.fugue.com";
#}
Ab hier und so werden feste IP-Adressen verteilt. Dafür stehen alle Adressen zur Verfügung, die nicht im "range" liegen.
Nehmen wir als erstes unseren Verwaltungsrechner ins erstes.netz:
###########################################################
############ fixed IP section ################
###########################################################
############ erstes.netz ################
###########################################################
host meinPC {
hardware ethernet [MAC-von-meinPC];
fixed-address 10.0.0.2;
}
Wie sieht es aus, hat Dein PC Wlan und Du die Switches und AccessPoints am Start? Sonst muß Dein PC mit Kabel an den Switch von erstes.netz.
Ja? Dann kommt hier auch der/die AccessPoint(s) hin:
host AP1 {
hardware ethernet [MAC-von-AccessPoint1];
fixed-address 10.0.0.100;
}
###########################################################
############ fixed IP section ################
###########################################################
############ zweites.netz ################
###########################################################
host AP2 {
hardware ethernet [MAC-von-AccessPoint2];
fixed-address 10.0.1.100;
}
Warum steht im Subnet 10.0.1.0 auch erstes.netz bei option domain-name?
Gute Frage!
Es ist hier Deine Entscheidung, ob Du Dein zweites Subnetz mit einer eigenen Domain versorgen möchtest, oder eben nicht. Beides ist möglich.
Im oberen Beispiel ist für beide Subnetze die Domain erstes.netz vergeben, und auch im Beispiel für den Nameserver ( DNS ) werde ich das so machen.
Eine Domain kann sich theoretisch auch über 100 Subnetze erstrecken.
Willst Du eine eigene Domain für das zweite Netz anlegen, dann musst Du hier diese eintragen, und später im Nameserver dafür eine eigene Lookup Datei anlegen.
Pro: Man sieht am Namen in welchem Netz der Client ist.
Kontra: Man muss eine Datei mehr pflegen
Hier ist der Unterschied nur in den Beschreibungen wie folgt:
Für das erste Netz 10.0.0.0:
option domain-search „erstes.netz“, „zweites.netz“;
( wir wollen auch aus erstes.netz > zweites.netz via Namensauflösung erreichen, z.B. wenn wir aus unserem ersten Netz die Kamera im zweiten Netz über den Webbrowser mit http://XKamera.zweites.netz aufrufen wollen –
ohne diesen Eintrag würde der Browser diese Adresse im Internet suchen)
Für das zweite Netz 10.0.1.0:
option domain-name „zweites.netz“;
Möchten wir auch aus dem zweiten Netz lokale Adressen im Browser aufrufen können, muss der Eintrag domain-search auch hier mit den gewünschten Domainnamen stehen.
Damit ist der DHCP im Prinzip lauffähig, einzig die Frage; an welchen Schnittstellen vergibt er denn jetzt die IP-Adressen, ist noch nicht beantwortet.
gateway: ~ #l /etc/dhcp
zeigt uns keine überzeugenden Kandidaten für eine default Konfig. ach, ja
gateway: ~ #l /etc/default
das sieht gut aus
gateway: ~ #nano /etc/default/isc-dhcp-server
# Defaults for isc-dhcp-server (sourced by /etc/init.d/isc-dhcp-server) # Path to dhcpd's config file (default: /etc/dhcp/dhcpd.conf). #DHCPDv4_CONF=/etc/dhcp/dhcpd.conf #DHCPDv6_CONF=/etc/dhcp/dhcpd6.conf # Path to dhcpd's PID file (default: /var/run/dhcpd.pid). #DHCPDv4_PID=/var/run/dhcpd.pid #DHCPDv6_PID=/var/run/dhcpd6.pid # Additional options to start dhcpd with. # Don't use options -cf or -pf here; use DHCPD_CONF/ DHCPD_PID instead #OPTIONS="" # On what interfaces should the DHCP server (dhcpd) serve DHCP requests? # Separate multiple interfaces with spaces, e.g. "eth0 eth1". INTERFACESv4="eth1 eth2" # hier bedient er die Netze INTERFACESv6="" # hier mal garnix, da haben wir doch grade was gesehen...
Jetzt sollte das laufen:
gateway: ~ #systemctl restart isc-dhcp-server
Fehler?
Job for isc-dhcp-server.service failed because the control process exited with error code.
See „systemctl status isc-dhcp-server.service“ and „journalctl -xe“ for details.
gateway: ~ #journalctl -xe
Okt 24 14:24:19 gateway isc-dhcp-server[1975]: Starting ISC DHCPv4 server: dhcpddhcpd service already running (pid file /var/run/dhcpd.pid currenty exists
ok, der Crash nach der Installation hat Spuren hinterlassen, das ist neu, früher startete der Server sauber, vielleicht ein Bug? Könnte man im Netz forschen, zu sowas hat die Community meist ähnliche Erfahrungen. Der Hinweis ist aber auch ausreichend.
gateway: ~ #rm /run/dhcpd.pid
gateway: ~ #systemctl restart isc-dhcp-server
gateway: ~ #systemctl status isc-dhcp.server.service
● isc-dhcp-server.service – LSB: DHCP server
Loaded: loaded (/etc/init.d/isc-dhcp-server; generated)
Active: active (running) since Thu 2019-10-24 14:27:01 CEST; 14min ago Docs: man:systemd-sysv-generator(8)
Process: 2075 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 1140)
Memory: 5.2M
CGroup: /system.slice/isc-dhcp-server.service
└─2087 /usr/sbin/dhcpd -4 -q -cf /etc/dhcp/dhcpd.conf eth1 eth2
Okt 24 14:26:59 gateway systemd[1]: Starting LSB: DHCP server…
Okt 24 14:26:59 gateway isc-dhcp-server[2075]: /etc/init.d/isc-dhcp-server: 50: /etc/init.d/isc-dhcp-server: cannot open /etc/dhcp/dhcpd6.conf: No such
Okt 24 14:26:59 gateway isc-dhcp-server[2075]: Launching IPv4 server only.
Okt 24 14:26:59 gateway dhcpd[2087]: Wrote 0 leases to leases file.
Okt 24 14:26:59 gateway dhcpd[2087]: Server starting service.
Okt 24 14:27:01 gateway isc-dhcp-server[2075]: Starting ISC DHCPv4 server: dhcpd.
Okt 24 14:27:01 gateway systemd[1]: Started LSB: DHCP server
Das sieht gut aus, um das Kapitel abzuschliessen, ziehen wir mit Verwaltungsrechner und AccessPoints in die neuen Netze um.
So, das mit den AccessPoints hat geklappt? Der Verwaltungsrechner ist im Subnetz erstes.netz und hat die IP 10.0.0.2?
Was kann man jetzt machen wenn das nicht so geklappt hat?
Sind die AccessPoint eingerichtet? Heisst, beziehen sie ihre IP schon via DHCP, ist das Wlan konfiguriert? Eventuell muss das noch unter anderer Flagge ( IP-Adressraum ) gemacht werden.
Nehmen wir als Beispiel einen alten Plasterouter der noch rumlag. Der hat den WAN-Anschluss und 4 Ethernetanschlüsse.
Grundsätzlich bleibt der WAN Anschluß leer und der erste der 4 Ethernetanschlüsse kommt an den Switch.
Zum testen nehmen wir den Switch jetzt wieder weg und schliessen unseren Verwaltungsrechner direkt mit Kabel an. Bekommt der Verwaltungsrechner jetzt eine IP?( Nichts mit 169.irgendwas, 192.168.irgendwas…! )
Ja?
Das ist Schlecht!
Nein, Spaß – gut – dann logst Du Dich jetzt auf der Webseite des Plasterouters ein (http://IP-deiner-jetzigen-default-route), wahrscheinlich 192.168.0.1
Dort stellt sich jetzt die Frage, kann Dein Plasterouter überhaupt IP-Adressen empfangen? AccessPoints sind in der Regel darauf voreingestellt, aber Plasterouter sind für sowas nicht gemacht.
Du kannst ihn aber austricksen. Gib ihm die Adresse die ihm im DHCP zugedacht war, trage Dein Gateway ein und schalte die DHCP-funktion des Plasterouters ab.
Hier ein paar Screenshots:
Die „Interneteinstellung“ des WAN Ports, die vergebene 10.0.3.1 ist vollkommen egal, da sie nicht genutzt wird. Plasterouter meckert aber, wenn da nichts steht.
Die LAN Einstellung, eventuell nur über erweiterte Ansicht zu erreichen:
Und der DHCP des Plasterouter NICHT aktiv! Was dann da steht ist egal, kann alles stehen bleiben.
Alles gespeichert? Dann Plasterouter aus, ans Subnetz erstes.netz und anschalten.
Jetzt bekommt unser Verwaltungsrechner die gewünschte 10.0.0.2.
Damit sind wir jetzt hinter unserer Firewall und loggen uns ein mit:
ich@meinPC: ~ # ssh root@10.0.0.1
Authenzität wieder bestätigen
gateway: ~ #rules
und
#SSH(ACCEPT) net $FW
kommentieren, speichern und schliessen
gateway: ~ #shrs und gateway antwortet auf eth0 nicht mehr auf SSH Anfragen!
Damit sind im Prinzip beide Netze Betriebsbereit, es fehlt nur noch der DNS-Server um im Internet surfen zu können. Vorher möchte ich aber noch ein kleines Helferlein vorstellen:
next> swatch