Zentrale Netzwerk-Appliances in Google Cloud

Dieses Dokument richtet sich an Netzwerkadministratoren, Lösungsarchitekten und Betriebsexperten, die zentralisierte Netzwerk-Appliances in Google Cloud ausführen. Kenntnisse der Compute Engine und des VPC-Netzwerks (Virtual Private Cloud) in Google Cloud sind erforderlich.

Geschäftsumgebungen müssen häufig Traffic an das Internet, ein lokales Netzwerk, andere Clouds oder sogar in andere Teile derselben Cloud-Umgebung über virtualisierte VM-basierte Appliances senden, die diese überwachen, transformieren und umwandeln oder Traffic blockieren.

In diesem Dokument werden mehrere Designoptionen erläutert, die VPC-Netzwerke segmentieren und mit einer zentralisierten, virtualisierten Netzwerk-Appliance verbinden. Die gesamte Kommunikation zwischen VPC-Netzwerken, lokalen Netzwerken und dem Internet wird über das zentrale Gerät geleitet. Sie können eine Gruppe redundanter Appliances bereitstellen, um eine Hochverfügbarkeitskonfiguration zu erhalten. Wenn Sie keine hohe Verfügbarkeit benötigen, können Sie eine einzelne Netzwerk-Appliance bereitstellen.

Das Routing von Traffic durch virtualisierte Appliances kann eine Herausforderung darstellen. In Google Cloud können Sie beispielsweise die Route zum Internet ersetzen und den Traffic an eine Reihe von virtuellen Appliances weiterleiten. Es ist jedoch nicht möglich, das Routingverhalten zwischen Subnetzwerken innerhalb einer VPC zu ändern. Das Routing zwischen Subnetzwerken erfolgt automatisch und diese Routen können nicht gelöscht oder überschrieben werden.

Aufgrund der wichtigen Rolle von virtualisierten Appliances müssen sie auch in hochverfügbaren Konfigurationen bereitgestellt werden. Dies ist eine Herausforderung, da Sie dafür sorgen müssen, dass der gesamte Traffic über eine der virtuellen Appliances geleitet wird und dass das Failover zwischen diesen Appliances automatisch erfolgt.

Das folgende Diagramm zeigt einen typischen Anwendungsfall mehrerer Designoptionen mit einer zentralisierten, virtualisierten Netzwerk-Appliance.

Designoptionen mit einer zentralisierten, virtualisierten Netzwerk-Appliance.

Das obige Diagramm zeigt die Kommunikationspfade zwischen segmentierten VPC-Netzwerken, lokalen Netzwerken und dem Internet sowie deren Weiterleitung über die zentralisierte, virtualisierte Netzwerk-Appliance.

Wichtigste Anwendungsfälle für diese Architektur

Sie können diese Architektur für mehrere Anwendungsfälle verwenden, bei denen virtuelle Netzwerkgeräte einbezogen werden, durch die der Traffic weitergeleitet wird. Beachten Sie dabei die folgenden Aspekte:

  • Viele Appliances von verschiedenen Anbietern finden Sie im Google Cloud Marketplace.
  • Einige Appliance-Anbieter bieten auf ihren Websites oder Support-Seiten auch benutzerdefinierte Compute Engine-Images für Google Cloud an.
  • Sie können Ihre eigenen virtualisierten Appliances mithilfe von Open-Source-Netzwerksoftware erstellen. Sie können auch eigene Images erstellen.

Anbieter stellen häufig eigene Referenzarchitekturen oder Bereitstellungsanleitungen für die Ausführung ihrer virtuellen Appliances in einer Konfiguration mit Hochverfügbarkeit bereit. Weitere Informationen finden Sie auf der Website des Anbieters.

Referenzarchitekturen des Anbieters umfassen möglicherweise nicht alle in diesem Dokument dargestellten Optionen.

