IP-Adressplan fürs Homelab: Subnetze sinnvoll planen

Ein Adressplan ist das Unauffälligste an einem Homelab und das Teuerste, wenn er fehlt. Ein falsch gewählter Bereich fällt erst auf, wenn das VPN aus dem Urlaub nicht funktioniert oder ein neuer Container das halbe Netz nicht mehr erreicht. Dann heißt die Lösung Umnummerieren – jedes Gerät, jede Firewall-Regel, jeder DNS-Eintrag, jede Konfigurationsdatei.

Dieser Artikel ist die Planung davor: welcher private Bereich, wie groß die Segmente, wie die Adressen innerhalb eines Segments verteilt werden und welche Kollisionen man von Anfang an vermeidet. Die Segmente selbst – welche es gibt und was zwischen ihnen erlaubt ist – behandelt der Partnerartikel VLANs im Homelab.

Die kurze Antwort

• Bereich: ein eigener Block aus 10.0.0.0/8, zum Beispiel 10.20.0.0/16. Nicht 192.168.0.0/24 oder 192.168.1.0/24, nicht 10.0.0.0/24.
• Segmente: ein /24 je VLAN, das dritte Oktett ist die VLAN-Nummer. VLAN 30 wird 10.20.30.0/24.
• Innerhalb jedes Segments dieselbe Einteilung: .1 ist das Gateway, feste Adressen unten, der DHCP-Bereich oben.
• Infrastruktur fest, Dienste reserviert, Clients dynamisch.
• Namen statt Adressen: eine interne Domain unter home.arpa oder unter der eigenen Domain.

Schritt 1: den Bereich wählen

Für private Netze sind drei Bereiche reserviert. Welcher davon was umfasst, steht im Subnetz-Rechner. Für die Wahl zählt etwas anderes: Welche Bereiche sind schon belegt – nicht im eigenen Netz, sondern in den Netzen, mit denen das eigene irgendwann verbunden wird?

Wer	Belegt ab Werk	Wann es kollidiert
Heimrouter allgemein	192.168.0.0/24, 192.168.1.0/24	VPN aus fast jedem fremden Heimnetz
FRITZ!Box	192.168.178.0/24	VPN aus jedem Haushalt mit FRITZ!Box
Manche Provider-Router	Bereiche aus 10.0.0.0/24	VPN aus dem Netz der Eltern, der Nachbarn, des Büros
Docker	172.17.0.0/16 bis 172.31.0.0/16, danach 192.168.0.0/16	Netze in diesen Bereichen, die der Docker-Host über ein Gateway erreichen soll
k3s (Kubernetes)	10.42.0.0/16 für Pods, 10.43.0.0/16 für Dienste	eigene Netze in diesen Bereichen
Tailscale, CGNAT	100.64.0.0/10	eigene Netze in diesem Bereich – der aber ohnehin nicht privat ist

Die Kollision entsteht, sobald ein Gerät zwei Netze mit demselben Bereich gleichzeitig sieht. Der Laptop im Hotel-WLAN 192.168.1.0/24 baut ein VPN nach Hause auf, zu Hause ist es ebenfalls 192.168.1.0/24 – und für den Laptop liegt der Heimserver dann im Hotel. Kein Fehler, keine Meldung, die Verbindung kommt einfach nicht an.

Daraus folgt die Wahl: ein Block aus 10.0.0.0/8, der weder am Anfang noch am Ende liegt. 10.20.0.0/16 ist ein Beispiel, 10.47.0.0/16 genauso gut. Die zweite Zahl wird zur Standortnummer. Kommt später ein zweiter Standort dazu – das Netz der Eltern, ein kleines Büro –, bekommt er 10.21.0.0/16, und beide lassen sich per VPN verbinden, ohne dass irgendwo umnummeriert wird.

Docker: die Container-Netze in den Plan holen

Docker legt für jedes Compose-Projekt ein eigenes Netz an und nimmt es ab Werk aus 172.17.0.0/16 bis 172.31.0.0/16, danach aus 192.168.0.0/16. Auf dem Host selbst fällt das meist nicht auf. Es fällt auf, sobald der Host ein Netz erreichen soll, das nur über ein Gateway erreichbar ist und zufällig im selben Bereich liegt – ein Firmennetz über VPN, ein zweiter Standort, ein Netz hinter einem anderen Router. Dann gewinnt die direkte Route ins Container-Netz, und das entfernte Netz ist vom Host aus nicht mehr erreichbar.

