In Provider-Netzen ist die klare Trennung zwischen privaten (RFC1918) und öffentlichen IPv4-Adressen entscheidend, um Routing-Konflikte, Sicherheitsprobleme und Skalierungsengpässe zu vermeiden. RFC1918-Adressen werden typischerweise intern oder für CGNAT genutzt, während öffentliche IPv4-Adressen direkt von Kunden oder für Internetzugang verwendet werden. Dieser Artikel vermittelt Einsteigern, IT-Studierenden und Junior Network Engineers praxisnah, wie Provider die beiden Adressräume sauber trennen und einsetzen.
Grundlagen von RFC1918-Adressen
RFC1918 definiert private IPv4-Adressräume, die nicht routbar im öffentlichen Internet sind. Die gängigen Bereiche:
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
Verwendung:
- Private interne Netze
- Access- oder Kunden-VLANs hinter CGNAT
- Management- und Service-Netze
- Schutz vor direkten Zugriffen aus dem Internet
Grundlagen öffentlicher IPv4-Adressen
Öffentliche IPv4-Adressen sind weltweit eindeutig und routbar. Sie werden von Registries wie RIPE oder ARIN vergeben.
- Direkter Internetzugang für Kunden
- Edge-Services wie Webserver, DNS oder VPN-Gateways
- Vermeidung von NAT bei Geschäftskunden oder Enterprise-Services
- Integration in BGP-Routing für globale Erreichbarkeit
Provider-Use-Cases für RFC1918
Private Adressen werden intern oder hinter NAT verwendet, um den öffentlichen Adressraum zu entlasten:
- CGNAT-Pools für Consumer-Access
- Interne VLAN- und VRF-Strukturen
- Management- und Monitoring-Netze
- Test- und Laborumgebungen
Beispiel CGNAT-Pool
# Private RFC1918-Pool
100.64.0.0/10 → CGNAT-Use
10.16.0.0/16 → interner Access VLAN
172.16.0.0/12 → Management-Netz
Provider-Use-Cases für öffentliche IPv4-Adressen
Öffentliche Adressen werden für direkt erreichbare Dienste oder Kunden bereitgestellt:
- Business-Kunden mit eigenem Internetzugang
- Hosting und Cloud-Services
- Firewall DMZ, VPN-Gateways, NAT-Exits
- Peering und Internet-Exchange-Verbindungen
Beispiel öffentliche IPv4-Zuweisung
# Öffentlicher Pool
198.51.100.0/24 → Kunden A
198.51.101.0/24 → Kunden B
203.0.113.0/24 → DMZ/Hosting
Trennung von RFC1918 und Public IPv4 im Netzdesign
Eine saubere Trennung reduziert Routing-Konflikte und vereinfacht den Betrieb:
- Private Netze werden intern oder hinter CGNAT gehalten
- Public IPs werden dediziert pro Kunden oder Service bereitgestellt
- VLAN- und VRF-Zuweisung trennt interne und externe Netze
- Edge-Router und Firewalls kontrollieren Übersetzungen und Zugriff
Beispiel-Topologie
Core Router
|
|-- VRF-Internal → RFC1918 VLANs / CGNAT-Pools
| 10.16.0.0/16
| 172.16.0.0/12
|
|-- VRF-Public → öffentliche IPv4-Zuweisungen
198.51.100.0/24
198.51.101.0/24
Logging und Audit
Besonders bei CGNAT ist Logging entscheidend, um Verbindungen einzelner Kunden nachvollziehen zu können:
- Mapping private → öffentliche IPv4-Adressen und Ports
- Session-Lifetime und Timeout überwachen
- Automatisierte Logs für Compliance und Troubleshooting
- Dokumentation in IPAM für interne Adressräume
Best Practices für Provider
- Klare Trennung von RFC1918- und Public-IP-Pools
- Private Adressen nur intern oder hinter CGNAT einsetzen
- Public IPv4 nur direkt erreichbaren Kunden oder Services zuweisen
- VLANs und VRFs für Segmentierung nutzen
- IPAM-Integration zur Verwaltung und Auditierung
- Reservierte Pools für Wachstum und M&A-Aktivitäten planen
- Routing- und Firewall-Regeln klar nach Public vs. Private trennen
Praxisbeispiel eines Provider-Netzes
- Core-Backbone: 10.0.0.0/12 für interne Netze
- Region Nord: RFC1918 10.16.0.0/16 für Access VLANs
- CGNAT-Pool: 100.64.0.0/10 für Consumer-Access
- Public IPv4 Pool: 198.51.100.0/24 → Business-Kunde A
- Public IPv4 Pool: 198.51.101.0/24 → Business-Kunde B
- DMZ Hosting: 203.0.113.0/24 → Webserver, Firewall-Exits
- Logging und IPAM dokumentieren alle Zuordnungen und Sessions
Skalierung und Wachstum
Eine konsistente Trennung ermöglicht Wachstum, Integration neuer POPs und M&A-Netze:
- Neue RFC1918-Blöcke für Access- oder CGNAT-Pools reservieren
- Public IPv4-Zuweisungen geplant und dokumentiert
- Automatisierte IPAM-Integration für Adressverfolgung
- Redundanz und Failover für Core- und Edge-Router berücksichtigen
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3
Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.
Meine Leistungen umfassen:
-
Professionelle Konfiguration von Routern und Switches
-
Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen
-
Erstellung von Topologien und Simulationen in Cisco Packet Tracer
-
Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG
-
Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible
-
Erstellung von Skripten für wiederkehrende Netzwerkaufgaben
-
Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege
-
Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting
Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.