Es ist wichtig, die Vor- und Nachteile jedes Ansatzes zu verstehen. Typische Anwendungsfälle für virtuelle Appliances, über die Traffic weitergeleitet wird:

  • Firewalls der nächsten Generation (NGFWs). Ein zentralisierter Satz von Firewalls wird als virtuelle Maschinen ausgeführt, die Funktionen bereitstellen, die nicht verfügbar sind, wenn Sie VPC-Firewallregeln verwenden. Dies ist der gängigste Anwendungsfall. Typische Merkmale von NGFW-Produkten sind die Deep-Packet-Prüfung (DPI) und die Firewall auf Anwendungsebene. Einige NGFW-Firewalls bieten außerdem eine TLS/SSL-Traffic-Prüfung sowie weitere Netzwerkfunktionen, die in den Anwendungsfällen in den folgenden Aufzählungselementen beschrieben sind.
  • System zur Angriffserkennung (Intrusion Detection System, IDS/IPS): Ein netzwerkbasiertes IDS erfordert die Sichtbarkeit aller potenziell böswilligen Zugriffe. Zur Vermeidung von Eindringversuchen wird der Traffic in der Regel direkt von einer IPS im Trafficpfad blockiert.
  • Transparenter Proxy. Ein transparenter Proxy wird häufig verwendet, um den HTTP(S)-Traffic zu überwachen und Einschränkungen für den Webzugriff zu erzwingen.
  • NAT-Gateway (Network Address Translation). Ein NAT-Gateway übersetzt IP-Adressen und Ports. Damit lassen sich beispielsweise überlappende IP-Adressen vermeiden. Google Cloud bietet Cloud NAT als verwalteten Dienst. Dieser Dienst ist jedoch nur für Traffic zum Internet und nicht für lokalen Traffic oder für andere VPC-Netzwerke in Google Cloud verfügbar.
  • Web Application Firewall (WAF). Eine WAF blockiert böswilligen HTTP-Traffic an eine Webanwendung. Google Cloud bietet im Rahmen der Sicherheitsrichtlinien von Google Cloud Armor eine WAF-Funktion. Die genaue Funktionalität unterscheidet sich je nach WAF-Anbieter. Daher ist es wichtig, genau zu bestimmen, was Sie benötigen.

Typische Anforderungen

Die Anforderungen an die Weiterleitung von Traffic über zentralisierte virtuelle Appliances unterscheiden sich je nach Anwendungsfall. Die folgenden Anforderungen gelten jedoch im Allgemeinen:

  • Der gesamte Traffic zwischen verschiedenen Netzwerksegmenten, z. B. Umgebungen, die von verschiedenen Teams verwaltet werden, mit separaten Sicherheitsanforderungen oder zwischen verschiedenen Modulen einer Anwendung, muss über eine zentralisierte virtuelle Appliance geleitet werden.
  • Der gesamte Traffic in und aus dem Internet in sichere Umgebungen muss über eine zentrale virtuelle Appliance geleitet werden.
  • Der gesamte Traffic zu oder von lokalen Systemen, die über Cloud VPN, Dedicated Interconnect oder Partner Interconnect mit Google Cloud verbunden sind, muss eine zentralisierte virtuelle Appliance durchlaufen.
  • Mehrere zentralisierte virtuelle Appliances werden in einer Konfiguration mit hoher Verfügbarkeit in einer Aktiv/Aktiv- oder Aktiv/Passiv-Konfiguration eingerichtet. Ein Failover erfolgt automatisch, wenn Software- oder Hardwareprobleme auf einer der virtualisierten Appliances auftreten.
  • Der gesamte Traffic wird zustandslos weitergeleitet, sodass ein Traffic-Fluss zwischen zwei virtuellen Maschinen immer über dieselbe virtuelle Appliance geleitet wird.
  • Der Durchsatz des Systems von zentralisierten virtuellen Appliances wird mit einer der beiden folgenden Optionen skaliert:
    • Vertikale Skalierung der virtuellen Appliances: Erhöhen der Anzahl der Kerne oder des Arbeitsspeichers auf jeder virtuellen Maschine.
    • Skalierung der virtuellen Appliances horizontal: Erhöhen der Anzahl der virtuellen Appliances, die zum Verteilen des Traffics verwendet werden

Architekturoptionen