Abhilfe: Docker einen eigenen Block aus dem Plan zuweisen, in /etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "10.20.240.0/20", "size": 26 }
  ]
}

Das ergibt 64 Container-Netze mit je 62 Adressen, alle im Block 240 bis 255, der dafür reserviert bleibt. Weil Docker diese Netze hinter der Adresse des Hosts verbirgt und sie den Host nie verlassen, darf jeder Docker-Host denselben Block verwenden. Die Einstellung greift nach einem Neustart des Docker-Dienstes und nur für neu angelegte Netze – bestehende Compose-Projekte einmal mit docker compose down und up neu erstellen. Das Standardnetz docker0, das nur Container ohne eigenes Netz verwenden, wird gesondert über die Einstellung bip festgelegt.

Schritt 2: die Größe je Segment

Ein /16 enthält 256 Netze der Größe /24. Adressknappheit gibt es in diesem Plan nicht, und deshalb lautet die Empfehlung: ein /24 je Segment, drittes Oktett gleich VLAN-Nummer.

VLAN	Segment	Netz	Gateway
10	Verwaltung	10.20.10.0/24	10.20.10.1
20	Dienste	10.20.20.0/24	10.20.20.1
30	Clients	10.20.30.0/24	10.20.30.1
40	IoT	10.20.40.0/24	10.20.40.1
50	Gäste	10.20.50.0/24	10.20.50.1
60	Backup	10.20.60.0/24	10.20.60.1
70	Von außen erreichbar	10.20.70.0/24	10.20.70.1

Der Wert liegt in der Lesbarkeit: Aus jeder Adresse ist ablesbar, in welchem Segment sie liegt, und aus jedem Segment, welche Adressen hineingehören. Im Störungsfall um zwei Uhr nachts ist das mehr wert als die gesparten Adressen.

Daraus folgt eine Nebenregel: VLAN-Nummern bleiben unter 240. Über 255 passen sie nicht mehr ins Oktett, und der Block 240 bis 255 ist für die Container-Netze reserviert (siehe oben). Bei einem Homelab ist das keine Einschränkung.

Drei Ausnahmen, bei denen ein kleineres Netz richtig ist:

• Testsegment für Wiederherstellungen: ein /29 ohne Verbindung nach außen. Eine zurückgespielte VM startet mit ihrer alten Adresse, und im Produktivnetz stünde sie dann neben dem Original. Das Verfahren steht in Restore testen.
• Transfernetze zwischen zwei Routern: ein /31 – zwei Adressen, beide nutzbar.
• Das VPN-Segment: ein eigenes Netz für die Tunnel-Adressen. Klein genug geplant, aber mit festem Platz im Schema – etwa 10.20.99.0/24.

Wer lieber mit kleineren Segmenten plant, zerlegt ein /24 im Subnetz-Rechner in gleich große Teilnetze. Die Tabelle dort zeigt die Grenzen, die man von Hand am leichtesten falsch rechnet.

Schritt 3: die Einteilung innerhalb eines Segments

Der eigentliche Nutzen eines Plans entsteht erst hier: in jedem Segment dieselbe Aufteilung. Wer weiß, dass .1 immer das Gateway und .10 bis .49 immer feste Adressen sind, muss für kein Segment nachschlagen.

Bereich	Verwendung
.1	Gateway – die Adresse des Routers in diesem Segment
.2 – .9	Netzinfrastruktur: Switches, Access-Points, zweiter Router
.10 – .49	feste Adressen: Hypervisor, DNS, Backup-Server, zentrale Dienste
.50 – .99	DHCP-Reservierungen: Geräte, die immer dieselbe Adresse bekommen sollen
.100 – .249	DHCP-Bereich für alles Dynamische
.250 – .254	Reserve für Provisorien und Fehlersuche

Die Grenzen sind eine Konvention, keine Technik. Wichtig ist nur, dass sie in allen Segmenten gleich sind und dass der DHCP-Bereich nie in den festen Bereich hineinreicht – sonst vergibt der Server eine Adresse, die ein fest eingestelltes Gerät schon benutzt, und beide sind abwechselnd erreichbar.

Schritt 4: fest, reserviert oder dynamisch

Die Frage ist nicht, welches Gerät wichtig ist, sondern was ohne DHCP noch funktionieren muss.

Fest eingetragen: alles, was läuft, bevor der DHCP-Server läuft, oder was selbst DHCP-Server ist. Router, Switches, der Hypervisor, der DNS-Server, der Backup-Server. Fällt der DHCP-Dienst aus, bleiben diese Geräte erreichbar – und damit die Werkzeuge, mit denen man den Ausfall behebt.

