DE112021004469T5

DE112021004469T5 - Verfahren und systeme zur effizienten virtualisierung von transparenten inline-computernetzwerkgeräten

Info

Publication number: DE112021004469T5
Application number: DE112021004469.9T
Authority: DE
Inventors: Richard Goodwin; Paul Sprague; Peter Geremia; Sean Moore
Original assignee: Centripetal Networks LLC
Current assignee: CENTRIPETAL LIMITED, IE
Priority date: 2020-08-27
Filing date: 2021-08-26
Publication date: 2023-06-07
Also published as: JP2023546775A; EP4205372A1; US11316823B2; CA3190870A1; WO2022047019A1; US11902240B2; US20230179563A1; US20220210119A1; US11570138B2; KR20230108254A; US20230336522A1; AU2021331195A1; US20220070140A1

Abstract

Netzwerkgeräte, die inline in Netzwerkverbindungen eingefügt sind und im Transit befindliche Pakete verarbeiten, können ihre Paketdurchsatzleistung erheblich verbessern, indem sie ihren Netzwerkschnittstellen keine L3-IP-Adressen und L2-MAC-Adressen zuweisen und dadurch Pakete über einen logischen Fast Path verarbeiten, der den Slow Path durch den Betriebssystemkernel umgeht. Bei der Virtualisierung solcher Bump-In-The-Wire (BITW)-Geräte für den Einsatz in Clouds müssen den Netzwerkschnittstellen L3-IP- und L2-MAC-Adressen zugewiesen werden. Daher werden Pakete über den Slow Path eines virtuellen BITW-Geräts verarbeitet, was die Leistung erheblich verringert. Durch Hinzufügen einer neuen Logik zum virtuellen BITW-Gerät und/oder durch Konfigurieren von Proxys, Adressen, Teilnetzen und/oder Routing-Tabellen kann ein virtuelles BITW-Gerät Pakete über den Fast Path verarbeiten und entsprechend die Leistung potenziell verbessern. Beispielsweise kann das virtuelle BITW-Gerät so konfiguriert sein, dass es einen virtuellen Pfad (umfassend den Fast Path) durch das virtuelle BITW-Gerät durchsetzt.

Description