Es gibt mehrere Möglichkeiten, eine hohe Verfügbarkeit zwischen virtuellen Appliances zu erreichen. Es gibt auch mehrere Möglichkeiten, Netzwerksegmente an die virtuellen Appliances anzuhängen.

Sie können jede beliebige Option für Hochverfügbarkeit mit jeder beliebigen Option zum Anhängen von Netzwerksegmenten kombinieren. Eine weiter unten in diesem Dokument beschriebene Option ist eine Architektur, in der VPC-Netzwerk-Peering und der interne TCP/UDP-Load-Balancer als nächster Hop verwendet werden.

Hochverfügbarkeitsoption auswählen

Sie können eine Architektur erstellen, um eine hohe Verfügbarkeit für die zentrale Appliance zu erreichen, indem Sie mehrere Instanzen auf zwei Arten verwenden:

  • Interne TCP/UDP-Load-Balancer als nächsten Hop verwenden. Bei diesem Ansatz platzieren Sie mehrere virtuelle Appliances in einer verwalteten Instanzgruppe hinter einem internen TCP/UDP-Load-Balancer. Dieser Load-Balancer wird als nächster Hop verwendet. Dies ist eine Standardroute, die die Standardroute in den mit den Appliances verbundenen VPC-Netzwerken ersetzt. Sie können Appliances entweder in einer Aktiv/Aktiv-Konfiguration, der Standardkonfiguration oder in einer Aktiv/Passiv-Konfiguration verwenden, indem Sie ein Failover für das interne TCP/UDP-Load-Balancing bereitstellen. Systemdiagnosen leiten den Traffic zu fehlerfreien Instanzen weiter. Wenn Sie bei einem Fehler eine automatische Neuerstellung vornehmen möchten, können Sie die automatische Reparatur verwenden. Wenn Ihr Gerät mehrere Netzwerkschnittstellen verwendet, kann ein interner TCP/UDP-Load-Balancer als nächster Hop Back-Ends auf jeder Netzwerkschnittstelle haben.

    Das folgende Diagramm zeigt die Topologie der Verwendung eines internen TCP/UDP-Load-Balancers als nächsten Hop.

    Die Topologie für die Verwendung eines internen TCP/UDP-Load-Balancers als nächsten Hop.

    Das vorstehende Diagramm zeigt eine verwaltete Instanzgruppe in einem VPC-Netzwerk, einschließlich mehrerer virtueller Appliances hinter einem internen TCP/UDP-Load-Balancer, der als nächster Hop dient.

  • Routing verwenden. Bei diesem Ansatz leitet Google Cloud den Traffic von den verbundenen VPC-Netzwerken zu den virtuellen Appliances weiter. Sie können Appliances entweder in einer Aktiv/Passiv-Konfiguration verwenden, indem Sie verschiedene Prioritätsrouten nutzen oder in einer Aktiv/Aktiv-Konfiguration, wenn Routen mit derselben Priorität konfiguriert sind. In diesem Fall verwenden Sie ECMP-Routing (Equal Cost Multi Path) zur Verteilung des Traffics. Sie können die automatische Reparatur verwenden, damit Appliances neu gestartet werden, wenn sie fehlerhaft sind.

    Das folgende Diagramm zeigt die Topologie für die Verwendung von Routing.

    Die Topologie für das Routing.

    Das obige Diagramm zeigt eine verwaltete Instanzgruppe in einem VPC-Netzwerk mit Google Cloud-Routen, die den Traffic an die virtuellen Appliances vom verbundenen VPC-Netzwerk weiterleitet.

Bei beiden Ansätzen kann in einer Aktiv/Aktiv-Konfiguration der Rücktraffic an eine andere virtuelle Maschine als an den ausgehenden Traffic weitergeleitet werden, sofern Sie nicht für den gesamten Traffic Quell-NAT verwenden. Der Support für die Sitzungssynchronisierung hängt vom Support der virtuellen Appliance ab.

