DHCP-Supernet
Kann ein DHCP-Server IP-Adressen aus einem IP-Adressbereich vergeben, aus welchem der Server selbst keine IP-Adresse besitzt? Muss bei einer Supernet-Konfiguration eine IP-Adresse des Servers innerhalb des im DHCP konfigurierten Bereichs liegen?
Ja, ein DHCP-Server kann IP-Adressen aus für ihn fremden IP-Adressbereichen vergeben, wenn er passend konfiguriert wird und dabei muss der Server selbst keine IP-Adresse aus dem entsprechenden IP-Netz besitzen. Eine solche DHCP-Konfiguration bezeichnet man als "Supernet" oder "Supernetz" und sollte mit jedem halbwegs gängigen DHCP-Server unter Linux möglich sein. Dies ist auf jeden Fall mit dem ISC DHCP und dnsmasq möglich. Nachfolgend werde ich allerdings nur auf den ISC DHCP, welcher auch als "dhcpd" bekannt ist, eingehen, da dies der mit den meisten Linux-Distributionen standardmäßig ausgelieferte DHCP-Server ist.
Ein Beispiel für eine mögliche Konfiguration des DHCP-Servers, bei dem IP-Adressen aus dem Bereich 172.16.29.2 bis 172.16.29.254 (das Netz selbst ist 172.16.29.0/24, also die Subnetmaske 255.255.255.0) vergeben werden sollen, aber auf dem Server ist jedoch lediglich die IP-Adresse 192.168.0.1 aus dem Netz 192.168.0.0/24 konfiguriert ist, findet sich in der nachfolgenden Konfigurationsdatei "/etc/dhcpd.conf":
ddns-update-style interim;
ignore client-updates;
shared-network intranet {
subnet 192.168.0.1 netmask 255.255.255.255 {
}
subnet 172.16.29.0 netmask 255.255.255.0 {
range 172.16.29.2 172.16.29.254;
option routers 172.16.29.1;
}
}
Die entscheidende Option, die hier zum Einsatz kommt, ist "shared-network", welche dem DHCP-Server mitteilt, dass sich mehrere IP-Subnetze das gleiche physikalische Netzwerk teilen; mehr dazu findet sich in der Dokumentation des ISC DHCP. Der Trick an der Sache ist zudem, dass es eine Subnet-Deklaration für die auf dem Server konfigurierte IP-Adresse (und nur für diese IP-Adresse) gibt. Eine Definition, die zumindest die IP-Adresse des Servers beinhaltet, muss zwingend konfiguriert werden, sonst startet der DHCP-Server nämlich nicht. Natürlich kann auch ein normaler IP-Bereich für das Netz 192.168.0.0/24 konfiguriert werden, wenn dies erforderlich bzw. gewünscht ist. Im obigen Beispiel sollen jedoch nur Adressen für das Netz 172.16.29.0/24 vergeben werden.
Normalerweise ist bei einer solchen Konfiguration ein DHCP-Relay bzw. -Proxy vorhanden, der die DHCP-Anfragen in Form von Broadcasts im Netz 172.16.29.0/24 annimmt und gezielt an einen DHCP-Server, hier die 192.168.0.1, weiterleitet. Das DHCP-Relay bzw. der DHCP-Proxy agiert daher zwischen den beiden IP-Netzen und hat in jedem der beiden Netze mindestens eine IP-Adresse. Für die Seite des Relays, die sich im gleichen Netz wie der DHCP-Server befindet, nehme ich in diesem Beispiel die IP-Adresse 192.168.0.24 an. Und damit die Antworten des DHCP-Servers wieder in das richtige Subnetz finden, muss nun noch eine passende Route auf dem Server gesetzt werden:
tux:~ # route add -net 172.16.29.0/24 gw 192.168.0.24 tux:~ #
Idealerweise fixiert man diese Route in der Netzwerk-Konfiguration, diese kann sich jedoch je nach Linux-Distribution an einer anderen Stelle befinden.
In seltenen Fällen kann es notwendig sein, eine solche Supernet-Konfiguration auch bei "aliased devices", also z.B. wenn eth0:1 vorhanden ist, zu verwenden, wenn sich der DHCP-Server völlig quer stellt und beispielsweise auf dem Interface eth0 das Netz 192.168.1.0/24 liegt und man auf dem Interface eth0:1 das Netz 192.168.2.0/24 konfiguriert hat, man aber mit dem DHCP-Server nur das zweite der beiden IP-Netze ansprechen möchte.
Grundsätzlich sollte man allerdings bei einer Supernet-Konfiguration im DHCP-Server die vorhandene Netzwerk-Konfiguration in Frage stellen und prüfen, ob man den DHCP-Server nicht an einer anderen Stelle plazieren bzw. ob nicht ein eventuell vorhandenes DHCP-Relay bzw. ein DHCP-Proxy durch einen vollwertigen DHCP-Server ersetzt werden kann.