Die private IP-Adressierung ist eine der nützlichsten Funktionen des Protokolls. Dieser Adressraum ist für die unregulierte Nutzung im lokalen Rahmen (innerhalb einer Organisation, ohne Verbindung über das Internet) vorgesehen und bietet die Freiheit, große interne Netzwerke zu erstellen.
Diese Flexibilität hat jedoch ihren Preis: Beim Versuch, zwei zuvor getrennte private IP-Netzwerke zu verbinden, kann es sein, dass in beiden Netzwerken einige derselben IP-Adressen verwendet wurden. Da IP-Adressen innerhalb jedes Netzwerks oder jeder Routingdomäne eindeutig sein müssen, führen diese Duplikate zu instabilen Netzwerkzugriffen in die und aus den überlappenden Bereichen. Zwar gibt es herkömmliche Workarounds, um die Auswirkungen zu verringern, aber F5 Volterra bietet eine Möglichkeit, das Problem vollständig zu vermeiden.
Wenn sich zwei unterschiedliche Teile eines Netzwerks überschneiden und denselben IP-Subnetzadressbereich verwenden, treten zwei Hauptprobleme auf. Erstens können diese beiden Subnetze überhaupt nicht miteinander kommunizieren, da keines der Geräte weiß, dass die Adresse nicht für einen lokalen Endpunkt bestimmt ist. Wenn beide Subnetze nur für Clients bestimmt und voller Benutzer sind, lässt sich dieses Problem möglicherweise leicht beheben. Wenn jedoch ein Subnetz Netzwerkdienste enthält, sind diese Dienste für das andere Subnetz völlig unerreichbar. Darüber hinaus wirkt sich eine IP-Überlappung auf den gesamten Datenverkehr aus, der von anderen Orten im Netzwerk zu diesen Subnetzen gelangt. Da Router im Netzwerk Informationen austauschen, werden beide Subnetze angekündigt, jedoch von zwei verschiedenen Standorten aus. Es kann jederzeit vorkommen, dass Verbindungen an den falschen Ort gesendet werden, auch bei erfolgreich hergestellten Verbindungen.
Die häufigste Ursache für IP-Überschneidungen in gut verwalteten Netzwerken ist die Verbindung oder Zusammenführung zweier zuvor getrennter Netzwerke. Das Szenario ist leicht vorstellbar, wenn zwei Organisationen fusionieren, insbesondere wenn die IT in beiden Organisationen eine ähnliche Adresszuweisungskonvention verwendet, beispielsweise 10/8 für Endpunkte und 172.16/12 für die Infrastruktur. Allerdings kommt es bei der Anbindung an eine oder mehrere Clouds immer häufiger zu Überschneidungen. Die größten Einzelnetzwerke befinden sich bei Hyperscalern wie öffentlichen Cloud-Anbietern und diese verwenden notwendigerweise private IP-Adressierungen. Wenn auf jedem Server eine große Anzahl VMs oder eine noch größere Anzahl Container gehostet wird, könnte eine einzelne Zeile ein ganzes /16-Netzwerk beanspruchen. Mit der steigenden Nachfrage nach der Cloud stieg auch die Nachfrage nach Zugriffsmöglichkeiten. Von Client-Site-VPNs hin zu Site-Site-VPNs, Multi-Cloud-Netzwerkprodukten und sogar direkten WAN-Verbindungen zu Cloud-Rechenzentren. Site-Site-VPNs und WAN-Links verbinden Teile des Cloud-Netzwerks effektiv mit dem Netzwerk des Kunden. Da die meisten Kundennetzwerke auch auf privaten IP-Adressen basieren, kommt es zunehmend zu IP-Überschneidungen.
Mit der zunehmenden Verbreitung verteilter moderner Apps werden auch App-zu-App-Verbindungen wie Hybrid Cloud, Cloud-zu-Cloud und Edge-zu-Cloud immer üblicher. Skalierbare Architekturen erfordern eine Methode zum Umgang mit IP-Überschneidungen, die sauber automatisiert werden kann. Viele Netzwerkadministratoren wenden sich zunächst NAT zu, denn schließlich ermöglicht NAT privaten IP-Adressen die Verbindung zum öffentlichen Internet. Allerdings verlagert NAT das Problem lediglich, anstatt es zu lösen: Die Abstraktion erstreckt sich nicht innerhalb des Subnetzes, sodass die Last der Bewältigung von Randfällen (wie Remote-Netzwerken mit demselben Subnetzbereich) auf Anwendungen und Dienste verlagert wird. Darüber hinaus beeinträchtigt NAT die Sichtbarkeit, indem es eine Verzerrung zwischen innerhalb und außerhalb des Subnetzes erfassten Ereignissen erzeugt. Die durch NAT verursachten laufenden Betriebskosten sind nur dann gerechtfertigt, wenn andere Optionen – wie beispielsweise eine Neunummerierung – schlechter sind.
Volterra VoltMesh von F5 bietet eine saubere Lösung gegen IP-Überlappungen. Überlappungen sind nur dann ein Problem, wenn Verbindungen auf L3 basieren. Daher trennt VoltMesh die L3-Adressen von den Transaktionen auf L4 oder L7 und verwendet dabei dieselben Methoden zur Anwendungsbereitstellung, auf die sich F5-Kunden seit 25 Jahren verlassen. VoltMesh verfügt jedoch über eine einzigartige Funktion: Da die Funktionen verteilt sind, kann die IT für die Bereitstellung der Anwendung eine beliebige IP-Adresse überall im Mesh auswählen. Und da die Funktionen integriert sind, bleibt die vollständige End-to-End-Sichtbarkeit für Netzwerk, Sicherheit und sogar die Anwendung erhalten. Mit VoltMesh ist es sogar möglich, einen Remote-Dienst – unabhängig von seiner tatsächlichen IP-Adresse – in ein lokales Subnetz mit einer lokalen IP-Adresse bereitzustellen. Es sind also überhaupt keine Netzwerkänderungen erforderlich: kein NAT, keine Firewall-Löcher und keine Routing-Änderungen. VoltMesh bietet vollständige Kontrolle und vollständige Sichtbarkeit ohne Netzwerkunterbrechung und damit die sauberste mögliche IP-Überlappungslösung.
Im Zeitalter der Multi-Cloud werden Netzwerke dank privater IP-Adressierung immer weiter ausgebaut und miteinander verbunden. Das bedeutet, dass IP-Überschneidungen auch weiterhin ein Problem darstellen werden, solange der Schwerpunkt auf der herkömmlichen Konnektivität liegt. Ob vor Ort oder zwischen Clouds – F5 Volterra VoltMesh kann Dienste sicher bereitstellen, indem es Anwendungen von der Netzwerkschicht entkoppelt, Erreichbarkeit ohne Konnektivität bietet und eine saubere Trennung gewährleistet, um die Privatsphäre privater Netzwerke zu wahren.
Weitere Informationen finden Sie unter „Journey to the Multi-Cloud Challenges“ auf DevCentral von F5 und „Get Complete Multi-Cloud Management with F5“.