Die Verwendung eines internen TCP/UDP-Load-Balancers als nächsten Hop hat folgende Vorteile gegenüber der Verwendung von Google Cloud-Routing für Hochverfügbarkeit:

  • Systemdiagnosen entscheiden, wohin der Traffic weitergeleitet wird, um sicherzustellen, dass der Traffic nur an fehlerfreie Instanzen weitergeleitet wird. Sie können Systemdiagnosen bereitstellen, damit die lokale Instanz überprüft oder ein End-to-End-Pfad verifiziert wird.
  • Sie können die Systemdiagnose-Timer für ein schnelleres Failover optimieren. Dieser Ansatz bietet die schnellsten Failover-Zeiten bei fehlerhaften Instanzen.

Die Verwendung eines internen TCP/UDP-Load-Balancers als nächsten Hop hat jedoch folgende Nachteile:

  • Nur TCP- und UDP-Traffic kann durch einen internen TCP/UDP-Load-Balancer geleitet werden. Andere Protokolle, einschließlich Internet Control Message Protocol (ICMP), werden nicht unterstützt.
  • Der interne TCP/UDP-Load-Balancer als nächster Hop unterstützt keine Netzwerktags.

Die Verwendung von Google Cloud-Routing bietet folgende Vorteile:

  • Alle Protokolle, mit Ausnahme von immer blockiertem Traffic, werden unterstützt. Sie sind nicht auf bestimmte Protokolle beschränkt.
  • Google Cloud-Routen können auf bestimmte Netzwerktags beschränkt werden. Beispielsweise können VM-Instanzen nach Regionen segmentiert werden, um unterschiedliche Appliances zu verwenden.

Die Verwendung von Google Cloud-Routing hat die folgenden Nachteile:

  • Bei Systemdiagnosen werden fehlerhafte Instanzen aus dem Pool gelöscht und neu erstellt. Der Trafficfluss ändert sich jedoch nicht sofort nach fehlgeschlagenen Systemdiagnosen, da es einige Zeit dauern kann, bis fehlerhafte Instanzen gelöscht und neue, fehlerfreie Instanzen erstellt werden. Dies führt zu langsameren Failover-Zeiten.
  • Wenn Sie Timer für Systemdiagnosen festlegen, um ein unnötiges Löschen und das erneute Erstellen von Instanzen zu vermeiden, führt dies zu langsameren Failover-Zeiten.

Option zum Anhängen von Netzwerksegmenten auswählen

Da das Routing zwischen Subnetzwerken nicht überschrieben werden kann, werden Netzwerksegmente mithilfe separater VPC-Netzwerke implementiert. Der Traffic zwischen diesen VPC-Netzwerken, zu einer lokalen Umgebung und zum Internet muss über die zentralisierten Appliances weitergeleitet werden. Alle diese Netzwerksegmente können entweder eigenständige VPC-Netzwerke oder freigegebene VPC-Netzwerke sein.

