In meinem Heimnetz hängen rund 80 Geräte, die ich über ihre Adresse anspreche: Steckdosen und Schalter, Kameras, Drucker, Messgeräte, PCs und Server. Lange hatte davon kaum eines eine feste Adresse. Die meisten bekamen sie zufällig aus dem Pool, und Home Assistant und das Monitoring speicherten, was gerade aktuell war. Bei einer Bestandsaufnahme zeigte sich, wie brüchig das ist: Viele gespeicherte Adressen gehörten inzwischen einem anderen Gerät. Ich habe deshalb ein IP-Konzept eingeführt, mit einem Adressblock je Geräteklasse und Reservierungen statt Pool.
Warum das nötig war
Vor dem Umbau habe ich alle Quellen nur lesend abgeglichen: die Leases beider DHCP-Server, die ARP-Tabelle der Firewall, die gespeicherten Adressen in Home Assistant, die Hosts im Monitoring und die DNS-Zonen. Das Ergebnis war ernüchternd.
- Eine Integration für Steckdosen speichert die Adresse fest und folgt Änderungen nicht. Von 30 Einträgen stimmten 16, einer war doppelt, 13 zeigten auf kein Gerät mehr.
- Mehrere Einträge in Home Assistant zeigten auf ein fremdes Gerät. Der Eintrag einer Lichterkette zeigte zum Beispiel auf einen Lüfter.
- Im Monitoring waren viele Hosts nach ihrer Adresse benannt. Nach einem Adresswechsel überwachten sie still ein anderes Gerät.
- Im DNS standen Altlasten, die auf Adressen zeigten, auf denen der genannte Dienst längst nicht mehr lief.
Vieles funktionierte also nur, weil die Adressen zufällig noch passten. Ein Stromausfall mit anschließender Neuvergabe hätte das Durcheinander sichtbar gemacht.
Ein Block je Geräteklasse
Die Grundidee: Jede Geräteklasse bekommt einen eigenen, leicht erkennbaren Adressbereich. Wer eine Adresse sieht, weiß sofort, was für ein Gerät dahinter steckt. So sieht mein Schema im letzten Oktett aus:
| Bereich | Geräteklasse |
|---|---|
| .1–.9 | Netzgeräte (Firewall, Switch, Access Point) |
| .10–.19 | Windows-Kern (Domänencontroller, Medienserver) |
| .20–.29 | DNS-Filter und interne Dienste |
| .30–.39 | Virtualisierung, Backup und Messgeräte |
| .40–.49 | Kameras und Photovoltaik |
| .50–.59 | Verwaltung und Server |
| .60–.69 | PCs und Windows-VMs |
| .70–.79 | Drucker (Tinte und 3D) |
| .80–.109 | Schaltaktoren (Shelly) |
| .110–.149 | Tuya-Steckdosen und ESP-Geräte mit Tuya-Firmware |
| .150–.159 | Bastelgeräte |
| .160–.179 | Haushaltsgeräte |
| .180–.190 | Sprachassistenten und Streaming-Sticks |
| .191–.194 | Quarantäne für nicht identifizierte Geräte |
| .195–.199 | Reserve und Zwischenparkplatz |
| .200–.254 | dynamischer Pool |
Die Blöcke sind unterschiedlich groß, und das ist Absicht. Für die Tuya-Steckdosen wollte ich zuerst nur 30 Adressen. Weil ich aber alle vorhandenen Einträge behalten wollte, auch die, deren Gerät gerade aus war, brauchte der Block 33 Plätze und reicht jetzt bis .149. Und Geräte mit einem Espressif-Chip habe ich nicht pauschal zu den Bastelgeräten gesteckt. Einige davon sind Steckdosen mit Tuya-Firmware, also gehören sie in den Tuya-Block. Erst die Frage „Wie spreche ich das Gerät an?“ entscheidet über den Block, nicht der Chip.
Zwei Blöcke verdienen eine Erklärung. Die Quarantäne ist für Geräte, die ich noch nicht zuordnen kann. Die Reserve dient beim Umzug als Parkplatz, falls zwei Geräte ihre Adressen tauschen müssen.
Reservierungen statt Pool
Die zweite Regel: Alles, was ich per Adresse anspreche, bekommt eine DHCP-Reservierung. Statische Adressen im Gerät selbst nutze ich nur noch, wo es nicht anders geht. Das betrifft bei mir vor allem zwei Zählerleser, deren Konfiguration auf einer SD-Karte steckt.
Der Bereich .1 bis .199 ist im DHCP-Server ausgeschlossen. Dort vergibt er nur Reservierungen, nie eine zufällige Adresse. Der Pool ab .200 hat 55 Adressen für Handys, Tablets und Gäste. Diese Geräte nutzen meist zufällige MAC-Adressen, eine Reservierung wäre bei ihnen ohnehin wertlos.
Bereich 192.0.2.1 – 192.0.2.254
Ausschluss 192.0.2.1 – 192.0.2.199 (nur Reservierungen)
Pool 192.0.2.200 – 192.0.2.254 (Handys, Tablets, Gäste)
Gateway 192.0.2.1
DNS die beiden Domänencontroller
Ein Gerät unter .200 ohne Reservierung fällt sofort auf. Genau das meldet mein täglicher Abgleich (mehr dazu unten).
Der Umzug ohne Ausfall
Mein erster Plan war vorsichtig: Gerät für Gerät in Wellen umziehen. Das Problem dabei war, dass fast alle Zieladressen von anderen Geräten belegt waren, die selbst umziehen sollten. Der Umzug war eine Permutation, die sich selbst blockiert. Ich hatte den Umzug schon in acht Wellen aufgeteilt. Eine davon war ein Zyklus, bei dem ein Gerät kurz auf dem Parkplatz stehen sollte.
Am Ende ging es einfacher, und die Reihenfolge war entscheidend:
- Sichern: DHCP-Export beider Server mit Leases, DNS-Zonen, Vollbackup von Home Assistant, Backup des Monitorings.
- Altlasten entfernen: veraltete DNS-Einträge auf Zieladressen löschen, bevor diese Adressen vergeben werden.
- Ausschluss erweitern auf .1 bis .199. Ab jetzt kann der Pool keine Zieladresse mehr vergeben.
- Alte Leases in den Zielbereichen löschen und alle Reservierungen auf einmal anlegen, auf beiden DHCP-Servern: 67 neue, insgesamt 75.
- Geräte neu verbinden lassen. Weil alle Reservierungen vorher standen, zogen die Geräte beim nächsten Neustart oder bei der nächsten Erneuerung von selbst um.
Die Regel dahinter: Löschst du ein Lease, darf die Adresse nicht frei im Pool liegen. Sonst kann ein Handy genau die frei gewordene Adresse bekommen. Im Wellenplan hieß das „erst reservieren, dann das Lease löschen“. Beim Umbau auf einen Schlag hat der erweiterte Ausschluss diese Aufgabe übernommen.
Rund 15 Minuten nach einem Stromzyklus im Haus waren 32 von 67 Geräten auf ihrer Zieladresse. Zehn waren noch auf der alten, weil sie nicht neu gestartet waren. 25 schliefen oder waren aus, für sie stand die Reservierung bereit. Es gab keine Doppelbelegung. Gateway, DNS, Proxmox, Backup-Server und Home Assistant habe ich direkt nach der Umstellung geprüft, sie antworteten alle. Der Rückweg für jedes einzelne Gerät war einfach: Reservierung löschen, Gerät erneuern, und es landet wieder im Pool.
Nicht alles lief glatt. Für vier Steckdosen fand ich kein Lease. Sie behalten ihre Adresse oder haben sie fest eingetragen, solche Geräte muss ich gezielt neu verbinden. Windows-PCs verschwanden kurz aus dem DNS, weil ihre alten Leases gelöscht wurden. Ein Neustart oder ipconfig /renew mit /registerdns trägt sie wieder ein. Für einige Geräte, die gerade aus waren, kannte ich die MAC nicht. Ihr Platz ist im Plan reserviert, die Reservierung folgt, sobald sie wieder im Netz sind. Bis dahin sind diese Plätze nur auf dem Papier geschützt.
Zwei DHCP-Server, doppelte Arbeit
DHCP machen bei mir die beiden Windows-Domänencontroller im Failover mit Lastverteilung 50 zu 50 und vier Tagen Lease-Dauer. Fällt einer aus, vergibt der andere weiter. Soweit die Theorie.
In der Praxis hat mich die Replikation überrascht. Der Befehl, der Reservierungen vom einen auf den anderen Server überträgt, scheitert aus einer Remote-Sitzung (Double-Hop) und auch als SYSTEM mit „Zugriff verweigert“. Vorher war schon einmal eine Reservierung nur auf einem Server angekommen. Ich lege Reservierungen deshalb mit einem wiederholbaren Skript auf beiden Servern einzeln an und vergleiche danach.
# je Server, danach Ergebnisse vergleichen
Get-DhcpServerv4Reservation -ScopeId 192.0.2.0 |
Sort-Object IPAddress |
Select-Object IPAddress, ClientId, NameDamit sich keine Abweichung einschleicht, läuft ein täglicher Abgleich. Er meldet Unterschiede zwischen den Servern, Leases im Reservierungsbereich ohne Reservierung und Adressen mit dem Status BAD_ADDRESS. Beim Abschluss des Umbaus hatten beide Server 88 identische Reservierungen, für jede stimmten Adresse und MAC überein.
Feste Adressen in Anwendungen
Home Assistant musste ich bei 26 Einträgen anpassen. Shelly-Geräte findet es über Zeroconf meist selbst wieder, die Tuya-Integration nicht. Der MQTT-Broker steckt in Home Assistant, und mehrere Geräte sprechen ihn per Adresse an. Diese Adresse ist im Konzept tabu.
Ein Access Point mit eigenem DHCP-Server würde WLAN-Clients an allen Reservierungen vorbei versorgen. Mein zweiter Router soll deshalb als reiner IP-Client laufen. In seiner Oberfläche habe ich das noch nicht nachgesehen.
Offen sind außerdem einige Geräte auf alten Adressen, die fehlenden MAC-Adressen und das Monitoring: Die Hosts dort sollen nach und nach Namen statt Adressen bekommen.
Schreibe einen Kommentar