Wenn eine Website plötzlich langsam wird, ein Container keine Datenbank erreicht oder ein Server trotz laufendem Dienst nicht erreichbar ist, liegt die Ursache oft im Netzwerk. Ein IP-Netzwerk verbindet Geräte über adressierte Datenpakete und bildet damit die Grundlage für Hosting, Cloud-Infrastrukturen und automatisierte Deployments. Ich zeige, wie IP-Adressen, Subnetze, DNS, Container-Netzwerke und Sicherheitsregeln zusammenspielen und worauf es bei einer belastbaren Infrastruktur ankommt.
Die wichtigsten Entscheidungen für ein stabiles IP-Netzwerk
- IPv4 und IPv6 erfüllen dieselbe Grundaufgabe, werden aber unterschiedlich adressiert und geplant.
- Subnetze trennen öffentliche Dienste, interne Anwendungen, Datenbanken und Administration.
- Private IP-Adressen sind nicht automatisch sicher. Firewall-Regeln und Netzwerkpolicies bleiben unverzichtbar.
- Docker und Kubernetes abstrahieren die Netzwerktechnik, lösen aber keine fehlerhafte Adressplanung.
- DNS, Routing und Monitoring entscheiden im Betrieb oft stärker über die Zuverlässigkeit als die reine Bandbreite.
Was ein IP-Netzwerk praktisch leistet
Ein Netzwerk auf Basis des Internet Protocol sorgt dafür, dass Datenpakete vom Absender zum richtigen Empfänger gelangen. Dafür erhält jedes Gerät oder jede virtuelle Schnittstelle eine IP-Adresse. Router lesen diese Adresse und entscheiden anhand ihrer Routingtabelle, über welchen nächsten Weg das Paket weitergeleitet wird.
Die IP-Schicht kümmert sich dabei um die Zustellung zwischen Netzen, nicht um den Inhalt der Kommunikation. TCP sorgt beispielsweise für eine zuverlässige Übertragung, während UDP mit weniger Overhead arbeitet und sich gut für DNS, Streaming oder bestimmte Echtzeitanwendungen eignet. Diese Trennung ist für DevOps wichtig, weil ein Fehler bei IP, Port, DNS oder Anwendung jeweils eine andere Ursache hat.
Ein einfacher Zugriff auf eine gehostete Website sieht meist so aus: DNS liefert die Adresse des Webservers oder Load Balancers, der Client baut eine TCP- oder QUIC-Verbindung auf und die Firewall prüft den Datenverkehr. Danach übernimmt ein Webserver oder Reverse Proxy die Anfrage. Die IP-Adresse allein ist also nur ein Teil der gesamten Verbindung.
Öffentliche und private Adressen
Eine öffentliche IPv4-Adresse ist aus dem Internet erreichbar, sofern Routing und Firewall dies erlauben. Private IPv4-Bereiche sind für interne Netze reserviert. Dazu gehören 10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16. Eine Adresse wie 10.20.4.15 kann deshalb in vielen voneinander getrennten Netzwerken gleichzeitig vorkommen.
Damit private Geräte ins Internet gelangen, wird häufig NAT eingesetzt. Der Router übersetzt interne Adressen in eine öffentliche Adresse. Für kleine Umgebungen ist das praktisch, im Hosting sollte man NAT jedoch nicht als Sicherheitskonzept missverstehen. Eine private Adresse schützt keinen Dienst, wenn andere interne Systeme unkontrolliert auf ihn zugreifen können.
IPv4, IPv6 und die richtige Adressplanung
IPv4 verwendet 32 Bit und wird meist in vier Dezimalgruppen dargestellt, etwa 203.0.113.10. IPv6 arbeitet mit 128 Bit und sieht beispielsweise so aus: 2001:db8:1200::10. Der große Adressraum von IPv6 beseitigt den Mangel an öffentlichen Adressen, macht aber keine saubere Planung überflüssig.
Ich plane neue Umgebungen grundsätzlich für IPv4 und IPv6, auch wenn ein Teil der Anwendungen zunächst nur IPv4 nutzt. Ein reiner IPv6-Betrieb kann funktionieren, scheitert aber in der Praxis noch immer an einzelnen Abhängigkeiten, älteren APIs oder externen Diensten. Dual Stack ist deshalb für viele Unternehmen der pragmatischere Übergang, erhöht aber den Aufwand für Firewall-Regeln und Monitoring.
CIDR verständlich gemacht
Die Schreibweise /24 bezeichnet die Länge des Netzanteils einer IPv4-Adresse. Ein IPv4-Netz mit /24 enthält 256 Adressen, wobei in klassischen lokalen Netzen meist 254 für Hosts verfügbar sind. Cloud-Plattformen reservieren teilweise zusätzliche Adressen, weshalb die tatsächlich nutzbare Anzahl vom Anbieter abhängt.
Für ein mittelgroßes Hosting-Setup kann eine Struktur wie diese sinnvoll sein:
| Bereich | Beispielnetz | Zweck |
|---|---|---|
| Frontend | 10.20.10.0/24 | Reverse Proxy, Load Balancer und öffentliche Webdienste |
| Anwendungen | 10.20.20.0/24 | Interne APIs und Worker |
| Datenbanken | 10.20.30.0/24 | SQL-, NoSQL- und Cache-Dienste |
| Administration | 10.20.40.0/24 | Monitoring, Bastion Host und Management-Zugänge |
Die konkreten Bereiche sind nur ein Muster. Entscheidend ist, dass sie nach Funktion und Vertrauensniveau getrennt werden. Ein Datenbanknetz sollte nicht einfach deshalb im selben Subnetz liegen, weil noch freie Adressen vorhanden sind.
IPv6 braucht größere Denkmodelle
Bei IPv6 ist ein einzelnes LAN normalerweise ein /64-Netz. Ein /56-Präfix bietet 256 solcher /64-Netze, ein /48-Präfix sogar 65.536. Für ein Rechenzentrum ist deshalb nicht die Zahl einzelner Geräte der wichtigste Planungsfaktor, sondern die Zahl der Standorte, Zonen und künftigen Segmente.
Das RIPE NCC empfiehlt für übersichtliche IPv6-Pläne eine Aufteilung an 4-Bit-Grenzen, etwa /48, /52, /56, /60 oder /64. Ich halte das für eine sehr gute Praxis, weil sich die Adressen leichter lesen, aggregieren und in Reverse-DNS-Zonen verwalten lassen. Ein zu knappes Präfix spart heute kaum etwas, kann aber später eine teure Umnummerierung erzwingen.
Wie Subnetze Hosting sicherer und übersichtlicher machen
Beim Hosting sollte ein Server nicht einfach als eine große Sammlung offener Ports betrachtet werden. Besser ist ein klarer Datenfluss. Internetverkehr erreicht zunächst einen Reverse Proxy oder Load Balancer. Dieser nimmt HTTPS entgegen und leitet die Anfrage nur an die dafür vorgesehenen Anwendungsdienste weiter.
Die Datenbank bleibt dabei in einem privaten Segment. Sie braucht normalerweise keine öffentliche IP-Adresse und sollte nur von den tatsächlich benötigten Anwendungsservern erreichbar sein. Für administrative Zugriffe nutze ich lieber einen abgesicherten Bastion Host oder ein VPN als direkt geöffnete SSH-Ports aus dem gesamten Internet.
Ein sinnvolles Verkehrsmodell
- Öffentlich erreichbar sind nur 80 und 443, sofern HTTP für die Weiterleitung auf HTTPS gebraucht wird.
- Der Reverse Proxy darf zu den Web- und API-Diensten im internen Segment verbinden.
- Die Anwendung darf nur auf die erforderlichen Datenbank-, Cache- und Messaging-Ports zugreifen.
- Die Datenbank akzeptiert keine Verbindungen aus dem öffentlichen Netz.
- Administrationszugänge sind auf VPN-Netze, feste Quelladressen oder einen Bastion Host begrenzt.
Diese Struktur hilft nicht nur bei der Sicherheit. Sie macht auch Fehlersuche und spätere Änderungen einfacher. Wenn eine API von außen funktioniert, aber keine Datenbankverbindung aufbauen kann, lässt sich die Suche auf Routing, Firewall, DNS oder Zugangsdaten im internen Pfad konzentrieren.
Welche Rolle Docker und Kubernetes spielen
Container bringen eine zusätzliche Netzwerkschicht ins System. Ein Docker-Container erhält meist eine eigene interne Adresse und kommuniziert über ein virtuelles Bridge-Netzwerk mit anderen Containern. Ein Bridge-Netz ist an einen einzelnen Docker-Host gebunden. Für mehrere Hosts wird ein Overlay-Netzwerk oder eine andere Routinglösung benötigt.
Das ist ein häufiger Denkfehler: Ein Port-Mapping wie 443:8443 bedeutet nicht, dass der Dienst automatisch sicher oder global erreichbar ist. Es bedeutet zunächst nur, dass ein Port des Hosts an einen Port im Container weitergeleitet wird. Erreichbarkeit, Bind-Adresse und Firewall müssen separat geprüft werden.
Services und Zugriff im Kubernetes-Cluster
Kubernetes trennt Pods, Services und den externen Zugriff. Ein Service stellt für eine Gruppe von Pods einen stabilen internen Endpunkt bereit, auch wenn einzelne Pods neu erstellt werden. Der Typ ClusterIP ist nur innerhalb des Clusters erreichbar, während LoadBalancer oder NodePort den Dienst nach außen bringen können.
Für HTTP- und HTTPS-Anwendungen wird häufig ein Ingress Controller verwendet. Die Kubernetes-Dokumentation weist inzwischen darauf hin, dass die Ingress-API eingefroren ist und für neue Funktionen die Gateway API bevorzugt wird. Für bestehende Installationen ist Ingress weiterhin nutzbar, bei neuen Plattformen sollte ich die langfristige Entwicklung aber in die Entscheidung einbeziehen.
Eine zusätzliche NetworkPolicy legt fest, welcher Pod mit welchem anderen Pod kommunizieren darf. Ohne solche Regeln ist die interne Erreichbarkeit oft großzügiger als gedacht. Für produktive Cluster empfehle ich ein restriktives Grundmodell und explizite Freigaben für Datenbank, DNS, Monitoring und externe APIs.
IP-Netzwerke richtig absichern und überwachen
Ein Netzwerk ist sicher, wenn erlaubte Kommunikationswege bewusst definiert und unerwartete Wege sichtbar gemacht werden. Dazu gehören Firewalls an der Netzgrenze, Regeln zwischen Segmenten und bei Kubernetes zusätzlich Policies auf Pod-Ebene. IPv4- und IPv6-Regeln müssen gleichwertig gepflegt werden. Eine IPv6-Adresse darf nicht unbeabsichtigt einen Dienst erreichbar machen, der über IPv4 geschützt ist.
Besonders kritisch sind pauschale Regeln wie „alles aus dem internen Netz erlauben“. In einer Cloud oder einem Cluster können dort auch kompromittierte Workloads liegen. Ich bevorzuge Regeln nach Anwendung, Port und Ziel, ergänzt durch kontrollierten ausgehenden Datenverkehr. Das wirkt anfangs aufwendiger, reduziert aber die Reichweite eines Fehlers.
Lesen Sie auch: Docker oder VM? Die passende Basis für Hosting und DevOps
Was ich bei der Fehlersuche zuerst prüfe
-
ip addrzeigt, ob die Schnittstelle die erwartete Adresse besitzt. -
ip routemacht sichtbar, ob ein passender Weg zum Ziel vorhanden ist. -
digprüft DNS-Auflösung, TTL und gegebenenfalls unterschiedliche IPv4- und IPv6-Antworten. -
ss -tulpnzeigt, ob der Dienst tatsächlich lauscht und an welcher Adresse. -
curl -vhilft, DNS, TLS, HTTP-Status und Verbindungsaufbau voneinander zu trennen. -
tracerouteodertracepathkann Routingprobleme und unerwartete Zwischenstationen sichtbar machen.
Im Monitoring beobachte ich mindestens Latenz, Paketverlust, Fehlerraten und Verbindungsanzahl. Eine hohe Bandbreite hilft wenig, wenn die Datenbank regelmäßig neue Verbindungen aufbauen muss oder ein Load Balancer seine Connection-Limits erreicht. Gute Dashboards zeigen deshalb nicht nur Traffic, sondern auch den Weg und die Abhängigkeiten einer Anfrage.
Die häufigsten Planungsfehler im Betrieb
Der erste Fehler ist ein zu knapp gewählter Adressraum. Ein /24-Netz kann für einen kleinen Dienst reichen, wird aber schnell eng, wenn zusätzlich Staging, Monitoring, Worker und temporäre Deployments entstehen. Ich reserviere lieber früh getrennte Bereiche, statt später produktive Systeme umnummerieren zu müssen.
Der zweite Fehler ist die Vermischung von öffentlichem und internem Verkehr. Nicht jeder Dienst braucht eine öffentliche Adresse, und nicht jede interne Adresse darf beliebige Ziele erreichen. Ein dritter Klassiker ist die Annahme, dass DNS-Probleme automatisch Netzwerkprobleme sind. DNS kann auflösen, während Routing, TLS oder eine Firewall den Zugriff trotzdem verhindern.
Auch NAT wird häufig überschätzt. Es versteckt interne Adressen, ersetzt aber weder Authentifizierung noch Segmentierung. Bei IPv6 fällt diese Krücke weitgehend weg, was zunächst ungewohnt ist, aber zu einer saubereren Architektur zwingt. Explizite Firewall-Regeln sind langfristig robuster als zufällige Nichterreichbarkeit.
Eine belastbare IP-Struktur beginnt mit dem Datenfluss
Für ein neues Hosting- oder DevOps-Projekt zeichne ich zuerst den Weg einer Anfrage vom Client bis zur Datenbank. Danach teile ich die Infrastruktur in öffentliche, interne und administrative Bereiche auf, lege IPv4- und IPv6-Präfixe fest und dokumentiere jede erlaubte Verbindung.
Die beste Lösung ist nicht das größtmögliche Netzwerk, sondern ein verständlich aufgebauter Adressraum, der Wachstum, Ausfälle und Sicherheitsanforderungen berücksichtigt. Wer Adressen, Routing, DNS, Container und Firewall als zusammenhängendes System plant, findet Fehler schneller und kann Deployments deutlich zuverlässiger automatisieren.