Es gibt mehrere Möglichkeiten, Netzwerksegmente anzuhängen:

  • Mehrere Netzwerkschnittstellen. Die einfachste Methode zum Verbinden mehrerer VPC-Netzwerke über eine virtuelle Appliance ist die Verwendung mehrerer Netzwerkschnittstellen, wobei jede Schnittstelle mit einem der VPC-Netzwerke verbunden ist. Internet- und lokale Verbindungen werden über eine oder zwei separate Netzwerkschnittstellen bereitgestellt. Bei vielen NGINX-Produkten ist die Internetverbindung über eine Schnittstelle verbunden, die in der NGFW-Software als nicht vertrauenswürdig markiert ist.

    Diese Topologie ist im folgenden Diagramm dargestellt.

    Topologie mehrerer VPC-Netzwerke, die über eine virtuelle Appliance über mehrere Netzwerkschnittstellen verbunden sind.

    Das obige Diagramm zeigt mehrere VPC-Netzwerke, die über mehrere Netzwerkschnittstellen über eine virtuelle Appliance verbunden sind. Jede Schnittstelle stellt eine Verbindung zu einem der VPC-Netzwerke her. Das Diagramm zeigt auch Internet- und lokale Verbindungen über separate Netzwerkschnittstellen, einschließlich einer Internetverbindung über eine nicht vertrauenswürdige Schnittstelle.

  • VPC-Netzwerk-Peering. Diese Topologie verwendet das Hub-and-Spoke-Konzept in Verbindung mit VPC-Netzwerk-Peering. Die Netzwerksegmente werden als eine Reihe von Spoke-VPC-Netzwerken implementiert, die mithilfe von VPC-Netzwerk-Peering mit einem Hub-VPC-Netzwerk verbunden werden, in dem der Traffic über den zentralisierten Pool von virtualisierten Appliances geleitet wird. Die Standardroute oder Routen, die auf den internen TCP/UDP-Load-Balancer als nächster Hop oder direkt auf die virtuellen Appliances verweisen, werden als benutzerdefinierte Routen über VPC-Netzwerk-Peering exportiert. Internet- und lokale Verbindungen werden über eine oder zwei separate Netzwerkschnittstellen bereitgestellt.

    Diese Topologie ist im folgenden Diagramm dargestellt.

    Topologie der Kombination mehrerer Netzwerkschnittstellen mit VPC-Netzwerk-Peering.

    Das obige Diagramm zeigt einen zentralisierten Pool von virtualisierten Appliances mit mehreren Netzwerkschnittstellen, die mit mehreren Hub-VPC-Netzwerken verknüpft sind. Jedes Hub-VPC-Netzwerk ist über VPC-Netzwerk-Peering mit mehreren VPC-Netzwerken verknüpft. Der Traffic zwischen zwei beliebigen VPC-Netzwerken wird über den zentralen Pool von virtualisierten Appliances geleitet.

  • Mehrere Netzwerkschnittstellen mit VPC-Netzwerk-Peering kombinieren. Bei diesem Ansatz werden die beiden vorherigen Optionen kombiniert, um die Skalierbarkeit zu erhöhen. Mehrere Netzwerkschnittstellen sind mit mehreren Hub-VPC-Netzwerken verknüpft, von denen jede über VPC-Netzwerk-Peering mit mehreren Spoke-VPC-Netzwerken verbunden ist. Für jedes Hub-and-Spoke-VPC-Netzwerk verwenden Sie denselben Ansatz wie im VPC-Netzwerk-Peering-Fall beschrieben.

    Diese Topologie ist im folgenden Diagramm dargestellt.

    Topologie des Hub-and-Spoke-Ansatzes mit VPC-Netzwerk-Peering.

    Das vorstehende Diagramm zeigt ein Hub-VPC-Netzwerk, das über VPC-Netzwerk-Peering mit mehreren VPC-Netzwerken verbunden ist. Der Traffic wird über den zentralisierten Pool virtualisierter Appliances mit einer Netzwerkschnittstelle im Hub-Netzwerk weitergeleitet.

Anhand des folgenden Entscheidungsbaums können Sie den besten Ansatz für das Anhängen von Netzwerksegmenten wählen.

Entscheidungsbaum für die Auswahl der besten Methode zum Anhängen von Netzwerksegmenten.

Die Verwendung mehrerer Netzwerkschnittstellen – der erste Ansatz, der in den vorherigen Fällen vorgestellt wurde – ist der einfachste Ansatz zur Implementierung.

Die Verwendung mehrerer Netzwerkschnittstellen hat jedoch die folgenden Nachteile:

  • Sie sind auf acht Netzwerkschnittstellen pro VM-Instanz beschränkt. Wenn Sie eine Netzwerkschnittstelle für die Internetverbindung und eine für lokale Verbindungen verwenden, können Sie nur sechs Netzwerksegmente in Google Cloud verbinden. Einige Appliances erfordern eine zusätzliche Verwaltungsoberfläche, die Sie auf 5 Netzwerksegmente beschränkt.
  • Nachdem eine Instanz erstellt wurde, können Sie keine Netzwerkschnittstellen hinzufügen oder entfernen.

