Eine IP-Adresse wirkt auf den ersten Blick wie eine zufällige Zahlen- oder Zeichenfolge, entscheidet aber darüber, ob ein Server erreichbar ist, ein Container mit dem richtigen Dienst spricht oder ein internes Netzwerk abgeschottet bleibt. Ein gutes IP-Adresse-Beispiel zeigt deshalb nicht nur das Format, sondern auch den Unterschied zwischen öffentlicher, privater und ausschließlich für Dokumentationen reservierter Adresse. Ich ordne die wichtigsten Varianten ein und zeige, welche Beispiele im Hosting- und DevOps-Alltag wirklich sicher verwendbar sind.
Die wichtigsten IP-Beispiele auf einen Blick
- IPv4 sieht beispielsweise wie 203.0.113.25 aus und besteht aus vier Zahlenblöcken.
- IPv6 nutzt hexadezimale Gruppen, etwa 2001:db8::25.
- Private Adressen wie 192.168.1.20 sind nur im internen Netzwerk gültig.
- Dokumentationsnetze wie 192.0.2.0/24 sind für Beispiele und Tests reserviert.
- Öffentliche IPs müssen eindeutig sein und werden vom Provider oder der Organisation verwaltet.
Wie eine IP-Adresse aufgebaut ist
Eine IP-Adresse ist die logische Adresse eines Geräts oder Dienstes in einem Netzwerk. Bei IPv4 besteht sie aus vier Dezimalzahlen zwischen 0 und 255, die durch Punkte getrennt werden. 203.0.113.25 ist deshalb syntaktisch korrekt, während 203.0.300.25 keine gültige IPv4-Adresse wäre.
Die Schreibweise allein verrät allerdings noch nicht, welche Rolle eine Adresse spielt. Entscheidend ist der Bereich, zu dem sie gehört. Ein Server mit 192.168.1.20 kann im Heimnetz erreichbar sein, ist aber nicht automatisch aus dem Internet zugänglich.
Adresse, Präfix und Subnetz
In der Praxis wird eine IP-Adresse häufig zusammen mit einem Präfix notiert, zum Beispiel 192.168.1.20/24. Die Zahl hinter dem Schrägstrich beschreibt, wie viele Bits zum Netzwerk gehören. Bei /24 umfasst das Netz typischerweise die Adressen 192.168.1.0 bis 192.168.1.255.
Für den Betrieb ist diese Unterscheidung wichtiger als die einzelne Adresse. Ein falsch gewähltes Subnetz kann dazu führen, dass Container, Datenbanken oder Load-Balancer zwar laufen, sich aber nicht gegenseitig erreichen.
Öffentliche, private und reservierte Adressen im Vergleich
Die drei wichtigsten Kategorien sehen ähnlich aus, erfüllen aber völlig unterschiedliche Zwecke. Ich verwende in technischen Dokumentationen möglichst reservierte Beispielbereiche, damit niemand versehentlich die Adresse eines echten Systems übernimmt.
| Typ | Beispiel | Typischer Einsatz | Aus dem Internet erreichbar |
|---|---|---|---|
| Öffentliche IPv4 | Beispieladresse des Providers | Webserver, Mailserver, VPN-Gateway | Grundsätzlich ja, abhängig von Firewall und Routing |
| Private IPv4 | 192.168.1.20 | LAN, Servernetz, Container- oder Cloud-Netzwerk | Nein, nicht direkt |
| Dokumentationsadresse | 192.0.2.25 | Handbücher, Präsentationen, Testkonfigurationen | Nein, nicht für den produktiven Betrieb |
| IPv6-Dokumentation | 2001:db8::25 | Beispiele und Schulungsumgebungen | Nein, ausschließlich dokumentarisch |
Private IPv4-Bereiche
Für interne Netze sind drei Bereiche vorgesehen. 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 eignet sich daher für einen internen Datenbankserver, nicht aber als öffentliche Adresse für eine Website.
Diese Netze werden meist über NAT ins Internet übersetzt. NAT ersetzt die interne Absenderadresse beim Verlassen des Netzwerks durch eine öffentliche Adresse. Das spart öffentliche IPv4-Adressen, erschwert aber eingehende Verbindungen und kann bei komplexen Container- oder VPN-Setups zusätzliche Konfiguration erfordern.
Reservierte Bereiche für Beispiele
Für realistisch aussehende IPv4-Beispiele gibt es die drei TEST-NET-Bereiche 192.0.2.0/24, 198.51.100.0/24 und 203.0.113.0/24. Eine Adresse wie 203.0.113.25 ist damit ideal für eine Dokumentation, ein Architekturdiagramm oder einen Blogartikel.
Für IPv6 übernimmt 2001:db8::/32 dieselbe Rolle. Ich würde diese Adressen niemals in eine produktive DNS-Zone oder eine Firewall übernehmen. Genau darin liegt ihr Vorteil, denn sie machen Beispiele verständlich, ohne auf ein tatsächlich betriebenes System zu zeigen.
Konkrete IP-Adresse-Beispiele für Hosting und DevOps
Im Hosting entscheidet die Adresse oft darüber, ob ein Dienst öffentlich erreichbar ist oder nur innerhalb einer Infrastruktur funktioniert. In DevOps kommt hinzu, dass mehrere Ebenen zusammenspielen. Dazu zählen virtuelle Maschinen, Container, Kubernetes-Netze, Reverse Proxy, DNS und Firewall.
Webserver mit Reverse Proxy
Ein Dokumentationsaufbau könnte so aussehen. Der öffentliche Reverse Proxy nutzt 203.0.113.25, die Anwendung läuft intern unter 10.20.0.15 und die Datenbank unter 10.20.0.30. Nur der Proxy nimmt Verbindungen aus dem Internet an, während Anwendung und Datenbank im privaten Netz bleiben.
Dieses Muster ist sicherer als eine Datenbank mit eigener öffentlicher Adresse. Für eine Website werden meist nur Port 80 für HTTP und Port 443 für HTTPS freigegeben. Der Datenbankport bleibt intern und wird zusätzlich durch Sicherheitsgruppen oder Firewall-Regeln eingeschränkt.
Docker und Container
Container erhalten häufig interne Adressen aus einem automatisch erzeugten Docker-Netzwerk, beispielsweise 172.18.0.5. Diese Adresse ist nicht stabil genug, um sie dauerhaft in eine Anwendungskonfiguration einzutragen. Container sollten sich über Servicenamen wie database oder api finden, weil sich ihre IP-Adresse nach einem Neustart ändern kann.
Das ist ein typischer Fehler bei ersten Deployments. Wer eine Container-IP fest einträgt, baut eine fragile Verbindung. Ich verlasse mich in solchen Umgebungen lieber auf internes DNS oder die Service-Erkennung der Plattform.
Kubernetes und interne Dienste
In Kubernetes unterscheiden sich Pod-IP, Service-IP und externe Load-Balancer-Adresse. Ein Pod könnte beispielsweise 10.244.2.17 erhalten, ein interner Service 10.96.0.10 und der öffentliche Load Balancer 203.0.113.40 als reine Dokumentationsadresse.
Die Pod-IP sollte normalerweise nicht direkt von außen angesprochen werden. Ein Service stellt eine stabile Abstraktion bereit, während Ingress oder Load Balancer den externen Zugriff kontrolliert. Das macht Deployments robuster, weil einzelne Pods jederzeit ersetzt werden können.
VPN und Serverzugriff
Für ein VPN kann ein eigener privater Bereich wie 10.50.0.0/24 verwendet werden. Ein Client erhält dann beispielsweise 10.50.0.12 und erreicht interne Systeme über deren private Adressen. Konflikte entstehen, wenn das lokale Heimnetz ebenfalls 10.50.0.0/24 nutzt.
Ich prüfe deshalb vor dem Einrichten eines VPNs immer, welche privaten Netze bei den Beteiligten bereits existieren. Ein weniger naheliegendes Netz kann hier praktischer sein als der bekannte Bereich 192.168.0.0/24.
IPv4 und IPv6 an verständlichen Beispielen erklärt
IPv4 ist kompakt und weit verbreitet, bietet aber nur rund 4,3 Milliarden Adressen. IPv6 erweitert den Adressraum massiv und wird im modernen Hosting zunehmend parallel zu IPv4 betrieben. Dieser Parallelbetrieb heißt Dual Stack.
| Merkmal | IPv4 | IPv6 |
|---|---|---|
| Beispiel | 203.0.113.25 | 2001:db8::25 |
| Schreibweise | Vier Dezimalblöcke | Hexadezimale Gruppen mit Doppelpunkten |
| Private Nutzung | 10.0.0.0/8 oder 192.168.0.0/16 | Unique Local Addresses, meist fd00::/8 |
| Typische Herausforderung | Adressknappheit und NAT | Firewall, Routing und ungewohnte Schreibweise |
Bei IPv6 dürfen führende Nullen innerhalb einer Gruppe entfallen. Mehrere aufeinanderfolgende Nullgruppen werden einmalig durch :: ersetzt. Aus 2001:0db8:0000:0000:0000:0000:0000:0025 wird dadurch 2001:db8::25.
Die verkürzte Schreibweise ist praktisch, kann aber anfangs irritieren. Beim Debugging achte ich besonders darauf, ob eine Anwendung IPv6 tatsächlich unterstützt und ob die Firewall-Regeln für beide Protokolle existieren. Eine nur für IPv4 getestete Konfiguration ist nicht automatisch IPv6-tauglich.
So prüfst du eine IP-Adresse ohne typische Fehler
Ein Blick auf das Format reicht nicht aus, um die Funktion einer Adresse zu beurteilen. Für eine belastbare Prüfung kombiniere ich die Adressklasse mit Routing, DNS und Erreichbarkeit.
- Format prüfen und feststellen, ob es sich um IPv4 oder IPv6 handelt.
- Adressbereich erkennen, also öffentlich, privat, Loopback oder dokumentarisch.
- Subnetz kontrollieren, damit Netzmaske und Gateway zusammenpassen.
- DNS-Auflösung testen, falls ein Hostname verwendet wird.
- Ports gezielt prüfen, statt nur einen Ping auszuführen.
- Firewall und Routing ansehen, wenn der Dienst trotz korrekter Adresse nicht erreichbar ist.
Ein Ping ist dabei kein vollständiger Funktionstest. ICMP kann blockiert sein, obwohl HTTPS funktioniert. Für einen Webdienst ist ein Test mit HTTPS auf Port 443 aussagekräftiger als die alleinige Antwort auf einen Ping.
Lesen Sie auch: Docker Logs richtig nutzen - Befehle, Filter und Log-Rotation
Häufige Fehlannahmen
- Private IP gleich sicher ist falsch. Ein internes Netz reduziert die öffentliche Angriffsfläche, ersetzt aber keine Zugriffskontrolle.
- Öffentliche IP gleich erreichbar stimmt nicht. Firewall, Routing, Providerfilter oder ein fehlender Dienst können den Zugriff verhindern.
- Dokumentationsadresse gleich Testserver ist ebenfalls falsch. TEST-NET-Adressen sind für Beispiele reserviert und nicht für reale Dienste gedacht.
- IP-Adresse gleich dauerhafte Identität gilt nicht bei DHCP, Cloud-Instanzen oder Containern. Adressen können sich ändern.
Gerade im Cloud-Betrieb wird die IP häufig überschätzt. Für Anwendungen sind stabile DNS-Namen, Health Checks und deklarative Infrastruktur meist wichtiger als eine dauerhaft fest verdrahtete Einzeladresse.
Die passende Adresse für jedes Beispiel wählen
Für einen Blogartikel, ein Diagramm oder eine Schulung greife ich zu 192.0.2.25, 198.51.100.15 oder 203.0.113.40. Für ein internes Hosting-Netz passen Adressen aus 10.0.0.0/8, 172.16.0.0/12 oder 192.168.0.0/16. Ein produktiver öffentlicher Server benötigt dagegen eine tatsächlich vom Provider zugewiesene Adresse.
Bei IPv6 ist 2001:db8::25 das klare Beispiel für Dokumentationen. Für interne IPv6-Netze kommen Unique Local Addresses infrage, während öffentliche Dienste eine global geroutete Adresse aus dem Präfix des Providers erhalten.
Mein wichtigster Praxistipp lautet deshalb, Beispiele immer mit ihrer Rolle zu beschriften. Die Angabe „Webserver 203.0.113.25, Datenbank 10.20.0.30, internes Gateway 10.20.0.1“ erklärt deutlich mehr als eine ungeordnete Liste von Zahlen. So bleibt sichtbar, was öffentlich sein soll, was intern bleibt und was nur zur Illustration dient.
Wer diese drei Ebenen sauber trennt, vermeidet die meisten Missverständnisse rund um IP-Adressen. Für Hosting und DevOps zählt am Ende nicht die schönste Beispieladresse, sondern ein nachvollziehbares Zusammenspiel aus Subnetz, DNS, Routing und Zugriffsschutz.