Vor dem Eintragen einer festen Adresse prüfen, ob sie wirklich frei ist – von einem Gerät im selben Segment:

# Keine Antwort heißt frei; der Befehl endet dann mit Status 0
arping -D -c 3 -I eth0 10.20.10.12

Ein Gerät, das seit Monaten ausgeschaltet im Schrank liegt, taucht in keiner Liste auf – bis es wieder eingeschaltet wird und dieselbe Adresse beansprucht. Deshalb gehört jede feste Adresse in die Dokumentation, auch die der selten benutzten Geräte.

Für den Proxmox-Host gilt das doppelt. Die Adresse steht in seiner Netzwerkkonfiguration und in /etc/hosts, und in einem Cluster zusätzlich in der Konfiguration von Corosync. Eine spätere Änderung ist möglich, aber eine Operation am offenen Herzen – Proxmox-Cluster ohne Shared Storage zeigt, wie viel an diesen Adressen hängt. Deshalb: vor der Installation festlegen.

Reserviert: Dienste in VMs und Containern, Drucker, Geräte mit Freigaben. Sie bekommen ihre Adresse per DHCP, aber immer dieselbe, gebunden an die MAC-Adresse. Der Vorteil gegenüber fester Konfiguration: Die Adresse wird an einer Stelle gepflegt, am DHCP-Server, und nicht verstreut in jeder VM.

Dynamisch: Laptops, Smartphones, Gäste, alles, worauf niemand von außen zugreift.

Zwei Proxmox-Fallen

Geklonte VMs bekommen dieselbe Adresse. Linux-Systeme mit systemd-networkd melden sich beim DHCP-Server mit einer Kennung, die aus /etc/machine-id abgeleitet ist. Klone einer Vorlage haben dieselbe Datei – und der DHCP-Server hält sie für ein und dasselbe Gerät. Ergebnis: zwei VMs, eine Adresse, abwechselnd erreichbar. Abhilfe: in der Vorlage vor dem Umwandeln die Datei leeren, nicht löschen. Beim ersten Start jedes Klons wird dann eine neue Kennung erzeugt.

# In der VM, unmittelbar vor dem Umwandeln in eine Vorlage
truncate -s 0 /etc/machine-id

Eine zurückgespielte VM kommt mit der Adresse des Originals. Die Wiederherstellung übernimmt die MAC-Adresse, und eine DHCP-Reservierung vergibt dann dieselbe Adresse wie an das noch laufende Original. Im Wiederherstellungsdialog von Proxmox gibt es dafür die Option Unique, die neue MAC-Adressen erzeugt. Für einen Restore-Test gehört sie eingeschaltet – oder die VM gleich ins isolierte Testsegment, wie in Restore testen beschrieben.

Schritt 5: Namen statt Adressen

Der beste Adressplan ist einer, den man im Alltag kaum braucht, weil alles über Namen läuft. Dafür braucht es eine interne Domain – und dort liegt der häufigste Fehler.

• Nicht .local. Diese Endung ist für Multicast-DNS reserviert. Geräte, die sie über normales DNS auflösen sollen, verhalten sich je nach Betriebssystem unterschiedlich und schwer nachvollziehbar.
• Keine erfundene Endung wie .lan oder .home. Sie funktionieren, bis jemand genau diese Endung als öffentliche Domain vergibt.
• home.arpa ist nach RFC 8375 genau für Heimnetze reserviert: pve1.home.arpa, backup.home.arpa.
• Oder eine Subdomain der eigenen Domain, etwa lab.beispiel.at. Der Vorteil: Für diese Namen lassen sich gültige Zertifikate ausstellen, ohne dass die Dienste aus dem Internet erreichbar sein müssen. Wer später interne Dienste mit HTTPS betreiben will, wählt diesen Weg. Die internen Namen stehen dann nur im internen DNS und werden nicht veröffentlicht – das nennt sich Split-DNS.

Die Pflege der Namen lässt sich großteils abgeben: Die DNS-Dienste der gängigen Router und Firewalls tragen Namen aus DHCP-Vergaben und -Reservierungen selbst ein. Bei dnsmasq ist das Standard, bei Unbound auf OPNsense eine Einstellung. Von Hand gepflegt werden dann nur noch die fest eingetragenen Geräte.

Schritt 6: dokumentieren – und zwar außerhalb des Labors

Eine Tabelle genügt. Als Vorlage zum Kopieren, mit Semikolon getrennt, damit sie sich in einer deutschsprachigen Tabellenkalkulation direkt richtig öffnet:

Adresse;Name;Segment;Art;Gerät/VM;MAC;Zweck
10.20.10.1;fw;10 Verwaltung;fest;Firewall;;Gateway
10.20.10.11;pve1;10 Verwaltung;fest;Proxmox-Host;;Hypervisor
10.20.20.15;cloud;20 Dienste;reserviert;VM 105;bc:24:11:xx:xx:xx;Dateiablage
10.20.60.10;pbs;60 Backup;fest;Backup-Server;;Proxmox Backup Server

Die MAC-Spalte braucht nur, wer Reservierungen verwendet – dort ist sie der Schlüssel. Ab einigen Dutzend Einträgen lohnt ein eigenes Werkzeug zur Adressverwaltung wie NetBox oder phpIPAM – für die meisten Homelabs ist es zu viel.

Wichtiger als das Format ist der Ort. Die Dokumentation muss erreichbar sein, wenn das Labor nicht läuft. Eine Adressliste, die nur in einer VM auf dem Hypervisor liegt, fehlt genau dann, wenn der Hypervisor nicht startet. Eine Kopie gehört dorthin, wo auch die Wiederherstellungsanleitung liegt – das Prinzip dahinter steht in der 3-2-1-Backup-Strategie. Und ganz altmodisch: ein Ausdruck neben dem Router. Er ist das Einzige, was auch ohne Strom und ohne Netz lesbar bleibt.

Und IPv6?

Die Planung sieht dort anders aus, der Grundgedanke bleibt. Für interne Adressen gibt es Unique Local Addresses nach RFC 4193: fd plus eine zufällige 40-Bit-Kennung ergibt ein eigenes /48, darin ist Platz für 65.536 Segmente der Größe /64. Die VLAN-Nummer passt als Segmentkennung hinein – VLAN 30 wird fdxx:xxxx:xxxx:30::/64. Die Zufallskennung ist dabei kein Detail: Sie ist das, was die Kollision zweier Standorte verhindert, die bei IPv4 durch geschickte Wahl vermieden werden muss.

Daneben vergibt der Provider ein öffentliches Präfix, und das ändert sich bei vielen Anschlüssen von Zeit zu Zeit. Für alles, was fest sein muss – DNS-Einträge, Firewall-Regeln, Dokumentation –, taugt es deshalb nicht; dafür sind die ULA da. Das Provider-Präfix dient nur dem Weg ins Internet. Und weil Geräte mit öffentlicher IPv6-Adresse grundsätzlich von außen adressierbar sind, muss die Firewall eingehende Verbindungen dort ausdrücklich sperren – bei IPv4 erledigte das die Adressumsetzung nebenbei.

Häufige Fragen

Warum nicht einfach 192.168.1.0/24? Weil unzählige Heimrouter denselben Bereich verwenden. Solange das eigene Netz nie per VPN aus einem fremden Netz erreicht werden soll, stört das nicht – sobald doch, kollidieren die Bereiche, und der Tunnel führt ins Leere.

Reicht ein einziges /24 für das ganze Homelab? Für den Anfang ja. Ein Adressplan mit 10.20.0.0/16 und einem /24 je Segment lässt sich aber schon mit einem einzigen Segment anlegen – 10.20.30.0/24 –, und die späteren VLANs bekommen ihren Platz, ohne dass das erste umnummeriert wird.

Muss der Proxmox-Host eine feste Adresse haben? Ja. Die Adresse steht in mehreren Konfigurationsdateien und in einem Cluster in der Corosync-Konfiguration. Eine DHCP-Adresse, die sich ändert, macht den Host unerreichbar oder den Cluster funktionsunfähig.

Welche interne Domain soll ich verwenden? home.arpa oder eine Subdomain der eigenen Domain. Nicht .local, weil diese Endung für Multicast-DNS reserviert ist, und keine erfundene Endung.

Wie viele Adressen soll der DHCP-Bereich haben? So viele, dass alle dynamischen Geräte gleichzeitig Platz haben, mit Reserve für Gäste. Bei einem /24 mit dem Bereich .100 bis .249 sind das 150 – für jedes Heimnetz mehr als genug.

Weiter

• VLANs im Homelab – welche Segmente und welche Regeln zwischen ihnen
• Subnetz-Rechner – Netzgrenzen prüfen und ein Netz in Teilnetze zerlegen
• Proxmox VE im Homelab – wo die feste Adresse des Hosts bei der Installation festgelegt wird
• Restore testen – warum das Testsegment zum Plan gehört