Die Verwendung von VPC-Netzwerk-Peering bietet folgende Vorteile:

  • Sie können bis zum Limit für VPC-Netzwerk-Peering-Verbindungen aus einem einzelnen VPC-Netzwerk hochskalieren. Wenden Sie sich an das Google Cloud-Vertriebsteam, wenn Sie Fragen zur Erhöhung dieses Limits haben.
  • Das Einrichten von VPC-Netzwerk-Peering erleichtert das Hinzufügen oder Entfernen von VPC-Netzwerken aus dieser Architektur.

Die Verwendung von VPC-Netzwerk-Peering hat jedoch folgende Nachteile:

  • Dieser Ansatz ist etwas komplexer als der Ansatz, der mehrere Netzwerkschnittstellen verwendet.
  • Die Anzahl der VPCs, die verbunden werden können, ist im Vergleich zum kombinierten Ansatz weiterhin begrenzt.

Der kombinierte Ansatz – mehrere Netzwerkschnittstellen und VPC-Netzwerk-Peering – bietet folgende Vorteile:

  • Dies ist der skalierbarste Ansatz, weil das Limit ein Produkt der Beschränkung von Netzwerkschnittstellen und der Grenze von VPC-Peering-Verbindungen ist. Sie können beispielsweise 6 Hub-VPC-Netzwerke mit separaten Netzwerkschnittstellen verbinden, wobei jede Schnittstelle 25 Spoke-VPC-Netzwerkverbindungen haben. Dadurch gilt ein Limit von 150 VPC-Netzwerken, die Traffic durch eine Gruppe virtueller Appliances übertragen.

Dieser Ansatz hat jedoch den folgenden Nachteil:

  • Die Implementierung ist der komplexeste Ansatz.

Beispielarchitekturen

Es folgt zwei Beispielarchitekturen. Die erste Beispielarchitektur zeigt, wie der interne TCP/UDP-Load-Balancer für Hochverfügbarkeit verwendet wird, und wird mit VPC-Netzwerk-Peering für das Anhängen von Netzwerksegmenten kombiniert. Die zweite Beispielarchitektur, ein spezieller Anwendungsfall, zeigt, wie Sie Traffic von einem einzelnen freigegebenen VPC-Netzwerk in Google Cloud an eine lokale Umgebung und zum Internet weiterleiten.

Beispielarchitektur mit VPC-Netzwerk-Peering und internem TCP/UDP-Load-Balancer als nächsten Hop

Diese Architektur ist ein typischer Anwendungsfall für Unternehmensumgebungen. Dabei wird der interne TCP/UDP-Load-Balancer für Hochverfügbarkeit verwendet, in Kombination mit dem VPC-Netzwerk-Peering zum Anhängen von Netzwerksegmenten.

Das folgende Diagramm zeigt die Topologie dieser Architektur.

Topologie der Verwendung von VPC-Netzwerk-Peering und internem TCP/UDP-Load-Balancer als nächsten Hop.

Das obige Diagramm zeigt ein Hub-VPC-Netzwerk und mehrere Spoke-VPC-Netzwerke, die über VPC-Netzwerk-Peering mit dem Hub-VPC-Netzwerk verbunden sind. Das Hub-VPC-Netzwerk hat zwei Instanzen einer virtuellen Appliance in einer verwalteten Instanzgruppe hinter einem internen TCP/UDP-Load-Balancer. Eine statische Standardroute verweist auf den internen TCP/UDP-Load-Balancer als nächsten Hop. Diese wird mithilfe von benutzerdefinierten Routen über das VPC-Netzwerk-Peering exportiert. Die Standardroute zum Internet-Gateway in den Spoke-VPC-Netzwerken wird gelöscht.