QUERVERWEIS AUF VERWANDTE ANMELDUNGEN
Die vorliegende Anmeldung beansprucht die Priorität der US-Patentanmeldung mit der Seriennummer 17/395,120 , eingereicht am 5. August 2021, die eine Priorität der provisorischen US-Patentanmeldung mit der Seriennummer Nr. 63/071,174 beansprucht, eingereicht am 27. August 2020, die hiermit in ihrer Gesamtheit durch Verweis einbezogen werden.
HINTERGRUND
TCP/IP (Transmission Control Protocol/Internet Protocol)-Netzwerke, wie z. B. das öffentliche Internet, sind die Grundlage für das moderne Informationszeitalter. Die TCP/IP-Protokollsuite ermöglicht die Datenkommunikation zwischen Endpunkt-Host-Computern, indem sie festlegt, wie Daten paketiert, adressiert, übertragen, geroutet und empfangen werden sollen. Die TCP/IP-Protokollsuite besteht aus fünf Schichten: der Bitübertragungsschicht (Physical Layer; Schicht 1 oder L1), der Sicherungsschicht (Data Link Layer; L2), der Vermittlungsschicht (Network Layer; L3), der Transportschicht (Transport Layer; L4) und der Anwendungsschicht (Application Layer). Von besonderer Bedeutung für die vorliegende Offenbarung sind die Schicht 3 (L3)-Protokolle (z. B. das Internetprotokoll (IP), wie IPv4 und IPv6), die von Netzwerkknoten/Hosts wie beispielsweise Routern verwendet werden, um Pakete effizient an ihre Ziele (z. B. Endpunkte/Host-Computer) zu leiten, sowie die Schicht 2 (L2)-Protokolle der Sicherungsschicht (z. B. Ethernet 802.3, Media Access Control (MAC)-Adressierung, Address Resolution Protocol (ARP), Neighbor Discovery Protocol (NDP) usw.), die zur effizienten Übertragung von Paketen über die Verbindungen zwischen den Netzknoten/Hosts verwendet werden.
Viele Organisationen betreiben private TCP/IP-Netze, um ihren Geschäftsbetrieb zu unterstützen und anderen vernetzten Organisationen und Verbrauchern Computerdienste und Ressourcen zur Verfügung zu stellen. Diese privaten Netze sind durch das Internet miteinander verbunden, das es verschiedenen Organisationen ermöglicht, auf die Computerdienste und Ressourcen der anderen zuzugreifen. Diese Computer werden anhand von IP-Adressen adressiert oder identifiziert, die Teil des öffentlichen IP-Adressraums/-satzes des Internets sind. Private Netze werden oft unabhängig vom Internet betrieben/verwaltet und verwenden einen privaten IP-Adressraum/-satz, der sich vom öffentlichen IP-Adressraum/-satz des Internets unterscheidet, d. h. die Schnittmenge ist die leere Menge. Wenn also eine Organisation, die ein privates Netz betreibt, möchte, dass ihre Computer/Hosts auf Internet-Hosts zugreifen oder von Internet-Hosts angesprochen werden können, dann muss die Organisation ein Network Address Translation (NAT)-Gateway (bzw. auf Deutsch Netzwerkadressübersetzungsgateway) betreiben, das sich an der Grenze zwischen dem privaten Netz und dem Internet befindet. Das NAT-Gateway fungiert als Schnittstelle zwischen dem IP-Adressraum des Internets und dem IP-Adressraum des privaten Netzes, d. h., das NAT-Gateway übersetzt zwischen IP-Adressen des Internets und IP-Adressen des privaten Netzes. Wenn also eine Organisation einen an ihr privates Netz angeschlossenen Host-Computer vom Internet aus zugänglich/adressierbar machen will, z. B. eine Unternehmenswebsite, dann muss der Host-Computer sowohl einer privaten IP-Adresse als auch einer öffentlichen IP-Adresse zugeordnet sein. Das NAT-Gateway ist so konfiguriert, dass es zwischen der privaten IP-Adresse des Host-Computers und seiner öffentlichen IP-Adresse übersetzt. Diese Zuordnungen können statisch und permanent oder dynamisch und ephemer sein.
1A zeigt ein Beispiel für eine Netzwerkumgebung 100, in der ein (physisches oder nicht virtuelles) privates Netzwerk 104, das von einem Unternehmen betrieben/verwaltet wird, mit einem öffentlichen Netzwerk 102 (z. B. dem Internet) verknüpft ist. Das Unternehmen kann den Netzwerkschnittstellen seiner Host-Computer, Router und/oder anderer Geräte private IP-Adressen zuweisen, z. B. aus dem privaten IPv4-Adressraum 10.0.0.0/8. Ein internes Routing-Protokoll (z. B. OSPF (Open Shortest Path First)) kann von dem Unternehmen verwendet werden, um eine Routing-Richtlinie zu definieren, die einen Netzwerkpfad 108 zwischen zwei beliebigen privaten IP-Adressen bestimmt, die dem privaten Netzwerk 104 zugeordnet sind. Das Unternehmen kann über ein NAT (Network Address Translation)-Gateway (NAT-G/W) 120 sein privates Netz (das einen privaten IP-Adressraum verwenden kann) mit dem Internet (das einen öffentlichen IP-Adressraum verwenden kann) verknüpfen. Die NAT-Gateway-Funktion kann in einem oder mehreren Netzwerk-Edge-Geräten wie Netzwerk-Firewalls und Edge-Routern enthalten sein, die in dem Diagramm nicht dargestellt sind. Das NAT-G/W 120 kann dem Unternehmen zugewiesene öffentliche Internet-IP-Adressen in private IP-Adressen übersetzen. Auf diese Weise können interne Hosts, die mit dem privaten Netz verbunden sind, mit Internet-Hosts kommunizieren und umgekehrt. Beispielsweise kann der Internet Service Provider (ISP) des Unternehmens dem Unternehmen einen öffentlichen Internet (IPv4)-Adressblock (z. B. 174.129.20.0/24) zur Verfügung stellen. Das Unternehmen kann z.B. den Adressblock 174.129.20.0/24 einer dem Internet zugewandten Netzwerkschnittstelle N1 121 seines NAT-G/W 120 und z. B. die private IP-Adresse 10.0.1.1 einer einem privaten Netzwerk zugewandten Netzwerkschnittstelle N2 122 des NAT-G/W 120 zuweisen.
Das Unternehmen kann das NAT-G/W 120 auch so konfigurieren, dass es eine öffentliche IP-Adresse (z. B. 174.129.20.63) auf eine private IP-Adresse (z. B. 10.0.2.157) abbildet, die einem (physischen oder nicht virtuellen) Computer 160 zugewiesen ist. Die öffentliche IP-Adresse des Computers 160 wäre in diesem Beispiel somit 174.129.20.63. Die Routing-Richtlinie und die zugehörige Konfiguration für das private Netz 104 können den Pfad 108 durch das private Netz 104 für vom Computer 160 stammende oder für ihn bestimmte Pakete, die das NAT-G/W 120 passieren (d. h. Pakete, die für Internet-Hosts bestimmt sind oder von ihnen stammen), bestimmen. Der Pfad 108 kann beispielsweise eine einzelne physische Verbindung/Kabel sein, die eine Netzwerkschnittstelle des NAT-G/W 120 mit einer Netzwerkschnittstelle des Computers 160 verbindet, oder beispielsweise mehrere physische Verbindungen, die einen oder mehrere Router und/oder Switches (Knoten) verbinden, die sich auf dem Netzwerkpfad befinden. Mit dieser Konfiguration kann beispielsweise ein an das öffentliche Netz 102 angeschlossener Computer-HOST- -0 110 über die Übertragung von L3/IP-Paketen durch das Internet mit 174.129.20.63 als Quell- oder Ziel-IP-Adresse bidirektional mit dem an das private Netz 104 angeschlossenen Computer 160 kommunizieren.
Das Unternehmen kann zwischengeschaltete Geräte einsetzen, die „inline“ in physische Verbindungen (z. B. Kupfer- und optische Kabel), die die Netzwerkschnittstellen von Netzwerkknoten (z. B. Router, Switches, Host-Computer usw.) verbinden, eingefügt werden und im Transit befindliche Pakete in Übereinstimmung mit dem Inhalt der Pakete und/oder mit der Anwendungslogik des zwischengeschalteten Geräts prüfen und verarbeiten können. Als solche können diese Geräte als In-Transit-Paketverarbeitungsgeräte bezeichnet werden. Diese zwischengeschalteten Paketverarbeitungsgeräte können Datenkommunikationsrichtlinien (z. B. Netzwerksicherheitsrichtlinien, Netzwerkzugangskontrollrichtlinien, Netzwerkanwendungsnutzungsrichtlinien, Netzwerkadressübersetzungsrichtlinien usw.) durchsetzen, wie sie vom Eigentümer/Betreiber/Administrator (z. B. dem Unternehmen) des privaten Netzwerks definiert wurden. Um die Richtlinien für bestimmte Kommunikationen durchzusetzen, kann der Netzwerkadministrator die Standorte der zwischengeschalteten Paketverarbeitungsgeräte (z. B. festlegen, in welche Verbindungen die zwischengeschalteten Paketverarbeitungsgeräte eingefügt werden sollen), die Netzwerkkonfigurationen und/oder die Routing-Richtlinien so koordinieren, dass die Pakete der bestimmten Kommunikationen immer (in eine oder beide Richtungen) durch die zwischengeschalteten Paketverarbeitungsgeräte laufen. Da diese Richtlinien auf Kommunikationen zwischen internen Hosts (die mit dem privaten Netz verbunden sind, z. B. Computer 160) und Hosts des öffentlichen Netzes (z. B. Internet) angewandt werden können, können sich die Geräte an oder in der Nähe der Grenzen zwischen dem privaten Netz und dem öffentlichen Netz befinden. Z. B. können die Geräte in Zugangsverbindungen zum öffentlichen Netz eingefügt werden. Beispiele für diese Geräte sind Netzwerk-Firewalls, Netzwerkzugriffskontrollgeräte, Web-Proxys, TLS-Proxys, Paketsicherheits-Gateways, Threat Intelligence Gateways, IPsec-Gateways und dergleichen. Ebenso können sich die Geräte zwischen den Grenzen beliebiger unterschiedlicher Netze (z. B. nicht nur zwischen einem privaten und einem öffentlichen Netz) und/oder zwischen den Grenzen von Teilnetzen und/oder Segmenten innerhalb eines Netzes befinden, z. B. an Konzentrationspunkten und Lastverteilungspunkten.
Unter Bezugnahme auf 1B: Bei der Konfiguration eines zwischengeschalteten Paketverarbeitungsnetzwerkgeräts C 140 für den Inline-Betrieb/ das Inline-Einfügen in eine Verbindung auf einem Pfad 108 zwischen zwei Netzwerkelementen A (z. B. NAT-G/W 120) und B (z. B. Computer 160) kann eine physische Verbindung (z. B., ein Kupfer- oder optisches Kabel und/oder eine physische drahtlose Verbindung), die den gesamten Pfad 108 oder einen Teil davon bilden kann, physisch in zwei Verbindungen unterteilt werden, wobei eine Verbindung einen Netzwerkschnittstellenport von Element A mit einem Netzwerkschnittstellenport C1 141 des Geräts C 140 verbindet, und die andere Verbindung einen Netzwerkschnittstellenport von Element B mit einem Netzwerkschnittstellenport C2 142 des Geräts C 140 verbindet. Die Netzwerkschnittstellen C1 und C2 des Geräts C können durch eine interne logische Verbindung verbunden sein, die durch die Anwendungslogik des Geräts (z. B. Paketfilterung und/oder zugehörige Logik zur Durchsetzung von Richtlinien) definiert ist. Beispielsweise kann ein sich im Transit befindliches Paket, das in C1 (oder C2) eintritt, von der Anwendungslogik des Geräts C verarbeitet werden, und dann, sofern die Logik entscheidet, das Paket nicht zu verwerfen, kann das Paket das Gerät C über C2 (oder C1) verlassen.
In einigen Szenarien können die Netzwerkschnittstellen der Netzwerkgeräte L3-/ Vermittlungsschicht- (z. B. IPv4) und L2-Sicherungsschicht- (z. B. MAC-) Adressen haben, die ihnen zugeordnet sind. In solchen Beispielen werden die Schnittstellen und Geräte als nicht-transparent beschrieben. Nicht-transparente Geräte können Schnittstellen haben, die direkt adressiert werden können und an der Festlegung von (L3) Routing-Richtlinien und Konfigurationen über Routing-Protokolle (z. B. OSPF) und (L2) Switching & Weiterleitung und Link-Layer-Discovery-Protokolle (z. B. ARP, NDP) teilnehmen können. Im Hinblick auf die Durchsetzung von Kommunikationsrichtlinien, beispielsweise zur Durchsetzung von Web-Nutzungs- und Web-Sicherheitsrichtlinien, kann das Unternehmen seine Netzwerke (z. B. privates Netzwerk 104), Geräte und Anwendungen so konfigurieren, dass bestimmter (oder der gesamte) ausgehende(r) Web (d. h. HTTP/HTTPS-)-Verkehr über einen nicht-transparenten Web-Proxy geroutet werden muss und/oder so, dass die Netzwerk-Firewall nur ausgehenden Web-Verkehr von dem nicht-transparenten Web-Proxy zulässt. Eine solche Konfiguration kann beinhalten, dass den Netzwerkschnittstellen des Web-Proxys (L3-)IP-Adressen zugewiesen bzw. sie mit diesen identifiziert werden. Allgemeiner ausgedrückt: Wenn Netzwerkadministratoren Netzwerkkommunikationsrichtlinien definieren, die erfordern, dass bestimmte Kommunikationsvorgänge über Paketverarbeitungsgeräte mit IP-adressierbaren Netzwerkschnittstellen geleitet werden, müssen die Administratoren sicherstellen, dass das Netzwerk und Routing-Richtlinien/Routing-Tabellen ordnungsgemäß konfiguriert sind, um die Anforderung zu erfüllen. Änderungen am Netz und/oder der Routing-Richtlinie können möglicherweise zu Änderungen im Routing führen, so dass die Anforderung nicht erfüllt wird; daher müssen Administratoren, wenn sie solche Änderungen vornehmen, möglicherweise Maßnahmen ergreifen, um sicherzustellen, dass die Anforderungen weiterhin erfüllt werden.
In anderen Szenarien haben die Netzwerkgeräte möglicherweise keine L3-/ Vermittlungsschicht- (z. B. IPv4, IPv6) und L2-Sicherungsschicht- (z. B. MAC-) Adressen, die ihnen zugeordnet sind. Diese Konfiguration kann z. B. in Inline-Netzwerkgeräten verwendet werden, die Pakete, die sich im Transit befinden, verarbeiten, z. B. in Paketfiltergeräten. In solchen Beispielen werden die Schnittstellen und Geräte als (L3- und L2)-transparent beschrieben, weil die Geräte von anderen Netzwerkelementen und Protokollen, die auf L3 oder L2 arbeiten, nicht „gesehen“ oder beobachtet werden können. Fachleute bezeichnen ein solches transparentes Inline-Gerät auch als „Bump in the Wire“ (BITW). Ein Grund dafür ist, dass Frames/Pakete, die ein BITW-Gerät durchlaufen, auf L2 oder L3 nicht modifiziert werden (z. B. werden keine Änderungen an MAC- oder IP-Adressen oder anderen Header-Feldern vorgenommen) und oft auf überhaupt keiner Schicht modifiziert werden.
Aus dieser transparenten Konfiguration eines BITW-Geräts ergeben sich mehrere potenzielle Vorteile und Effizienzgewinne. Zum Beispiel kann die Leistung (gemessen am Paketdurchsatz des Geräts) aus mehreren Gründen verbessert werden. Ein Grund ist, dass ausgehende Frames/Pakete nicht auf Routing- und Weiterleitungstabellen zugreifen müssen, z. B. über einen Aufruf des Betriebssystem-Kernels, um z. B. die Ziel-MAC-Adresse für den L2-Frame zu ermitteln. Ein weiterer Grund ist, dass nicht-transparente Paketverarbeitungsgeräte die relativ langsame TCP/IP-Netzwerkstack-Logik verwenden können, die vom Kernel des Betriebssystems (z. B. Linux) der Geräte bereitgestellt wird, um im Transit befindliche Pakete zu verarbeiten und an L3-Routing- und L2-Switching/ Weiterleitungsprotokollen teilzunehmen; transparente Geräte hingegen können den TCP/IP-Netzwerkstack des OS-Kernels umgehen und eine viel schnellere Paketverarbeitungslogik verwenden, die direkt auf die Netzwerkschnittstellen-Controller (NICs) zugreift, z. B. das Data Plane Development Kit (DPDK). Schnelle Paketverarbeitungslogikmodule wie DPDK können möglicherweise Funktionen, die L3/IP-Paketheader ändern (z. B. Proxy-Funktionen, die Quell- oder Ziel-IP-Adresswerte von Paketen ändern) oder L2/Ethernet-Frames (z. B. Linkweiterleitungsfunktionen, die Quell- oder Ziel-MAC-Adresswerte ändern) nicht nativ unterstützen. Wenn solche Funktionen für eine bestimmte Anwendung benötigt werden, kann die Anwendung, z. B. über Aufrufe des TCP/IP-Netzwerkstacks des OS, auf diese zugreifen; dieser Ansatz kann jedoch die Paketverarbeitungsleistung der Anwendung beeinträchtigen.
Fachleute bezeichnen eine OS-Bypass-Architektur/Implementierung oft als „Fast Path“ („schnellen Pfad“) (im Gegensatz zum „Slow Path“ bzw. „langsamen Pfad“ durch den OS-Kernel) und gehen davon aus, dass das zugehörige BITW-Gerät nur minimale Latenzzeiten verursacht und keine Pakete verwirft (z. B. aufgrund von Pufferüberläufen infolge großer Latenzzeiten). Wie bei nicht-transparenten Geräten müssen Netzwerkadministratoren, wenn sie Netzwerkkommunikationsrichtlinien definieren, die erfordern, dass bestimmte Kommunikationsvorgänge durch solche transparenten Geräte geleitet werden, sicherstellen, dass das Netzwerk und Routing-Richtlinien ordnungsgemäß konfiguriert sind, um die Anforderung zu erfüllen. Da jedoch die Netzwerkschnittstellen der transparenten Geräte keine IP-Adressen haben, können Administratoren keine Routing-Richtlinien verwenden, um bestimmte Pakete an die Schnittstellen zu leiten, sondern müssen stattdessen indirekte Methoden verwenden, um sicherzustellen, dass Anforderungen erfüllt sind. Dementsprechend, und ähnlich wie im Fall des nicht transparenten Geräts, können Änderungen am Netzwerk und/oder der Routing-Richtlinie potenziell zu Änderungen im Routing führen, so dass die Anforderung nicht erfüllt ist; daher müssen Administratoren, wenn sie solche Änderungen vornehmen, möglicherweise Maßnahmen ergreifen, um sicherzustellen, dass solche Anforderungen weiterhin erfüllt werden, was schwieriger zu bewerkstelligen sein kann als im Fall des nicht transparenten Geräts (weil z. B. nur indirekte vs. direkte Routing-Methoden verwendet werden können).
Die Effizienzgewinne von Cloud-Computing-Plattformen und -Diensten (z. B. Amazon Web Services, Microsoft Azure, Google Cloud usw.) hat viele Organisationen dazu veranlasst, Teile ihrer physischen privaten Netzwerke in virtuelle Private Clouds zu migrieren oder zu virtualisieren. Bei der Bereitstellung von Inline-Netzwerkgeräten, z. B. Inline-Paketfiltergeräten, in einer virtuellen privaten Cloud-Umgebung, die einen Dienst wie Amazon Virtual Private Cloud (VPC) nutzt, müssen den Netzwerkschnittstellen der Geräte (private) IP-Adressen zugewiesen werden, und die Netzwerkschnittstellen der Geräte können nicht länger transparent bleiben. Während eine Verbindung zu einem Netzwerkschnittstellenport eines physischen Geräts über eine physische Verbindung, z. B. ein Ethernet-Kabel, hergestellt werden kann, ist eine solche physische Verbindung in einer virtuellen Umgebung nicht möglich. Bei der Abbildung solcher physischen Verbindungen auf eine virtuelle Cloud-Umgebung müssen die Verbindungen über L3-Routing und die zugehörige Routing-Richtlinie emuliert/virtualisiert werden.
2A zeigt eine beispielhafte Netzwerkumgebung 200, in der eine virtuelle Private Cloud 204 - die z. B. von einem Unternehmen an der Spitze einer Infrastructure-as-a-Service (IaaS)-Plattform konfiguriert wurde, die vom Unternehmen selbst oder von einem IaaS-Anbieter (z. B. Amazon, Microsoft, Google usw.) gehostet werden kann - eine Schnittstelle zum öffentlichen Netzwerk 102 hat. Die virtuelle Private Cloud 204 kann eine virtualisierte Version des physischen privaten Netzwerks 104 in 1A sein. Eine virtuelle NAT-G/W 220-Funktion, die von der IaaS-Plattform zur Verfügung gestellt/bereitgestellt werden kann, kann öffentliche Adressen (z. B. Internetadressen), z. B. 174.129.20.63, auf private IP-Adressen virtueller Computer abbilden, wie z. B. 10.0.2.157 für den virtuellen Computer 260.
Das Routing-Protokoll und die zugehörige Routing-Richtlinie können auch den Netzwerkpfad zwischen dem virtuellen NAT-G/W 220 und dem virtuellen Computer 260 bestimmen, der in 2A durch den virtuellen Pfad 208 dargestellt ist. Die Routing-Protokolle und -Richtlinien für die virtuelle Private Cloud können vom Anbieter der IaaS-Plattform, z. B. einem laaS-Provider, und nicht zwangsläufig vom Abonnenten der Plattform (z. B. dem Unternehmen) verwaltet werden. Routing-Protokolle und -Richtlinien können sich unter verschiedenen IaaS-Anbietern unterscheiden; außerdem können IaaS-Anbieter den Abonnenten/Unternehmen, die die virtuellen privaten Cloud-Plattformen der IaaS-Anbieter nutzen, die Kontrolle über die Routing-Protokolle und -Richtlinien möglicherweise nicht verfügbar machen. Wenn ein Unternehmen beispielsweise erfordert, dass bestimmte Pakete einen bestimmten Pfad oder Teilpfad oder eine bestimmte Verbindung durch eine virtuelle Private Cloud durchlaufen, muss das Unternehmen die IP-Adressen der Cloud-Elemente konfigurieren und die Private Cloud so konfigurieren, dass ein bestimmter Pfad von bestimmten Paketen durchlaufen wird, beispielsweise indem es Teilnetze konfiguriert und indem es die Routing-Tabellen der Cloud (die IaaS-Anbieter verfügbar machen) ändert. Da das Unternehmen möglicherweise keine Kontrolle über die Routing-Richtlinien hat, kann es schwierig und problematisch sein, sicherzustellen, dass solche Anforderungen erfüllt werden, insbesondere wenn die Private Cloud dynamisch ist, z. B. wenn häufig Änderungen an der privaten Cloud vorgenommen werden, die die Routing-Konfigurationen verändern (was wahrscheinlich ist, weil einer der potenziellen Vorteile von Clouds darin besteht, dass Änderungen am Netzwerk, z. B. das dynamische Hinzufügen oder Entfernen von Servern aufgrund dynamischer Änderungen der Auslastung, im Vergleich zu physischen Netzwerken viel effizienter zu implementieren sind).
ZUSAMMENFASSUNG
Die folgenden Absätze stellen eine vereinfachte Zusammenfassung dar, um ein grundlegendes Verständnis einiger Aspekte der Offenbarung zu vermitteln. Sie sind weder dazu gedacht, wichtige oder kritische Elemente der Offenbarung zu identifizieren, noch den Umfang der Offenbarung abzugrenzen. In den folgenden Abschnitten werden lediglich, als Hinführung zur nachfolgenden Beschreibung, einige Konzepte der Offenbarung in vereinfachter Form dargestellt.
In Anbetracht der obigen Hintergrunddiskussion besteht ein Bedarf an Verfahren, Systemen und Logik, die die Virtualisierung von transparenten physischen BITW-Netzwerkgeräten und/oder die Bereitstellung der Geräte in dynamischen virtuellen privaten Cloud-Umgebungen unterstützen. Darüber hinaus besteht ein Bedarf, dies auf eine Weise zu tun, die (a) die Fast Path-Paketverarbeitung und die damit verbundene Paketdurchsatzleistung erhalten, (b) Richtlinien durchsetzt, um sicherzustellen, dass Pakete, die bestimmte/spezifizierte Kommunikationen umfassen, virtuelle Pfade durchlaufen, die durch die virtualisierten BITW-Geräte verlaufen, und/oder (c) unveränderlich gegenüber Unterschieden in Routing-Richtlinien über verschiedene virtuelle Private-Cloud-Plattformen hinweg ist.
Die hier beschriebenen Aspekte beziehen sich im Allgemeinen auf Computerhardware und - software für TCP/IP-Netzwerke und damit verbundene Verfahren. Zum Beispiel beziehen sich ein oder mehrere nicht-einschränkende Aspekte der Offenlegung im Allgemeinen auf Netzwerkgeräte, die eine paketierte Datenübertragung in einem Computernetzwerk vermitteln.
Beispielsweise beschreiben die hier offengelegten Verfahren, Vorrichtungen, Systeme und/oder computerlesbaren Medien Beispiele für Logik und Konfigurationen, die (1a) eine effiziente Virtualisierung von transparenten physischen Inline-In-Transit-Paketverarbeitungsnetzwerkgeräten und/oder (1b) eine effiziente Bereitstellung in einer virtuellen privaten Cloud-Umgebung unterstützen können; und/oder die (2a) die Paketverarbeitungsleistung der Geräte erhalten können und/oder (2b) Kommunikationsrichtlinien des Unternehmens durchsetzen können, wonach einige oder alle Pakete, die Kommunikationen zwischen einem oder mehreren Internet-Hosts und einem oder mehreren virtuellen Hosts, die mit der virtuellen privaten Cloud verbunden sind, umfassen, einen virtuellen Pfad durchlaufen, der eine virtuelle Verbindung zwischen den Netzwerkschnittstellen eines virtuellen Bump-in-the-Wire-Geräts (BITW) enthält. Diese Eigenschaften und Merkmale können unveränderlich gegenüber Unterschieden oder Änderungen in den Routing-Richtlinien sein, die über verschiedene virtuelle Private-Cloud-Plattformen hinweg auftreten können. Der Einfachheit halber kann der Begriff „virtuelles BITW-Gerät“ hier verwendet werden, um virtualisierte Versionen physischer BITW-Geräte zu bezeichnen, z. B. transparente physische Inline-In-Transit-Fast Path-Paketverarbeitungsnetzwerkgeräte, die virtualisiert und in einer Cloud bereitgestellt wurden.
Werden Netzwerkschnittstellen dieser virtuellen BITW-Geräte in der Cloud virtualisiert und bereitgestellt, können ihnen (L3)-private IP-Adressen und (L2)-MAC-Adressen zugewiesen werden, die mit der effizienten Network-Address-Mapping (NAM)-Logik (bzw. auf Deutsch Netzwerk-Adresszuordnungs-Logik) der Geräte und den Routing-Tabellen der Cloud verbunden sind, um gewünschte L3-Proxy-Funktionen und L3/L2-Routing- und Weiterleitungsfunktionen durchzuführen. Die virtualisierten Geräte können im Transit befindliche Pakete unter Verwendung der gleichen oder einer ähnlichen Fast Path-Paketverarbeitungs- (FPPP, für Fast Path Packet Processing) Logik (z. B. Data Plane Development Kit (DPDK)) verarbeiten, wie die von den physischen Versionen der BITW-Geräte verwendete, und dabei die TCP/IP-Netzwerkstack-Logik des Slow-Path-Betriebssystems umgehen.
Ein virtueller Host-Computer, der mit einer virtuellen privaten Cloud verbunden ist, kann durch seine (private) IP-Adresse identifiziert werden und kann mit einer Richtlinie verbunden sein, wonach bestimmte oder alle im Transit befindlichen Pakete, die Kommunikation zwischen dem virtuellen Host-Computer und Internet-Hosts umfassen, ein virtuelles BITW-Gerät durchlaufen müssen, das in einem virtuellen Pfad in der Cloud zwischen dem virtuellen Host-Computer und der Internet-Schnittstelle der Cloud eingesetzt wird, z. B. ein NAT- (Network-Address-Translation) Gateway. Die IP-Adressen und zugehörigen Teilnetze des virtuellen BITW-Geräts, des virtuellen Host-Computers und des NAT-Gateways können so konfiguriert sein, dass Kommunikationen zwischen dem Internet und dem virtuellen Host-Computer den virtuellen Pfad durchlaufen und durch das virtuelle BITW-Gerät laufen. Eine dem Internet zugewandte Netzwerkschnittstelle des virtuellen BITW-Geräts kann als ein IP-Adressen-Proxy für den virtuellen Host-Computer identifiziert werden. Ein NAT-Gateway, das eine Schnittstelle zwischen dem Internet und der privaten Cloud bildet und nativ zwischen der Internetadresse des virtuellen Host-Computers und seiner privaten IP-Adresse übersetzt, kann so umkonfiguriert werden, dass es die Internetadresse des virtuellen Host-Computers in die Proxy-Adresse übersetzt. Pakete, die von einem Internet-Host stammen und für den virtuellen Host-Computer bestimmt sind, können (von der Cloud) vom NAT-Gateway an die Proxy-Netzwerkschnittstelle des virtuellen BITW-Geräts geroutet werden. Nach dem Empfang eines Pakets an der Proxy-Schnittstelle kann die NAM-Logik des Geräts die L3-Zieladresse und die L2-MAC-Adressen des Pakets so ändern, dass, nachdem das Gerät das Paket über die Fast Path-Logik verarbeitet hat und das Paket aus der dem virtuellen Host zugewandten Netzwerkschnittstelle des Geräts weitergeleitet hat, das Paket an den virtuellen Host-Computer geroutet wird. In ähnlicher Weise können Pakete, die vom virtuellen Host-Computer stammen und für einen Internet-Host bestimmt sind, an die dem virtuellen Host zugewandte Netzwerkschnittstelle des Geräts geleitet und von dieser empfangen werden, von der NAM-Logik modifiziert werden, durch die Fast Path-Logik des Geräts verarbeitet werden, aus der Proxy-Schnittstelle weitergeleitet werden und an das NAT-Gateway geroutet werden, das eine Adressübersetzung durchführen und das Paket an den Internet-Host weiterleiten kann.
Weitere hier offengelegte Aspekte beziehen sich auf das Konfigurieren eines virtuellen BITW-Geräts zur Verarbeitung von Paketen über einen Fast Path (schnellen Pfad) des virtuellen BITW-Geräts.
Weitere hier offengelegte Aspekte beziehen sich auf das Konfigurieren eines Proxys, einer Adresse, eines Teilnetzes und/oder einer Routing-Tabelle eines virtuellen BITW-Geräts, zur Sicherstellung, dass Pakete einen virtuellen Pfad durch eine Cloud durchlaufen, wobei der virtuelle Pfad einen Fast Path (schnellen Pfad) durch das virtuelle BITW-Gerät umfasst.
Weitere hier offengelegte Aspekte betreffen die Bereitstellung eines virtuellen BITW-Geräts in einem virtuellen Pfad; die Zuweisung von IP-Adressen an Netzwerkschnittstellen, die Teilnetzen von Virtueller-Pfad-Endgeräten („virtual path terminals“) entsprechen; das Konfigurieren einer NAM-Logik (1) mit IP- und/oder MAC-Adressen von Endgeräten und/oder Schnittstellen und/oder (2) mit Proxy-Informationen; das Konfigurieren eines NAT-Gateways, um mindestens eine öffentliche IP-Adresse in eine private IP-Adresse zu übersetzen, die dem virtuellen BITW-Gerät zugeordnet ist; und die Bereitstellung mindestens einer Cloud-Routing-Tabelle, die so konfiguriert ist, dass sie ein Outbound-Virtual-Path-Routing (virtuelles Pfad-Routing für ausgehenden Datenverkehr) durch das virtuelle BITW-Gerät und das NAT-Gateway bewirkt (durchsetzt).
Es gibt viele mögliche Varianten und Erweiterungen zu den obigen Aspekten, einschließlich beispielsweise des Falles mehrerer virtueller Host-Computer, von denen einige im Folgenden beispielhaft beschrieben werden.
Die Merkmale der Offenbarung werden bei der Durchsicht dieser Offenbarung in ihrer Gesamtheit, einschließlich der beigefügten Zeichnungen, deutlicher.
Figurenliste
Einige der hierin enthaltenen Merkmale sind beispielhaft und nicht einschränkend in den Figuren der beigefügten Zeichnungen dargestellt, in denen sich gleiche Bezugszeichen auf gleiche bzw. ähnliche Elemente beziehen, und wobei:

1A und 1B illustrative Netzwerkumgebungen für physische private Netzwerke mit physischen Inline-BITW-Geräten darstellen;
2A und 2B illustrative Netzwerkumgebungen für virtuelle Private Clouds mit virtuellen BITW-Geräten zeigen;
3 ein beispielhaftes Blockdiagramm eines Prozesses der Bereitstellung, Konfigurierung und des Betriebs eines virtuellen BITW-Geräts in einer privaten Cloud zeigt;
4 eine beispielhafte Architektur eines virtuellen BITW-Geräts zeigt;
5 ein beispielhaftes Leiterdiagramm von Paketkommunikationen zwischen einem Internet-Host und einem mit einer privaten Cloud verbundenen virtuellen Host-Computer, die ein virtuelles BITW-Gerät durchlaufen, zeigt.
6 ein Beispiel für ein Computergerät zeigt, das zur Implementierung der hier beschriebenen Vorrichtungen, Systeme und Verfahren verwendet werden kann.

DETAILLIERTE BESCHREIBUNG
In der folgenden Beschreibung verschiedener illustrativer Ausführungsformen wird auf die beigefügten Zeichnungen Bezug genommen, die einen Teil dieses Dokuments bilden und in denen zur Veranschaulichung verschiedene Ausführungsformen gezeigt werden, in denen Aspekte der Offenbarung ausgeführt werden können. Es versteht sich, dass auch andere Ausführungsformen verwendet und strukturelle und funktionelle Änderungen vorgenommen werden können, ohne vom Schutzbereich der Offenbarung abzuweichen. Darüber hinaus wird auf bestimmte Anwendungen, Protokolle und Ausführungsformen verwiesen, in denen Aspekte der Offenbarung ausgeführt werden können. Es versteht sich, dass auch andere Anwendungen, Protokolle und Ausführungsformen verwendet und strukturelle und funktionelle Änderungen vorgenommen werden können, ohne vom Schutzbereich der Offenbarung abzuweichen. Es ist klarzustellen, dass, obwohl in den Beschreibungen, Abbildungen und Beispielen auf das IPv4-Protokoll Bezug genommen wird, auf das IPv6-Protokoll und andere Protokolle in ähnlicher Weise Bezug genommen werden kann.
In der folgenden Beschreibung werden verschiedene Verbindungen zwischen Elementen erörtert. Diese Verbindungen sind allgemein gehalten und können, sofern nicht anders angegeben, in beliebiger Kombination, direkt oder indirekt, verdrahtet oder drahtlos, physisch oder logisch (z. B. virtuell oder softwaredefiniert) sein. In dieser Hinsicht ist die Beschreibung nicht als einschränkend zu verstehen.
Wie in 2B gezeigt, können, wenn ein angemeldetes Unternehmen oder eine andere Einheit, wie z. B. ein Private-Cloud-Betreiber, eine virtualisierte Version eines physischen BITW-Geräts C 240 (ein virtuelles BITW) in den virtuellen Pfad 208 einfügt, um im Transit befindliche Pakete zu verarbeiten, den Netzwerkschnittstellen C1 241 und C2 242 des Geräts C (L3)-IP-Adressen zugewiesen sein, so dass die zugrunde liegende Private-Cloud-Plattform das Gerät nicht nur erkennt, sondern auch potenziell Pakete durch das Gerät routen kann. Wenn jedoch das Unternehmen eine Richtlinie definiert, die beispielsweise erfordert, dass alle Pakete, die Kommunikationen zwischen dem Computer 260 und beliebigen Internet-Hosts umfassen, über das Gerät C 240 laufen, kann das Unternehmen die Richtlinie möglicherweise nicht direkt durchsetzen, da es möglicherweise das Routing nicht kontrollieren kann. Beispielsweise kann das Routing-Protokoll entscheiden, dass der beste Pfad (in 2B nicht gezeigt) zwischen NAT-G/W 220 und Computer 260 nicht durch Gerät C 240 führt. Das Unternehmen kann Maßnahmen ergreifen, um das Routing-Protokoll möglicherweise dazu zu bringen, bestimmte Pakete durch das Gerät C 240 zu routen; zum Beispiel kann das Unternehmen erfordern, dass die jeweiligen IP-Adressen der Schnittstellen C1 und C2 verschiedenen, sich nicht überlappenden Teilnetzen zugeordnet sind, um die Wahrscheinlichkeit des gewünschten Routings zu erhöhen. In 2B kann beispielsweise der Schnittstelle C1 die 10.0.1.6 im Teilnetz 10.0.1.0/24 zugewiesen werden, während der Schnittstelle C2 die 10.0.2.7 im Teilnetz 10.0.2.0/24, das sich nicht mit dem der Schnittstelle C1 zugehörigen Teilnetz überlappt, zugewiesen werden kann. Solche Maßnahmen garantieren jedoch nicht das gewünschte Routing, da es beispielsweise einen Pfad (in 2B nicht dargestellt) zwischen dem Teilnetz 10.0.1.0/24 und dem Teilnetz 10.0.2.0/24 geben kann, der das Gerät C umgeht, oder weil das Routing beispielsweise bewirken kann, dass Pakete in der falschen Richtung durch das Gerät C geroutet werden. Selbst wenn das Routing durch Gerät C 240 wie gewünscht/erforderlich zu funktionieren scheint, kann jede weitere Änderung des Netzes, z. B. das Hinzufügen, Entfernen und/oder Ändern von Servern, Teilnetzen, IP-Adressen usw., zu einer Neukonfiguration des Routings führen, so dass das Routing von Paketen durch das Gerät C 240 nicht mehr den gewünschten Anforderungen des Unternehmens entspricht.
Ein Ansatz zur Unterstützung der Zuweisung von IP-Adressen und MAC-Adressen an Netzwerkschnittstellen von (transparenten physischen) BITW-Netzwerkgeräten - so dass die Geräte virtualisiert und in virtuellen privaten Clouds von IaaS-Anbietern bereitgestellt werden und am L3-Routing und an der L2-Weiterleitung teilnehmen können - ist der, zur Verwendung der (Slow Path-) TCP/IP-Netzwerkstack-Logik des Betriebssystems des Geräts zurückzukehren, um im Transit befindliche Pakete zu verarbeiten und Routing- und Weiterleitungsinformationen zu konfigurieren/bestimmen. Somit können die Leistungsgewinne beim Paketdurchsatz, die durch die Transparenz und die damit verbundene Fast Path-Paketverarbeitungslogik in einem physischen BITW-Gerät ermöglicht werden, zur Unterstützung der Virtualisierung des Geräts geopfert werden. Die Verwendung der TCP/IP-Netzwerkstack-Logik des Betriebssystems kann jedoch dazu führen, dass lokale Routing- und Weiterleitungsinformationen automatisch von den Routing- und Switchingprotokollen der Cloud-Plattform konfiguriert werden; wie bereits erwähnt, setzt dies jedoch nicht notwendigerweise irgendwelche Paket-Routing-Richtlinien/Anforderungen für die Cloud durch und kann zu weiteren Leistungseinbußen führen.
Wie weiter unten beschrieben wird, können die folgenden korrelierten Komponenten zur Unterstützung eines virtuellen BITW bereitgestellt werden: (1) eine Cloud-Konfigurationskomponente, die Adressierung (z. B. IP- und MAC-Adressierung), Adressübersetzung, Proxying (Kommunikations- bzw. Paketvermittlung), Subnetting und/oder Routing koordinieren kann; und (2) eine Network-Address-Mapping- (NAM) Logikkomponente, die in das virtuelle BITW-Gerätesystem eingefügt (z. B. mittels eines Shim) werden kann, wie etwa zwischen den Treibern des FPPP-Netzwerkschnittstellen-Controller (NIC) und der FPPP-Kernpaketverarbeitungslogik, die L3/IP-Adressen und L2/MAC-Adressen von eintretenden und/oder austretenden L3/L2-Paketen/Frames effizient auf Werte abbilden kann, die bewirken können, dass sie zu beabsichtigten Zielen entlang eines virtuellen Pfades geroutet/weitergeleitet werden.
Unter Bezug auf 3 soll zunächst ein Beispiel für eine Cloud-Konfigurationskomponente betrachtet werden, die aus einer der folgenden miteinander verbundenen Teilkomponenten bestehen kann:
Konfiguration des virtuellen BITW-Geräts und zugehöriger Teilnetze zu einem virtuellen Pfad;
Konfigurieren des NAT-Gateways und damit verbundenes Proxying; und
Konfigurieren von Cloud-Routing-Tabellen.
Es sei angemerkt, dass die Konfiguration der Teilkomponenten im Kontext und in Abstimmung mit der Infrastruktur des privaten Cloud-Anbieters erfolgen kann, die automatisch und/oder transparent Funktionen wie etwa Routing und Routing-Tabellen-Generierung, MAC-Adressgenerierung und -zuweisung usw. durchführen kann, deren Vorgänge hier nicht gezeigt oder beschrieben werden. Zu beachten ist auch, dass die beschriebenen Beispiele/Szenarien für den einfachen Fall eines virtuellen Inline-BITW-Geräts 240 gelten, das zwischen einem einzelnen virtuellen Host-Computer (z. B. Computer 260), einem einzelnen Internet-Gateway (z. B. NAT-G/W 220) und einem einzelnen Internet-Host (z. B. HOST-0 110) vermittelt. Die hier beschriebenen Methoden und Systeme können von Fachleuten ohne weiteres auf komplexere Szenarien mit mehreren virtuellen Hosts, Internet-Hosts, Gateways und virtuellen BITW-Geräten erweitert werden.
In 2A, die eine Beispielumgebung darstellt, bevor ein virtuelles BITW-Gerät eingesetzt wurde, kann das NAT-G/W 220 so konfiguriert sein, dass es zwischen öffentlichen IP-Adressen, die mit dem öffentlichen Netzwerk 102 (z. B. dem öffentlichen Internet) verbunden sind, und privaten IP-Adressen, die mit einer virtuellen Private Cloud 204 verbunden sind, übersetzt. Beispielsweise kann der virtuelle Computer 260 mit der öffentlichen IP-Adresse 174.129.20.63 und mit der privaten IP-Adresse 10.0.2.157 verbunden sein. Das NAT-G/W 220 ist demnach in 2A so dargestellt, dass er 174.129.20.63 nach/von 10.0.2.157 übersetzt. Das Routing-System des Cloud-Plattform-Anbieters (z. B. des IaaS-Anbieters) kann einen (bidirektionalen) Pfad 208 durch die virtuelle Private Cloud 104 zwischen der Netzwerkschnittstelle N2 222 (mit der IP-Adresse 10.0.1.1) des NAT-G/W 220 und dem Computer 260 (mit der IP-Adresse 10.0.2.157) bestimmen. Die IP-Adressen 10.0.1.1 und 10.0.2.157 und die zugehörigen Netzwerkschnittstellen stellen die Endgeräte des Pfades 208 dar.
Bezugnehmend auf 3, kann das virtuelle BITW-Gerät in Schritt 3-1 bereitgestellt, konfiguriert und in einem virtuellen Pfad eingesetzt werden. Jedes Endgerät („terminal“) des virtuellen Pfads kann ausschließlich mit einem Teilnetz und mit einer Netzwerkschnittstelle des virtuellen BITW-Geräts verbunden sein. Jeder solchen Netzwerkschnittstelle des virtuellen BITW-Geräts kann eine IP-Adresse zugewiesen sein, die sich im selben Teilnetz befindet wie ihr zugehöriges Pfadendgerät („path terminal“). Die NAM-Logik des virtuellen BITW-Geräts kann mit IP-Adressen und MAC-Adressen der Endgeräte des virtuellen Pfads und der Netzwerkschnittstellen des Geräts konfiguriert sein. Die NAM-Logik kann mit Informationen konfiguriert sein, um Pakete, die von der Proxy-Schnittstelle des virtuellen BITW-Geräts empfangen werden, dem/den virtuellen Host-Computer(n) oder virtuellen Pfad-Endgerät(en) zuzuordnen, die vom Proxy vermittelt werden.
Zum Beispiel kann, unter Bezugnahme auf 2B, wenn ein virtuelles BITW-Gerät C 240 inline in den Pfad 208 eingesetzt wird, die Netzwerkschnittstelle C1 241 mit einer IP-Adresse, zum Beispiel 10.0.1.6, konfiguriert sein, die sich im gleichen Teilnetz, zum Beispiel einem /24-Teilnetz, befindet wie die Netzwerkschnittstelle N2 222 von NAT-G/W 220, die eine IP-Adresse 10.0.1.1 hat und die ein Endgerät („terminal“) des Pfades 208 ist. C1 241 kann als die Proxy-Schnittstelle bestimmt werden, d.h. C1 241 mit der IP-Adresse 10.0.1.6 kann als IP-Adress-Proxy für den virtuellen Computer 260 (mit der IP-Adresse 10.0.2.157) dienen. Der Einfachheit halber können ein (oder mehrere) virtuelle Host-Computer, die über eine Netzwerkschnittstelle eines virtuellen BITW-Geräts vermittelt werden, als „Ziel(e)“ bezeichnet werden. Die NAM-Logik kann mit dieser Proxy-Information konfiguriert sein, die von der NAM-Logik verwendet werden kann, um die IP-Adressfeldwerte der im Transit befindlichen L3-Pakete von 10.0.1.6 auf 10.0.2.157 abzubilden/zu ändern. Gleichzeitig kann die Netzwerkschnittstelle C2 242 mit einer IP-Adresse, z. B. 10.0.2.7, konfiguriert sein, die sich im selben Teilnetz, z. B. einem /24-Teilnetz, befindet wie der virtuelle Zielcomputer 260 (mit der IP-Adresse 10.0.2.157, dem anderen Endpunkt des Pfads 208), aber wobei sich das Teilnetz, das C2 enthält, von dem Teilnetz, das C1 enthält, unterscheidet und sich nicht mit diesem überlappt. Nachdem den Netzwerkschnittstellen IP-Adressen zugewiesen wurden, kann die Cloud-Plattform MAC-Adressen generieren und den Schnittstellen zuweisen und die Routing-Tabellen der Cloud aktualisieren (z. B. unter Verwendung von OSPF und ARP), um das neu eingesetzte virtuelle BITW-Gerät 240 in die Routing-Konfiguration der Cloud einzubinden/zu integrieren. Die Cloud-Plattform kann Routing-Tabellen erstellen und aufrechterhalten, die mit jeder Netzwerkschnittstelle in der Cloud verknüpft sind und Routen zwischen den Netzwerkschnittstellen festlegen können. Nach dem Aktualisieren der Routing-Tabellen kann die NAM-Logik aus den Routing-Tabellen und dem Netzwerkstack eine beliebige der folgenden Informationen extrahieren: die IP- und MAC-Adresse des virtuellen Zielcomputers 260; die IP- und MAC-Adresse der Schnittstelle C1 241 (z. B. des Proxys für den virtuellen Zielcomputer 260); und/oder die MAC-Adresse der Netzwerkschnittstelle des NAT-G/W 220-Gateways, die sich im gleichen Teilnetz wie C1 241 befindet. Wie weiter unten beschrieben, kann diese Information von der NAM-Logik verwendet werden, um dabei zu helfen, sicherzustellen, dass bestimmte (oder alle) Pakete, die Kommunikationen zwischen Internet-Hosts und dem virtuellen Zielcomputer 260 umfassen, durch das virtuelle BITW-Gerät 240 laufen. Diese Information kann auch verwendet werden, um effizient auf Routing- und Weiterleitungsinformationen in Übereinstimmung mit der Fast Path-Paketverarbeitung zuzugreifen, auf die andernfalls über den Slow-Path (d. h. den TCP/IP-Netzwerkstack des Betriebssystems) zugegriffen werden kann.
Unter Bezugnahme auf 3 kann in Schritt 3-2 das NAT-Gateway, das die Private Cloud 204 mit dem öffentlichen Netz 102 verbindet durch Übersetzen zwischen den öffentlichen (z. B. Internet-) IP-Adressen und privaten (z. B. Cloud-) IP-Adressen virtueller Host-Computer neu konfiguriert werden, um die öffentlichen IP-Adressen der virtuellen Ziel-Host-Computer in die private IP-Adresse der Proxy-Schnittstelle des virtuellen BITW-Geräts zu übersetzen.
Unter Bezugnahme auf 2B kann beispielsweise das NAT-G/W 220 so konfiguriert sein, dass es 174.129.20.63, die öffentliche IP-Adresse vom Computer 260, in 10.0.1.6, die private IP-Adresse von C1 241, anstelle von 10.0.2.157, der privaten IP-Adresse vom Zielcomputer 260, übersetzt. Im Grunde hat das NAT-G/W 220 die Netzwerkschnittstelle C1 als Proxy für den Zielcomputer 260 bestimmt (und, wie oben erläutert, kann die NAM-Logik des virtuellen BITW ähnlich konfiguriert sein).
Unter Bezugnahme auf 3 können in Schritt 3-3 die Routing-Tabellen der Cloud-Plattform so modifiziert/konfiguriert/erweitert werden, dass ausgehende Pakete, die den virtuellen Pfad zwischen den Endgeräten des Pfades durchlaufen, z. B. Pakete, die von einem endseitigen virtuellen Computer („terminal virtual computer“) stammen/abgeleitet werden und für einen Internet-Host (oder einen anderen öffentlichen Netzwerkhost) über das NAT-Gateway bestimmt sind, von einem endseitigen virtuellen Computer zur Nicht-Proxy-Netzwerkschnittstelle des virtuellen BITW-Geräts und dann von der Proxy-Netzwerkschnittstelle des virtuellen BITW-Geräts zum NAT-Gateway, das die Private Cloud mit dem öffentlichen Netz verbindet, geleitet werden können. Insbesondere können die Routing-Tabellen so geändert werden, dass: (1) ausgehende Pakete, die das Teilnetz verlassen, das sowohl mit dem endseitigen virtuellen Computer als auch mit der Nicht-Proxy-Schnittstelle des virtuellen BITW-Geräts verbunden ist, in Richtung der Nicht-Proxy-Schnittstelle geleitet/weitergeleitet werden; und/oder (2) ausgehende Pakete, die das Teilnetz verlassen, das sowohl mit der Proxy-Schnittstelle des virtuellen BITW als auch mit der NAT-Gateway-Schnittstelle verbunden ist, in Richtung der NAT-Gateway-Schnittstelle geleitet/weitergeleitet werden.
Beispielsweise können, unter Bezugnahme auf 2B, die Erweiterungen der Routing-Tabellen der Cloud (1) einen Eintrag enthalten, der die Schnittstelle N2 222 des NAT-G/W 220, die die IP-Adresse 10.0.1.1 hat, als das Internet-Gateway für alle ausgehenden Pakete identifiziert, die das Teilnetz 10.0.1.0/24 verlassen. Man beachte, dass (1a) dieses Teilnetz 10.0.1.0/24 die Proxy-Schnittstelle C1 241 des virtuellen BITW-Geräts 240 umfasst und dass (1b) N2 222 ein Endgerät des virtuellen Pfads 208 ist. Somit kann dieser Eintrag dazu beitragen, die mit der Durchquerung des virtuellen Pfads 208 verbundenen Anforderungen durchzusetzen. Die Erweiterungen der Routing-Tabellen der Cloud können ferner (2) einen Eintrag in der Routing-Tabelle für die Schnittstelle C2 242 enthalten, der die Schnittstelle C2 242, mit der IP-Adresse 10.0.2.7, als Austrittspunkt für alle ausgehenden Pakete, die das Teilnetz 10.0.2.0/24 verlassen, identifiziert. Man beachte, dass (2a) dieses Teilnetz 10.0.2.0/24 den virtuellen Zielcomputer 260 (mit der IP-Adresse 10.0.2.157) umfasst und dass (2b) der virtuelle Computer 260 ein Endgerät des virtuellen Pfads 208 ist. Somit kann dieser Eintrag auch dazu beitragen, die mit der Durchquerung des virtuellen Pfades 208 verbundenen Anforderungen durchzusetzen.
Nach Abschluss der Schritte 3-1, 3-2 und 3-3 kann das virtuelle BITW-Gerät auf seinem virtuellen Pfad betriebsbereit sein; daher kann in Schritt 3-4 das virtuelle BITW in Betrieb genommen werden.
Man beachte, dass die Reihenfolge der Schritte 3-1, 3-2 und 3-3 und der zugehörigen Unterschritte beispielhaft ist und sich in der Praxis davon unterscheiden kann. Außerdem kann jeder dieser Schritte kombiniert und/oder weiter unterteilt werden.
Unter Bezugnahme auf 4, die ein Beispiel für die Logik-Architektur des virtuellen BITW-Geräts als Pipeline darstellt, wird als nächstes die NAM-Logikkomponente betrachtet. Die NAM kann zwischen den Treibern des FPPP-Netzwerkschnittstellen-Controllers (NIC) und der Fast Path-Paketverarbeitungs- (FPPP) Anwendungslogik eingefügt sein, wobei es sich bei der Anwendung beispielsweise um Netzwerk-Firewalling, Netzwerkzugangskontrolle, Web-Proxy, TLS-Proxy, Paketsicherheits-Gateway, Threat Intelligence Gateway, IPsec-Gateway und/oder Ähnliches handeln kann. Ein Zweck der NAM kann dadurch erklärt werden, dass er in einem virtuellen BITW-Gerät verwendet werden kann, nicht aber in einem physischen BITW-Gerät. Zum Beispiel kann sich eine Version von 4 für ein physisches BITW-Gerät von 4 (für das virtuelle BITW) zumindest durch die NAM-Logikkomponente unterscheiden.
Die NAM-Komponente kann eine oder mehrere Funktionen bereitstellen. Beispiele für diese Funktionen können sein:
NAM-Funktion 1: Für die Proxy-Netzwerkschnittstelle: ordnet zu zwischen der Proxy-IP-Adresse und den IP-Adressen des virtuellen Zielcomputers;
NAM-Funktion 2: konfiguriert die IP- und MAC-Adressen von im Transit befindlichen L3-Paketen und L2-Frames, um Richtlinien/Anforderungen für die Durchquerung des virtuellen Pfades durchzusetzen; und/oder
NAM-Funktion 3: hält eine effiziente Datenstruktur aufrecht, die durch Flussmerkmale der Pakete indiziert werden kann und Informationen enthält, die mit kürzlich beobachteten im Transit befindlichen Frames/Paketen verbunden sind, um Routing- und Weiterleitungsinformationen, die mit Paketen im gleichen Fluss verbunden sind, die während des Proxying verloren gegangen sein können, wiederherzustellen und schnell darauf zuzugreifen.
Alle drei (3) oben aufgeführten NAM-Funktionen resultieren aus dem Wunsch, den Netzwerkschnittstellen (C1 und C2 in 4) des virtuellen BITW-Geräts IP-Adressen und MAC-Adressen zuzuweisen, wohingegen die Netzwerkschnittstellen eines physischen BITW-Geräts per Definition L3- und L2-transparent sind und daher kein NAM erforderlich ist.
In Bezug auf die NAM-Funktion 1: Oben, zum Beispiel Schritt 3-1 von 3, wurde bereits gesagt, dass das Internet-Cloud-NAT-Gateway so konfiguriert sein kann, dass es die öffentliche(n) IP-Adresse(n) des/der virtuellen Zielcomputer(s) in die IP-Adresse der Proxy-Schnittstelle des virtuellen BITW-Geräts übersetzt. Dementsprechend kann, zum Beispiel in Schritt 3-1 von 3, die NAM-Logik so konfiguriert sein, dass sie die IP-Adresse der Proxy-Schnittstelle in die private(n) IP-Adresse(n) des/der virtuellen Zielcomputer(s) übersetzt.
Unter Bezugnahme auf 2B kann beispielsweise, da die Schnittstelle C 1 241 als Proxy für den virtuellen Zielcomputer 260 fungieren kann, wenn C1 ein Paket empfängt, dessen L3-Ziel-IP-Adresse auf die IP-Adresse 10.0.1.6 von C1 eingestellt ist, die NAM-Logik beispielsweise so konfiguriert sein, dass sie die Ziel-IP-Adresse des Pakets in die IP-Adresse 10.0.2.157 des Zielcomputers 260 ändert und das Paket dann über den schnellen Pfad durch die FPPP-Anwendungslogik zur Schnittstelle C2 weiterleitet. Umgekehrt kann, wenn C2 ein Paket empfängt, dessen L3-Quell-IP-Adresse auf die IP-Adresse 10.0.2.157 des Zielcomputers 260 eingestellt ist, das Paket über den schnellen Pfad an die NAM weitergeleitet werden, die so konfiguriert sein kann, dass sie die Quell-IP-Adresse des Pakets in die IP-Adresse 10.0.1.6 von C1 ändert. C1 kann dann das Paket an sein Ziel weiterleiten. Handelt es sich bei der Ziel-IP-Adresse des Pakets um eine Internet-Adresse (oder Adresse eines anderen öffentlichen Netzes), so kann das Paket das NAT-G/W 220 passieren, das die L3-Quell-IP-Adresse des Pakets von der IP-Adresse 10.0.1.6 von C1 in die öffentliche IP-Adresse 174.129.20.63 des Computers 260 übersetzen kann.
In Bezug auf die NAM-Funktion 2: Die Netzwerkschnittstellen des virtuellen BITW-Geräts können für die Weiterleitung von Paketen an ihre Ziele zuständig sein. Die Weiterleitungsfunktion kann dafür verantwortlich sein, dass die MAC-Adressen der L2-Frames, die die L3-Pakete enthalten, auf die richtigen Werte gesetzt werden, z. B. die MAC-Adressen der Endgeräte des virtuellen Pfads. Diese MAC-Adresswerte können von den Routing-Tabellen der Cloud über den Slow Path, d. h. über Aufrufe an die TCP/IP-Netzwerkstack-Logik des Betriebssystemkernels, gewonnen werden; aus Leistungsgründen könnte das virtuelle BITW-Gerät bei der Verarbeitung von im Transit befindlichen Paketen jedoch den Slow Path nicht verwenden. Durch die Konfiguration der NAM-Logik mit den richtigen MAC-Adressinformationen beim Konfigurieren des virtuellen BITW-Geräts für den Betrieb, wie beispielsweise in Schritt 3-1 von 3, kann die Weiterleitungsfunktion MAC-Adressinformationen vom (Fast Path-) NAM anstelle des (Slow Path-) TCP/IP-Netzwerkstacks des Betriebssystemkernels erhalten.
In Bezug auf die NAM-Funktion 3: Diese Funktion kann für einige Cloud-Konfigurationen verwendet werden, bei denen es zum Beispiel mehrere virtuelle Computer gibt, die von einem anderen virtuellen Zielcomputer, z. B. einem Load-Balancer, Web-Proxy usw., vermittelt werden können, wobei die zugehörigen Kommunikationen über das virtuelle BITW-Gerät laufen. Nimmt man beispielsweise an, es gibt keine NAM-Funktion 3; dann kann ein Anforderungspaket, das von einem von mehreren virtuellen Computern hinter einem virtuellen Proxy-Zielcomputer (z. B. einem Load-Balancer) stammt und für einen Internet-Host bestimmt ist, den Internet-Host (oder Host eines anderen öffentlichen Netzes) veranlassen, ein Antwortpaket zu erstellen und zu übertragen, das die IP-Adresse des Proxy-Load-Balancers als Ziel hat. Beim Empfang des Antwortpakets weiß der Load-Balancer möglicherweise nicht, von welchem vermittelten virtuellen Computer die entsprechende Anfrage stammte/ausging; daher kann der Load-Balancer einen beliebigen der vermittelten virtuellen Computer auswählen, an den er das Antwortpaket weiterleitet; daher kann es sein, dass der ausgewählte vermittelte virtuelle Computer nicht der Absender/ die Quelle des entsprechenden Anfragepakets ist.
Um das obige Beispielszenario und andere zu handhaben, kann die NAM eine effiziente Datenstruktur enthalten, die Informationen zu kürzlich beobachteten L3-Paketen und zugehörigen L2-Frames speichert/zwischenspeichert, umfassend die 5-Tupel-Werte des Pakets (L3-Quell- und Ziel-IP-Adressen, L4-Quell- und Ziel-Ports, L3-Protokolltyp), die MAC-Adressen des zugehörigen Frames und/oder die Richtung. Auf diese Weise kann die NAM das obige Beispielszenario (und ähnliche Szenarien) handhaben, indem sie die IP-Adresse und MAC-Adresse des virtuellen Computers, von dem das entsprechende Anforderungspaket ausging, wiederherstellt und das Antwortpaket und den zugehörigen Frame entsprechend modifiziert, so dass das Antwortpaket schließlich von dem richtigen virtuellen Computer empfangen wird. Es sei angemerkt, dass, um möglicherweise vorhandene Fast Path-Leistungsanforderungen zu erfüllen, die effiziente Datenstruktur, z. B. ein LRU-Cache, effiziente Einfügungen, Suchvorgänge und/oder Löschungen unterstützen kann.
5 zeigt ein Beispiel für eine Kommunikation zwischen dem Internet-Host HOST-0 110 und dem virtuellen Computer 260 in der privaten Cloud, die über das virtuelle BITW-Gerät 240 im virtuellen Pfad 208 laufen kann. Die in 5 dargestellten Beispiel-Netzwerkelemente entsprechen den in 2B dargestellten Beispielelementen und zugehörigen Konfigurationen, jedoch können die Elemente in 5 auch anderen hier beschriebenen Konfigurationen entsprechen. Aus Beispielzwecken wird auch davon ausgegangen, dass das virtuelle BITW-Gerät 240 gemäß den Schritten 3-1, 3-2 und 3-3 von 3 eingerichtet und konfiguriert wurde und sich in einem Betriebsmodus befindet, der durch Schritt 3-4 von 3 dargestellt wird.
Als Beispiel kann der virtuelle Computer 260 eine Webserver-Anwendung mit einem DNSregistrierten Domänennamen www.example-web-server.net ausführen, und der HOST-0 110 (zum Beispiel durch die öffentliche IP-Adresse 74.65.150.95 adressiert) kann eine Webclient/Webbrowser-Anwendung ausführen. Ein Benutzer, der den Webbrowser auf dem HOST-0 110 betreibt, kann den Browser auf die URL https://www.example-web-server.net richten. In Schritt 5-0 (in 5 nicht dargestellt) kann der Browser eine Anfrage an das (Internet-)DNS stellen, um www.example-webserver.net zu lösen, und das DNS kann mit der IP-Adresse 174.129.20.63 antworten.
In Schritt 5-1 kann der HOST-0 110 den Aufbau einer TCP-Verbindung mit Port 443 (HTTPS) von 174.129.20.63 (d.h. virtueller Computer 260) einleiten, indem er ein TCP-SYN-Handshake-Paket P0.0 mit der L3-Quell-IP-Adresse 74.65.150.95 und der L3-Ziel-IP-Adresse 174.129.20.63 über das Internet an den virtuellen Computer 260 sendet.
In Schritt 5-2 kann das NAT-G/W 220 das Paket P0.0 empfangen. Die NAT-Funktion kann die öffentliche IP-Adresse 174.129.20.63 des Computers 260 in 10.0.1.6 übersetzen, die die (private) IP-Adresse der Netzwerkschnittstelle C1 241 des virtuellen BITW-Geräts 240 sein kann und die die Proxy-IP-Adresse für den virtuellen Zielcomputer 260 sein kann. Das NAT-G/W 220 kann das Paket P0.0 wie folgt in P0.1 umwandeln: (1) L3-Ziel-IP-Adresse geändert in 10.0.1.6 (die IP-Adresse der Proxy-Netzwerkschnittstelle C1 241); (2) L2-Quell-MAC-Adresse geändert in 12:f7:4c:ac:de:7f (die MAC-Adresse der Netzwerkschnittstelle N2 222 von NAT-G/W 220); und (3) L2-Ziel-MAC-Adresse geändert in 12:3d:f8:07:f0: 19 (die MAC-Adresse der Netzwerkschnittstelle C1 241 des virtuellen BITW-Geräts 240). Die Netzwerkschnittstelle N2 222 kann das Paket P0.1 auf dem virtuellen Pfad 208 an die Netzwerkschnittstelle C1 241 des virtuellen BITW-Geräts 240 senden.
In Schritt 5-3 kann das virtuelle BITW-Gerät 240 das Paket P0.1 über seine Netzwerkschnittstelle C1 241 empfangen. Die NAM kann, wie in der oben beschriebenen NAM-Funktion 3, zum Speichern von Informationen, die mit kürzlich beobachteten Paketen verbunden sind, Informationen, die mit dem Paket P0.1 verbunden sind, in ihre effiziente Datenstruktur einfügen, für den Fall, dass die Herkunftscomputerinformationen später benötigt werden, um Informationen wiederherzustellen, die während der Proxy-Transformationen verloren gegangen sein könnten (in diesem Beispiel nicht dargestellt). Die NAM kann das Paket P0.1 wie folgt in P0.2 umwandeln: (1) L3-Ziel-IP-Adresse geändert in 10.0.2.157 (die IP-Adresse des virtuellen Computers 260); (2) L2-Quell-MAC-Adresse geändert in 12:a8:84:40:b6:39 (die MAC-Adresse der Netzwerkschnittstelle C2 242); und (3) L2-Ziel-MAC-Adresse geändert in 12:43:9d:b6:7b:f3 (die MAC-Adresse der Netzwerkschnittstelle des virtuellen Computers 260). Die NAM kann das Paket P0.2 an C2 242 weiterleiten/leiten. Die (Fast Path-) Paketverarbeitungsanwendung verarbeitet das Paket P0.2. Unter der Annahme, dass die Anwendung das Paket P0.2 nicht verwirft/blockiert, kann die Netzwerkschnittstelle C2 242 das Paket P0.2 auf dem virtuellen Pfad 208 an den virtuellen Computer 260 senden.
In Schritt 5-4 kann der virtuelle Zielcomputer 260 das Paket P0.2 empfangen. Der Computer 260 kann auf das TCP SYN-Handshake-Signal reagieren, indem er ein Paket P1.0 erzeugt, das ein TCP SYN- ACK-Handshake-Signal enthält und mit: (1) L3-Quell-IP-Adresse eingestellt auf 10.0.2.157 (die private IP-Adresse des virtuellen Computers 260); (2) L3-Ziel-IP-Adresse eingestellt auf 74.65.150.95 (die IP-Adresse von HOST-0 110); (3) L2-Quell-MAC-Adresse eingestellt auf 12:43:9d:b6:7b:f3 (die MAC-Adresse des Computers 260); und (4) L2-Ziel-MAC-Adresse eingestellt auf 12:a8:84:40:b6:39 (die MAC-Adresse der Netzwerkschnittstelle C2 242 des virtuellen BITW-Geräts 240). Die Einstellung der Ziel-MAC-Adresse des Pakets P1.0 auf die MAC-Adresse von C2 242 kann dazu beitragen, sicherzustellen, dass das Paket P1.0 den virtuellen Pfad 208 durch das virtuelle BITW-Gerät 240 durchläuft, auch wenn die L3-Ziel-IP-Adresse von P1.0 nicht die IP-Adresse von C2 242 ist. Der Computer 260 kann das Paket P1.0 auf dem virtuellen Pfad 208 in Richtung HOST-0 110 senden/weiterleiten.
In Schritt 5-5 kann das virtuelle BITW-Gerät 240 das Paket P1.0 über seine Netzwerkschnittstelle C2 242 empfangen. Die NAM kann, wie in der oben beschriebenen NAM-Funktion 3, zum Speichern von Informationen, die mit kürzlich beobachteten Paketen verbunden sind, Informationen, die mit dem Paket P1.0 verbunden sind, in ihre effiziente Datenstruktur einfügen, für den Fall, dass die Herkunftscomputerinformationen später benötigt werden, um Informationen wiederherzustellen, die während der Proxy-Transformationen verloren gegangen sein könnten (in diesem Beispiel nicht dargestellt). Die NAM kann das Paket P1.0 wie folgt in P1.1 umwandeln: (1) L3-Quell-IP-Adresse geändert in 10.0.1.6 (die IP-Adresse der Netzwerkschnittstelle C1 241, die als Proxy für den Computer 260 dient); (2) L2-Quell-MAC-Adresse geändert in 12:3d:f8:07:f0:19 (die MAC-Adresse der Netzwerkschnittstelle C1 241); und (3) L2-Ziel-MAC-Adresse geändert in 12:f7:4c:ac:de:7f (die MAC-Adresse der Netzwerkschnittstelle N2 222 von NAT-G/W 220). Das Einstellen der Ziel-MAC-Adresse von Paket P1.1 auf die MAC-Adresse von N2 222 kann dazu beitragen, sicherzustellen, dass das Paket P1.1 den virtuellen Pfad 208 zum NAT-G/W 220 durchläuft, obwohl die L3-Ziel-IP-Adresse von P1.1 nicht die IP-Adresse von N2 222 ist. Die NAM kann das Paket P1.1 in Richtung C1 241 weiterleiten/leiten. Die (Fast Path-)Paketverarbeitungsanwendung verarbeitet das Paket P1.1. Unter der Annahme, dass die Anwendung das Paket P1.1 nicht verwirft/blockiert, kann die Netzwerkschnittstelle C 1 241 das Paket P1.1 auf dem virtuellen Pfad 208 in Richtung HOST-0 110 senden/weiterleiten.
In Schritt 5-6 kann das NAT-G/W 220 das Paket P1.1 über seine Netzwerkschnittstelle N2 222 empfangen, die ein Endgerät des virtuellen Pfades 208 ist. Das NAT-G/W 220 kann das Paket P1.1 wie folgt in P1.2 umwandeln: (1) L3-Quell-IP-Adresse geändert in 174.129.20.63 (die öffentliche IP-Adresse des virtuellen Computers 260). Die Netzwerkschnittstelle N1 221 sendet/leitet das Paket P1.2 über das Internet in Richtung HOST-0 110 weiter.
In Schritt 5-7 kann eine TCP-Verbindung und ein TLS-Tunnel zwischen dem HOST-0 110 und dem virtuellen Computer 260 (der die Website www.example-web-site.net beherbergt) aufgebaut und eine (TLS-gesicherte) HTTP-Sitzung (z. B. HTTPS) durchgeführt werden. Nach Beendigung der HTTP-Sitzung können der TLS-Tunnel und die TCP-Verbindung abgebrochen werden. Alle Pakete, aus denen sich die Kommunikation zusammensetzt, können den virtuellen Pfad 208 durchlaufen und das virtuelle BITW-Gerät 240 in beiden Richtungen passieren.
Jedes der hier beschriebenen oder in einer der Figuren dargestellten Elemente kann teilweise oder vollständig mit einem oder mehreren Computergeräten implementiert werden. Die Hardware-Elemente eines Beispiel-Computergeräts 600, das zur Implementierung aller anderen hier beschriebenen Elemente verwendet werden kann, sind in 6 dargestellt. Jedes dieser Hardware-Elemente und/oder das Computergerät 600 selbst kann in einer virtuellen Version des Computergeräts 600 emuliert werden. Das Computergerät 600 kann einen oder mehrere Prozessoren 601 enthalten, die computerlesbare Anweisungen eines Computerprogramms ausführen können, um eine der hierin beschriebenen Funktionen oder andere Operationen auszuführen. Die Anweisungen können zusammen mit anderen Daten in einem Speicher 602 gespeichert sein, der beispielsweise einen Speicher wie einen Nur-Lese-Speicher (ROM) und/oder einen Speicher mit wahlfreiem Zugriff (RAM), eine Festplatte, eine magnetische oder optische Platte, ein USB (Universal Serial Bus)-Laufwerk und/oder jede andere Art von computerlesbaren Medien umfassen kann. Das Computergerät 600 kann auch eine Benutzerschnittstelle 604 als Schnittstelle zu einem oder mehreren Eingabegeräten 605 enthalten, wie z. B. einer Tastatur, Maus, Spracheingabe usw., und als Schnittstelle zu einem oder mehreren Ausgabegeräten 606, wie z. B. einer Anzeige, einem Lautsprecher, einem Drucker usw. Das Computergerät 600 kann auch eine Netzwerkschnittstelle 603 als Schnittstelle zu einem oder mehreren externen Geräten enthalten, die Teil eines Netzwerks außerhalb des Computergeräts 600 sein können. Obwohl 6 eine beispielhafte Hardwarekonfiguration zeigt, können ein oder mehrere Elemente des Computergeräts 600 als Software oder eine Kombination aus Hardware und Software implementiert werden. Es können Modifikationen vorgenommen werden, um Komponenten des Computergeräts 600 hinzuzufügen, zu entfernen, zu kombinieren, zu teilen usw. Darüber hinaus können die in 6 gezeigten Elemente unter Verwendung von grundlegenden Computergeräten und -komponenten implementiert werden, die so konfiguriert sind, dass sie Operationen, wie sie hier beschrieben sind, durchführen. Prozessor(en) 601 und/oder Speicher 602 können auch oder alternativ durch einen oder mehrere integrierte Schaltkreise (ICs) implementiert werden. Ein IC kann beispielsweise ein Mikroprozessor sein, der auf Programmieranweisungen oder andere Daten zugreift, die in einem ROM gespeichert und/oder fest mit dem IC verdrahtet sind. Ein IC kann zum Beispiel eine anwendungsspezifische integrierte Schaltung (ASIC) mit Gattern und/oder anderer Logik für die hier beschriebenen Berechnungen und anderen Operationen sein. Ein IC kann einige Operationen auf der Grundlage der Ausführung von Programmieranweisungen durchführen, die aus dem ROM oder RAM gelesen werden, während andere Operationen in Gattern oder anderer Logik fest verdrahtet sind.
Die hierin beschriebenen Funktionen und Schritte können in computerverwendbaren Daten oder computerausführbaren Anweisungen verkörpert sein, wie in einem oder mehreren Programmmodulen, die von einem oder mehreren Computergeräten (z. B. Computern oder anderen Datenverarbeitungsgeräten) ausgeführt werden, um eine oder mehrere hierin beschriebene Funktionen auszuführen. Im Allgemeinen können Programmmodule Routinen, Programme, Objekte, Komponenten, Datenstrukturen und/oder andere Elemente enthalten, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren, wenn sie von einem oder mehreren Prozessoren eines oder mehrerer Computergeräte ausgeführt werden. Die computerausführbaren Anweisungen können auf einem computerlesbaren Medium wie einer Festplatte, einer optischen Platte, einem Wechselspeichermedium, einem Festkörperspeicher, einem RAM usw. gespeichert sein. Wie man sieht, kann die Funktionalität der Programmmodule beliebig kombiniert oder verteilt werden. Darüber hinaus kann die Funktionalität ganz oder teilweise in Firmware oder Hardware- Äquivalenten wie integrierten Schaltkreisen, anwendungsspezifischen integrierten Schaltkreisen (ASICs), feldprogrammierbaren Gate-Arrays (FPGAs) und dergleichen verkörpert sein. Besondere Datenstrukturen können verwendet werden, um einen oder mehrere Aspekte der Offenbarung effektiver zu implementieren, und solche Datenstrukturen werden in Betracht gezogen, um in den Anwendungsbereich der hierin beschriebenen computerausführbaren Anweisungen und computerverwendbaren Daten zu fallen.
Obwohl nicht erforderlich, wird der Durchschnittsfachmann verstehen, dass verschiedene hierin beschriebene Aspekte als ein Verfahren, ein System, eine Vorrichtung oder ein oder mehrere computerlesbare Medien, die computerausführbare Anweisungen speichern, die, wenn sie von einem oder mehreren Prozessoren eines Computergeräts ausgeführt werden, das Computergerät veranlassen, die hierin offenbarten Schritte durchzuführen, verkörpert werden können. Dementsprechend können die Aspekte die Form eines vollständigen Hardware-Ausführungsbeispiels, eines vollständigen Software- Ausführungsbeispiels, eines vollständigen Firmware-Ausführungsbeispiels, eines vollständigen virtuellen Ausführungsbeispiels oder eines Ausführungsbeispiels annehmen, die Software-, Hardware-, virtualisierte und/oder Firmware-Aspekte in beliebiger Kombination kombiniert.
Wie hierin beschrieben, können die verschiedenen Methoden und Handlungen über ein oder mehrere physisch getrennte oder integrierte Computergeräte (die zusammen ein Computergerät bilden können) und Netzwerke ausgeführt werden. Die Funktionalität kann in beliebiger Weise verteilt sein oder sich in einem einzigen physischen Computergerät oder einer virtuellen Version eines Computergeräts (z. B. einem Server, einem Client-Computer, einem Benutzergerät, einer virtuellen Umgebung oder dergleichen) befinden.
Aspekte der Offenbarung wurden in Form von illustrativen Ausführungsbeispielen beschrieben. Zahlreiche andere Ausführungsformen, Modifikationen und Variationen innerhalb des Umfangs und des Geistes der beigefügten Ansprüche werden dem Durchschnittsfachmann bei der Durchsicht dieser Offenbarung auffallen. Beispielsweise wird der Durchschnittsfachmann erkennen, dass die in den Abbildungen dargestellten Schritte in einer anderen als der angegebenen Reihenfolge durchgeführt werden können und dass ein oder mehrere der dargestellten Schritte optional sein können.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 17/395120 [0001]
US 63/071174 [0001]

