Ein sauber geplanter IP-Bereich entscheidet im Hosting und in DevOps oft darüber, ob Netzwerke übersichtlich bleiben oder später teuer umgebaut werden müssen. Ich zeige, wie zusammenhängende Adressblöcke mit CIDR funktionieren, wie viele Geräte in ein Präfix passen und worauf es bei VPCs, Kubernetes, Firewalls und VPNs wirklich ankommt.
Die wichtigsten Regeln für die Planung von IP-Bereichen
- CIDR beschreibt einen zusammenhängenden Block mit Präfixlänge, zum Beispiel 10.20.0.0/16.
- Ein IPv4-Netz mit /24 umfasst 256 Adressen, davon sind klassisch meist 254 für Hosts nutzbar.
- Private Netze nutzen vor allem 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16.
- Überlappende Netze behindern Peering, VPNs und Routing und sollten von Anfang an vermieden werden.
- Für Firewalls gilt /32 als einzelne IPv4-Adresse, während größere Präfixe ganze Gruppen erlauben.
Was ein IP-Bereich technisch bedeutet
Eine IP-Range ist ein zusammenhängender Block von IP-Adressen. Statt jede Adresse einzeln zu verwalten, fasst man sie unter einem Netzwerkpräfix zusammen. Das spart Konfigurationsaufwand und erlaubt Routern, Firewalls und Cloud-Plattformen, Regeln für viele Adressen gleichzeitig anzuwenden.
In der Praxis wird ein IPv4-Block meist in CIDR-Schreibweise angegeben. Die Zahl hinter dem Schrägstrich zeigt, wie viele der 32 Bits zum Netz gehören. Bei 10.20.0.0/16 sind also 16 Bits festgelegt, während 16 Bits für Adressen innerhalb dieses Netzes bleiben.
| Präfix | Adressen insgesamt | Klassisch nutzbare Hosts | Typischer Einsatz |
|---|---|---|---|
| /30 | 4 | 2 | Punkt-zu-Punkt-Verbindung |
| /28 | 16 | 14 | Kleine Servergruppe |
| /24 | 256 | 254 | Überschaubares Subnetz |
| /16 | 65.536 | 65.534 | Großes internes Cloud-Netz |
Die klassische Hostzahl ergibt sich aus 2 hoch der Anzahl der Host-Bits, abzüglich Netzwerk- und Broadcast-Adresse. Diese Faustregel gilt nicht in jeder Umgebung. Cloud-Anbieter reservieren häufig zusätzliche Adressen, und bei einer Punkt-zu-Punkt-Verbindung kann ein /31 mit zwei nutzbaren Adressen sinnvoll sein.
So liest und berechnet man CIDR-Blöcke
Für die tägliche Arbeit reicht eine kleine Tabelle oft aus. Je kleiner die Zahl hinter dem Schrägstrich ist, desto größer ist der Block. Ein /20 enthält deutlich mehr Adressen als ein /24, weil mehr Bits für Hosts verfügbar bleiben.
Ein praktisches Beispiel mit /24
Der Block 192.168.50.0/24 reicht von 192.168.50.0 bis 192.168.50.255. Die erste Adresse identifiziert das Netz, die letzte dient im klassischen IPv4-Netz als Broadcast-Adresse. Für Geräte bleiben normalerweise 192.168.50.1 bis 192.168.50.254.
Wenn ich dieses Netz in vier gleich große Teilnetze aufteile, wird aus /24 jeweils ein /26. Jeder Teilblock umfasst 64 Adressen. Die Netze beginnen bei .0, .64, .128 und .192. Diese einfache Struktur ist hilfreich, wenn etwa Entwicklung, Test, Produktion und Administration voneinander getrennt werden sollen.
Netzadresse und Broadcast-Adresse prüfen
Ein häufiger Fehler besteht darin, eine beliebige Adresse als Netzwerkadresse zu verwenden. Bei 192.168.50.70/26 lautet die tatsächliche Netzadresse 192.168.50.64/26, weil ein /26 in Blöcken von 64 Adressen arbeitet. Der Bereich endet bei 192.168.50.127.
Für die Kontrolle nutze ich im Alltag einen CIDR-Rechner oder Befehle wie ipcalc. Das ist keine Schwäche, sondern gute Praxis. Entscheidend ist, das Ergebnis anschließend zu verstehen und nicht blind in eine Terraform-, Kubernetes- oder Firewall-Konfiguration zu kopieren.
Welche Rolle IP-Bereiche im Hosting spielen
Beim klassischen Hosting wird eine öffentliche IPv4-Adresse oft einem Server, Load-Balancer oder Mail-System zugeordnet. Ein kompletter öffentlicher Block kann sinnvoll sein, wenn viele Dienste getrennte Adressen benötigen. Für gewöhnliche Websites reicht jedoch meist eine einzelne Adresse hinter einem Reverse Proxy oder einer Load-Balancer-Schicht.
Private Adressen sind im internen Netzwerk die bessere Wahl. Dafür stehen die Bereiche 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16 zur Verfügung. Sie sind nicht direkt über das öffentliche Internet erreichbar und werden über NAT, einen Proxy oder ein Gateway nach außen übersetzt.
| Bereich | Geeignet für | Wichtige Einschränkung |
|---|---|---|
| Private IPv4-Ranges | Server, Datenbanken, interne APIs, Container | Nicht direkt öffentlich routbar |
| Öffentliche IPv4-Ranges | Webserver, Mailserver, öffentliche Gateways | Benötigen Schutz durch Firewall und Monitoring |
| IPv6 /64 | Moderne Subnetze und duale Netzwerke | Firewall-Regeln müssen IPv6 ausdrücklich berücksichtigen |
Bei virtuellen Netzwerken wie einer VPC oder VNet wird zuerst ein größerer Bereich festgelegt, etwa 10.20.0.0/16. Daraus entstehen kleinere Subnetze für öffentliche Komponenten, private Anwendungen und Datenbanken. Ich plane diese Ebenen lieber großzügig, aber mit klarer Reserve, statt später wegen fehlender Adressen ein laufendes Netzwerk zu migrieren.
IP-Planung für DevOps, Container und Kubernetes
In einer DevOps-Umgebung existieren meist mehrere Adressräume gleichzeitig. Ein Cloud-Netz besitzt einen Bereich für virtuelle Maschinen, Kubernetes verwendet zusätzliche Netze für Pods und Services, und VPNs oder On-Premises-Systeme bringen weitere Präfixe mit. Diese Bereiche müssen eindeutig und nicht überlappend sein.
VPCs und Subnetze sinnvoll aufteilen
Ein mögliches Schema sieht so aus:
- 10.20.0.0/16 für die gesamte Produktionsumgebung
- 10.20.0.0/20 für öffentliche Subnetze
- 10.20.16.0/20 für private Anwendungssysteme
- 10.20.32.0/20 für Datenbanken und interne Dienste
- 10.20.48.0/20 als Reserve für künftige Erweiterungen
Die genaue Größe hängt von der Plattform und dem Wachstum ab. Ein /28 wirkt am Anfang bequem, ist aber bei Autoscaling, mehreren Availability Zones und kurzlebigen Build-Runnern schnell erschöpft. Adressreserven sind Teil der Betriebsplanung, nicht bloß ein Komfortthema.
Container und Kubernetes nicht vergessen
Docker-Netzwerke, Kubernetes-Pods und Kubernetes-Services können eigene CIDR-Blöcke verwenden. Wenn ein Pod-Netz beispielsweise 10.244.0.0/16 nutzt, darf dieses Präfix nicht bereits im Rechenzentrum, im VPN oder in einem verbundenen VPC-Netz auftauchen.
Überlappungen führen oft zu schwer verständlichen Fehlern. Ein Server kann dann nicht eindeutig entscheiden, ob 10.10.5.20 im lokalen Netz, im VPN oder in der Cloud liegt. In meiner Praxis ist ein dokumentierter Adressplan deshalb mindestens so wichtig wie die eigentliche Firewall-Konfiguration.
Firewalls und Allowlisting richtig konfigurieren
Ein IP-Bereich wird häufig genutzt, um Zugriffe zu erlauben oder zu sperren. Eine Regel für 203.0.113.10/32 betrifft genau eine Adresse. Mit 203.0.113.0/24 würden dagegen 256 Adressen erfasst. Diese Unterscheidung entscheidet darüber, ob eine Sicherheitsregel präzise oder unnötig weit gefasst ist.
Für Administrationszugänge sollte ich möglichst kleine Präfixe verwenden. SSH oder RDP aus dem gesamten Internet freizugeben, also etwa 0.0.0.0/0, ist bequem, erhöht aber die Angriffsfläche massiv. Besser sind ein VPN, ein Bastion Host oder ein eng begrenztes Büro- beziehungsweise Provider-Netz.
Lesen Sie auch: Docker Swarm im Hosting richtig aufsetzen und betreiben
Allowlist oder große Provider-Range
Bei externen SaaS-Diensten und CI/CD-Plattformen ist die Lage komplizierter. Manche Anbieter veröffentlichen große, regelmäßig wechselnde Adresslisten. Eine vollständige Freigabe kann technisch erforderlich sein, ist aber weniger restriktiv als ein fester selbst betriebener Runner.
Ich prüfe deshalb vor jeder Allowlist drei Punkte. Wer kontrolliert den Bereich? Wie häufig ändert er sich? Und kann der Dienst stattdessen über private Konnektivität, einen festen Egress oder einen selbst gehosteten Agenten erreicht werden? Eine IP-Allowlist ist nützlich, ersetzt aber weder Authentifizierung noch Verschlüsselung.
Öffentliche Adressen, IPv6 und typische Planungsfehler
Ein öffentlicher Adressblock gehört nicht automatisch demjenigen, der ihn in einer Konfiguration einträgt. Öffentliche IPv4-Adressen werden von Providern, Rechenzentren oder Cloud-Anbietern zugewiesen. Für interne Netze sollte ich deshalb keine frei erfundenen öffentlichen Präfixe verwenden, sondern private Bereiche oder offiziell delegierte Adressen.
IPv6 verändert die Größenordnung deutlich. Ein /64 bietet so viele Adressen, dass die Anzahl einzelner Hosts kaum noch der begrenzende Faktor ist. Trotzdem bleiben Routing, Segmentierung und Firewall-Regeln wichtig. IPv6 einfach einzuschalten, ohne die Sicherheitsregeln für IPv6 zu prüfen, ist ein klassischer Fehler.
- Netze werden zu klein gewählt und blockieren später Autoscaling.
- Produktions-, Test- und Entwicklungsumgebungen verwenden dieselben Präfixe.
- VPN-Partner nutzen bereits identische privaten Bereiche.
- Eine Firewall erlaubt versehentlich ein ganzes /16 statt eines benötigten /32.
- IPv6 wird nicht dokumentiert, obwohl der Dienst dual-stack betrieben wird.
- Adressänderungen werden manuell durchgeführt und nicht als Infrastructure as Code versioniert.
Besonders der letzte Punkt wird unterschätzt. Ein IP-Plan gehört in die technische Dokumentation und, soweit möglich, in Terraform, Ansible oder eine zentrale IPAM-Lösung. So bleiben Änderungen nachvollziehbar und mehrere Teams arbeiten mit derselben Wahrheit.
Ein belastbarer IP-Plan für den nächsten Infrastrukturumbau
Ich beginne mit einer vollständigen Bestandsaufnahme aller bestehenden Netze, VPNs, Containerbereiche und externen Abhängigkeiten. Danach reserviere ich getrennte Blöcke für Produktion, Test, Entwicklung, Management und künftige Regionen. Erst wenn Überschneidungen ausgeschlossen sind, teile ich die größeren Netze in Subnetze auf.
Für kleine Umgebungen genügt eine Tabelle mit Präfix, Zweck, Standort, Verantwortlichem und Reserve. Größere Plattformen profitieren von IPAM, automatisierten Validierungen und einem CI-Check, der überlappende CIDR-Blöcke vor dem Deployment ablehnt.
Die wichtigste Entscheidung lautet nicht, möglichst viele Adressen zu reservieren, sondern einen klaren, erweiterbaren und dokumentierten Adressraum zu schaffen. Dann bleibt das Netzwerk auch bei neuen Services, zusätzlichen Standorten und wachsendem Kubernetes-Cluster beherrschbar.