Sie haben folgende Möglichkeiten, die Anforderungen zu erfüllen:

  • Die Verbindung zwischen Spokes wird automatisch durch die Firewall weitergeleitet, da VPC-Netzwerk-Peering nicht transitiv ist und daher Spoke-VPC-Netzwerke Daten nicht direkt austauschen können. Sie können die virtuellen Appliances so konfigurieren, dass sie die Bedingungen und Richtlinien festlegen, unter denen die Spokes Traffic austauschen können.
  • Die Internetverbindung ist nur über die virtuellen Appliances möglich, da die Standardroute zum Internet-Gateway aus den Spoke-VPC-Netzwerken entfernt wurde. Die virtuellen Appliances verfügen über eine Standardroute über eine separate Netzwerkschnittstelle, die im Fall eines NGFW als nicht vertrauenswürdig markiert werden kann.
  • Die Verbindung zu lokalen Netzwerken erfolgt über ein Konnektivitäts-VPC-Netzwerk, das über eine separate Netzwerkschnittstelle mit der virtuellen Appliance verbunden ist. Eine Cloud-VPN- oder Cloud Interconnect-Verbindung wird in diesem Konnektivitäts-VPC-Netzwerk beendet.
  • Hochverfügbarkeit wird durch benutzerdefinierte Systemdiagnosen für den internen Load-Balancer erreicht. Sie können Appliances mithilfe des Failovers für das interne TCP/UDP-Load-Balancing als aktiv/passiv konfigurieren. Dies gewährleistet, dass der Traffic immer über eine einzige virtuelle Appliance geleitet wird.

Sie können diese Beispielarchitektur verwenden, wenn die Kommunikation zwischen den verschiedenen VPC-Netzwerken nur über TCP/UDP erfolgt. Er kann bis zu dem Limit von VPC-Netzwerk-Peering-Verbindungen pro VPC-Netzwerk skaliert werden.

Eine Beispielimplementierung dieser Architektur mit einem NAT-Gateway als virtuelle Appliance finden Sie unter Zentrale VM-basierte Appliances mithilfe des internen TCP/UDP-Load-Balancers als nächsten Hop bereitstellen. Zum Bereitstellen anderer virtueller Appliances können Sie dasselbe Muster verwenden, wie im vorherigen Abschnitt Anwendungsfälle beschrieben.

Besonderer Anwendungsfall mit einem freigegebenen VPC-Netzwerk in Google Cloud

Bei einer speziellen Verwendung muss kein Traffic zwischen verschiedenen VPC-Netzwerken über die virtuellen Appliances geleitet werden. Stattdessen wird nur der Traffic von einem einzelnen freigegebenen VPC-Netzwerk an eine lokale Umgebung und das Internet weitergeleitet. Sie können diesen Anwendungsfall implementieren, indem Sie für die Konnektivität mit dem gemeinsam genutzten VPC-Netzwerk, lokal und Google Cloud eine der zuvor in diesem Dokument beschriebenen Hochverfügbarkeitsoptionen kombiniert mit jeweils einer Netzwerkschnittstelle verwenden. Wenn Sie Einblick in den Traffic zwischen Subnetzen erhalten möchten, ohne ihn über zentralisierte Appliances auszuführen, kann die Paketspiegelung hilfreich sein.

Diese Topologie ist im folgenden Diagramm dargestellt.

Topologie eines besonderen Anwendungsfalls mit einem freigegebenen VPC-Netzwerk in Google Cloud.

Das obige Diagramm zeigt den Traffic von einem einzelnen freigegebenen VPC-Netzwerk, der über ein Pool virtueller Appliances an das lokale Netzwerk und zum Internet weitergeleitet wird.

Implementierung einer Architektur mit virtuellen Appliances

Wählen Sie zum Implementieren einer Architektur, die virtuelle Appliances verwendet, eine Option für Hochverfügbarkeit aus und kombinieren Sie sie mit einer Option zum Anhängen von Netzwerksegmenten.

Für die folgenden Optionskombinationen sind Implementierungsanleitungen verfügbar:

In den vorherigen Anleitungen werden NAT-Gateways als Anwendungsfall für die Appliance verwendet. Sie können das Gateway jedoch mithilfe eines der anderen Anwendungsfälle anpassen.

Wenn Sie eine Appliance von einem Google Cloud-Partner bereitstellen möchten, z. B. über den Cloud Marketplace, wenden Sie sich an Ihren Appliance-Anbieter oder suchen Sie auf der Website des Anbieters nach Richtlinien zur Bereitstellung derer Appliances in Google Cloud.

Nächste Schritte