Claims

Verfahren, umfassend: Bereitstellen einer Vorrichtung in einem virtuellen Pfad; Konfigurieren einer Network-Address-Mapping (NAM)-Logik mit: mehreren Adressen von Virtueller-Pfad-Endgeräten, die über den virtuellen Pfad verbunden sind; mehreren Adressen von Netzwerkschnittstellen, die Teilnetzen der Virtueller-Pfad-Endgeräte entsprechen; und Proxy-Informationen; Konfigurieren eines Network Address Translation (NAT)-Gateways, um mindestens eine öffentliche Internetprotokoll-(IP)-Adresse in eine private IP-Adresse zu übersetzen, die der Vorrichtung zugeordnet ist; und Bereitstellen mindestens einer Cloud-Routing-Tabelle, die so konfiguriert ist, dass sie ein Virtual-Path-Routing durch die Vorrichtung und das NAT-Gateway bewirkt.
Verfahren nach Anspruch 1, wobei die Vorrichtung ein virtuelles Bump-in-the-Wire (BITW)-Gerät umfasst.
Verfahren nach Anspruch 1 oder Anspruch 2, wobei die mehreren Adressen der Virtueller-Pfad-Endgeräte umfassen: mehrere Internetprotokoll (IP)-Adressen der Endgeräte; und mehrere Media Access Control (MAC)-Adressen der Endgeräte.
Verfahren nach einem der Ansprüche 1-3, wobei die mehreren Adressen der Netzwerkschnittstellen umfassen: mehrere Internetprotokoll (IP)-Adressen der Netzwerkschnittstellen; und mehrere Media Access Control (MAC)-Adressen der Netzwerkschnittstellen.
Verfahren nach einem der Ansprüche 1-4, wobei die Netzwerkschnittstellen umfassen: eine erste Netzwerkschnittstelle der Vorrichtung, die einem ersten Teilnetz entspricht, die so konfiguriert ist, dass sie eine Schnittstelle zu einer Netzwerkschnittstelle des NAT-Gateways bildet; und eine zweite Netzwerkschnittstelle der Vorrichtung, die einem zweiten Teilnetz entspricht, die so konfiguriert ist, dass sie eine Schnittstelle zu einer Netzwerkschnittstelle eines Ziels bildet, wobei sich das erste Teilnetz und das zweite Teilnetz nicht überlappen.
Verfahren nach einem der Ansprüche 1-5, wobei der virtuelle Pfad einen Fast Path durch die Vorrichtung umfasst, und wobei die Vorrichtung so konfiguriert ist, dass sie mindestens ein vom NAT-Gateway empfangenes Paket durch den Fast Path routet.
Verfahren nach einem der Ansprüche 1-6, wobei die Cloud-Routing-Tabelle so konfiguriert ist, dass sie ein Outbound-Virtual-Path-Routing durch die Vorrichtung und das NAT-Gateway bewirkt.
Verfahren nach einem der Ansprüche 1-7, wobei das Konfigurieren der NAM-Logik das Konfigurieren der NAM-Logik in der Weise umfasst, dass jedes der Virtueller-Pfad-Endgeräte ausschließlich auf eine der Netzwerkschnittstellen abgebildet wird.
Verfahren, umfassend: Empfangen, durch ein Network-Address-Translation (NAT)-Gateway, eines Pakets, das an eine öffentliche Internetprotokoll (IP)-Adresse adressiert ist; Übersetzen, durch das NAT-Gateway, der öffentlichen IP-Adresse in eine private IP-Adresse einer Vorrichtung, die in einem virtuellen Pfad bereitgestellt wird, wobei die Vorrichtung eine Network-Address-Mapping (NAM)-Logik umfasst, die konfiguriert ist mit: mehreren Adressen von Virtueller-Pfad-Endgeräten, die über den virtuellen Pfad verbunden sind; mehreren Adressen von Netzwerkschnittstellen, die Teilnetzen der Virtueller-Pfad-Endgeräte entsprechen; und Proxy-Informationen; und Senden des Pakets durch das NAT-Gateway an die private IP-Adresse.
Verfahren nach Anspruch 9, ferner umfassend das Routen, unter Verwendung mindestens einer Cloud-Routing-Tabelle, des Pakets durch den virtuellen Pfad über das NAT-Gateway und die Vorrichtung.
Verfahren nach Anspruch 9 oder Anspruch 10, wobei die Vorrichtung ein virtuelles Bump-in-the-Wire (BITW)-Gerät umfasst.
Verfahren nach einem der Ansprüche 9-11, wobei die mehreren Adressen der Virtueller-Pfad-Endgeräte umfassen: mehrere Internetprotokoll (IP)-Adressen der Endgeräte; und mehrere Media Access Control (MAC)-Adressen der Endgeräte.
Verfahren nach einem der Ansprüche 9-12, wobei die mehreren Adressen der Netzwerkschnittstellen umfassen: mehrere Internetprotokoll (IP)-Adressen der Netzwerkschnittstellen; und mehrere Media Access Control (MAC)-Adressen der Netzwerkschnittstellen.
Verfahren nach einem der Ansprüche 9-13, wobei die Netzwerkschnittstellen umfassen: eine erste Netzwerkschnittstelle der Vorrichtung, die einem ersten Teilnetz entspricht, die so konfiguriert ist, dass sie eine Schnittstelle zu einer Netzwerkschnittstelle des NAT-Gateways bildet; und eine zweite Netzwerkschnittstelle der Vorrichtung, die einem zweiten Teilnetz entspricht, die so konfiguriert ist, dass sie eine Schnittstelle zu einer Netzwerkschnittstelle eines Ziels bildet, wobei sich das erste Teilnetz und das zweite Teilnetz nicht überlappen.
Verfahren nach einem der Ansprüche 9-14, wobei der virtuelle Pfad einen Fast Path durch die Vorrichtung umfasst.
Verfahren nach einem der Ansprüche 9-15, wobei die NAM-Logik so konfiguriert ist, dass jedes der Virtueller-Pfad-Endgeräte ausschließlich auf eine der Netzwerkschnittstellen abgebildet wird.
Computerlesbares Medium, das Anweisungen speichert, die, wenn sie von einem Network-Address-Translation (NAT)-Gateway ausgeführt werden, das NAT-Gateway so konfigurieren, dass es die in einem der Ansprüche 9-16 angeführten Schritte durchführt.
Network-Address-Translation (NAT)-Gateway, umfassend: einen oder mehrere Prozessoren; und ein oder mehrere computerlesbare Medien, die Anweisungen speichern, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, das NAT-Gateway dazu veranlassen: ein Paket zu empfangen, das an eine öffentliche Internetprotokoll (IP)-Adresse adressiert ist; die öffentliche IP-Adresse in eine private IP-Adresse einer Vorrichtung zu übersetzen, die in einem virtuellen Pfad bereitgestellt ist, wobei die Vorrichtung eine Network-Address-Mapping (NAM)-Logik umfasst, die konfiguriert ist mit: mehreren Adressen von Virtueller-Pfad-Endgeräten, die über den virtuellen Pfad verbunden sind; mehreren Adressen von Netzwerkschnittstellen, die Teilnetzen der Virtueller-Pfad-Endgeräte entsprechen; und Proxy-Informationen; und das Paket an die private IP-Adresse zu senden.
NAT-Gateway nach Anspruch 18, wobei die Anweisungen, wenn sie von dem einen oder mehreren Prozessoren ausgeführt werden, ferner das NAT-Gateway dazu veranlassen, unter Verwendung mindestens einer Cloud-Routing-Tabelle das Routen des Pakets durch den virtuellen Pfad über das NAT-Gateway und die Vorrichtung zu bewirken.
NAT-Gateway nach Anspruch 18 oder Anspruch 19, wobei die mehreren Adressen der Virtueller-Pfad-Endgeräte umfassen: mehrere Internetprotokoll (IP)-Adressen der Endgeräte; und mehrere Media Access Control (MAC)-Adressen der Endgeräte.
NAT-Gateway nach einem der Ansprüche 18-20, wobei die mehreren Adressen der Netzwerkschnittstellen umfassen: mehrere Internetprotokoll (IP)-Adressen der Netzwerkschnittstellen; und mehrere Media Access Control (MAC)-Adressen der Netzwerkschnittstellen.
NAT-Gateway nach einem der Ansprüche 18-21, wobei die Netzwerkschnittstellen umfassen: eine erste Netzwerkschnittstelle der Vorrichtung, die einem ersten Teilnetz entspricht, die so konfiguriert ist, dass sie eine Schnittstelle zu einer Netzwerkschnittstelle des NAT-Gateways bildet; und eine zweite Netzwerkschnittstelle der Vorrichtung, die einem zweiten Teilnetz entspricht, die so konfiguriert ist, dass sie eine Schnittstelle zu einer Netzwerkschnittstelle eines Ziels bildet, wobei sich das erste Teilnetz und das zweite Teilnetz nicht überlappen.
NAT-Gateway nach einem der Ansprüche 18-22, wobei die NAM-Logik so konfiguriert ist, dass jedes der Virtueller-Pfad-Endgeräte ausschließlich auf eine der Netzwerkschnittstellen abgebildet wird.
System, umfassend: ein Network-Address-Translation (NAT)-Gateway, umfassend: einen oder mehrere Prozessoren; und ein oder mehrere computerlesbare Medien, die Anweisungen speichern; und eine Vorrichtung, die in einem virtuellen Pfad bereitgestellt wird und die eine private Internetprotokoll (IP)-Adresse hat, wobei die Vorrichtung eine Network-Address-Mapping (NAM)-Logik umfasst, die konfiguriert ist mit: mehreren Adressen von Virtueller-Pfad-Endgeräten, die über den virtuellen Pfad verbunden sind; mehreren Adressen von Netzwerkschnittstellen, die Teilnetzen der Virtueller-Pfad-Endgeräte entsprechen; und Proxy-Informationen, wobei die Anweisungen, wenn sie von dem einen mehreren Prozessoren ausgeführt werden, das NAT-Gateway dazu veranlassen: ein Paket zu empfangen, das an eine öffentliche Internetprotokoll (IP)-Adresse adressiert ist; die öffentliche IP-Adresse in die private IP-Adresse der Vorrichtung zu übersetzen; und das Paket an die private IP-Adresse der Vorrichtung zu senden.
System nach Anspruch 24, wobei die Anweisungen, wenn sie von dem einen oder mehreren Prozessoren ausgeführt werden, ferner das NAT-Gateway dazu veranlassen, unter Verwendung mindestens einer Cloud-Routing-Tabelle das Routen des Pakets durch den virtuellen Pfad über das NAT-Gateway und die Vorrichtung zu bewirken.
System nach Anspruch 24 oder Anspruch 25, wobei die Vorrichtung ein virtuelles Bump-in-the-Wire (BITW)-Gerät umfasst.
System nach einem der Ansprüche 24-26, wobei die mehreren Adressen der Virtueller-Pfad-Endgeräte umfasst: mehrere Internetprotokoll (IP)-Adressen der Endgeräte; und mehrere Media Access Control (MAC)-Adressen der Endgeräte.
System nach einem der Ansprüche 24-27, wobei die mehreren Adressen der Netzwerkschnittstellen umfasst: mehrere Internetprotokoll (IP)-Adressen der Netzwerkschnittstellen; und mehrere Media Access Control (MAC)-Adressen der Netzwerkschnittstellen.
System nach einem der Ansprüche 24-28, wobei die Netzwerkschnittstellen umfassen: eine erste Netzwerkschnittstelle der Vorrichtung, die einem ersten Teilnetz entspricht, die so konfiguriert ist, dass sie eine Schnittstelle zu einer Netzwerkschnittstelle des NAT-Gateways bildet; und eine zweite Netzwerkschnittstelle der Vorrichtung, die einem zweiten Teilnetz entspricht, die so konfiguriert ist, dass sie eine Schnittstelle zu einer Netzwerkschnittstelle eines Ziels bildet, wobei sich das erste Teilnetz und das zweite Teilnetz nicht überlappen.
System nach einem der Ansprüche 24-29, wobei der virtuelle Pfad einen Fast Path durch die Vorrichtung umfasst.
System nach einem der Ansprüche 24-30, wobei die NAM-Logik so konfiguriert ist, dass jedes der Virtueller-Pfad-Endgeräte ausschließlich auf eine der Netzwerkschnittstellen abgebildet wird.