Manchmal muss es einfach von hinten durch die Brust ins Auge gehen. Folgender Anwendungsfall:
Man nehme einen Debian Etch-basierenden LAMPP-Server, der für diese Funktion seit geraumer Zeit eine statische IP besitzt, die allen relevanten Clients mit Hilfe eines Eintrages in der /etc/hosts bzw. C:\winnt\system32\drivers\etc\hosts bekannt ist. Alles easy, alles Roger.
Bis – ja, bis mit unterschiedlichen Routern experimentiert wird, die mit wechselnder DHCP-Verantwortlichkeit mal einzeln, mitunter aber auch beide gleichzeitig im LAN hängen … dann natürlich zwingend mit unterschiedlichen IPs. Das verursacht keinem der DHCP-basierenden Clients jedweder Betriebssystem-Schubladen auch nur eine Spur von Ungemach: Neu booten oder auch nur die DHCP-Lease erneuern – und schon sind die Einträge für Standard-Gateway und DNS-Proxy korrekt.
Lediglich der Etch-LAMPP ist unzufrieden. Schließlich ist sein bisheriges Standard-Gateway und DNS-Proxy nach dem Routerwechsel nicht mehr erreichbar, oder zumindest unkooperativ – und das knarzt im Getriebe.
Eine pure DHCP-Konfiguration ist schnell gemacht: http://wiki.debian.org/NetworkConfiguration erklärt, dass man dazu in /etc/network/interfaces lediglich folgendes eintragen muss:
auto eth0
iface eth0 inet dhcp
Funktioniert auch prima – außer, dass die im LAN bekannte statische IP des LAMPPs nicht mehr funktioniert … Klar, der DHCP-Server hat der Kiste ja eine IP aus dem Pool der dynamische verteilten IPs zugeteilt, und die alte, bewährte IP ist nun stumm.
Also zurück zur statischen IP – nicht schwierig, stattdessen einfach folgendes schreiben:
iface eth0 inet static
address 192.168.42.2
netmask 255.255.255.0
gateway 192.168.42.254
dns-nameservers 192.168.42.254
Der aufmerksame Leser erkent, dass 192.168.42.254 den Router und DNS-Proxy bildet. Dessen IP statisch einzutragen wollten wir doch aber eigentlich ausdrücklich vermeiden, weil doch mal der .254, mal der .253 läuft, je nach Tageslaune bzw. Experimentiergeist des Hobby-Admins. *kopfkratz*
Gesucht ist also eine halbdynamische Konfiguration, bei der der LAMPP eigenverantwortlich eine feste IP verwendet, unter der er auch zu erreichen ist, er aber trotzdem irgendwie per DHCP das Standardgateway ermittelt. Wie geht das denn nur?
Des Rätsels Lösung: Wir verpassen dem Netzwerkinterface einen Alias – anders gesagt: eine gespaltene Persönlichkeit. Zusätzlich zum regulären eth0, das sich beim DHCP-Server mit einer dynamischen IP und anderen relevanten Details des LANs versorgen darf, bekommt es nun den Alias eth0:1 verpasst – und dieser bekommt die altbekannte statische IP zugewiesen. In der /etc/network/interfaces liest sich das so:
auto eth0
iface eth0 inet dhcp
auto eth0:1
iface eth0:1 inet static
address 192.168.42.2
netmask 255.255.255.0
Kommentiert: Der erste Block definiert wie gehabt die vollautomatische Konfiguration von eth0 via DHCP. Der zweite Block erstellt und konfiguriert dem Interface den Alias eth0:1 und weist ihm statisch eine zweite IP zu. Das Eintragen statischer IPs hinsichtlich Gateway und DNS-Proxy ist somit vollkommen unnötig.
Nach dem Reboot liefert ifconfig dann erfreulicherweise folgendes (gekürzt):
eth0 Protokoll:Ethernet Hardware Adresse 00:0C:29:54:43:A3
inet Adresse:192.168.42.22 Bcast:192.168.42.255 Maske:255.255.255.0
...
eth0:1 Protokoll:Ethernet Hardware Adresse 00:0C:29:54:43:A3
inet Adresse:192.168.42.2 Bcast:192.168.42.255 Maske:255.255.255.0
Quod erat demonstrandum: Dieselbe MAC-Adresse – die .22 kommt dynamisch vom DHCP-Server, die .2 aus der statischen Konfiguration. Und das Wichtigste: Der Webserver reagiert wieder brav unter Angabe der .2 bzw. unter dem per Hosttabelle(n) bekannten Hostnamen.
… Ich gehe davon aus, dass das mit Lenny auch funktionieren dürfte. Praxistauglich getestet ist o.a. Konfiguration allerdings mit Etch.
Keine Kommentare möglich.