Interner Passthrough-Network-Load-Balancer als nächster Hop

Ein interner Passthrough-Network-Load-Balancer ist ein regionaler Load-Balancer, mit dem Sie Ihre Dienste hinter einer internen IP-Adresse ausführen und skalieren können. Sie können einen internen Passthrough-Network-Load-Balancer als nächsten Hop verwenden, an den Pakete entlang des Pfads zu ihrem endgültigen Ziel weitergeleitet werden. Dazu legen Sie den Load-Balancer als nächsten Hop in einer statischen Route fest.

Bevor Sie sich die Informationen auf dieser Seite ansehen, sollten Sie mit den folgenden Themen vertraut sein:

Ein interner Passthrough-Network-Load-Balancer als nächster Hop ist in den folgenden Fällen nützlich:

  • Load-Balancing von Traffic auf mehrere VMs, die als Gateway- oder Router-VMs dienen.

  • Verwenden vonvirtuellen Appliances als nächsten Hop für eine Standardroute. Bei dieser Konfiguration senden VM-Instanzen in Ihrem VPC-Netzwerk (Virtual Private Cloud) Traffic über eine Reihe von virtuellen Gateway-VMs mit Load-Balancing an das Internet.

  • Traffic über mehrere Load-Balancer in zwei oder mehr Richtungen senden, indem Sie dieselbe Gruppe von Multi-NIC-Gateway- oder Router-VMs als Back-Ends verwenden. Erstellen Sie dazu einen Load-Balancer und verwenden Sie ihn als nächsten Hop für eine statische Route in jedem VPC-Netzwerk. Jeder interne Passthrough-Network-Load-Balancer wird in einem einzelnen VPC-Netzwerk betrieben und verteilt den Traffic an die Netzwerkschnittstellen der Backend-VMs in diesem Netzwerk.

Architektur

Im folgenden Diagramm dient eine VM-Instanzengruppe von Router-VMs als Backend für zwei verschiedene Load-Balancer. Der erste interne Passthrough-Network-Load-Balancer sendet Pakete an nic0 der Backend-VMs und der zweite interne Passthrough-Network-Load-Balancer sendet Pakete an nic1 an denselben Backends.

Load-Balancing für mehrere NICs.
Load-Balancing für mehrere NICs (zum Vergrößern klicken).

Vorteile der Verwendung eines internen Passthrough-Network-Load-Balancers als nächsten Hop

Wenn der Load-Balancer ein nächster Hop für eine statische Route ist, ist in den Gastbetriebssystemen der Client-VMs im VPC-Netzwerk, in dem die Route definiert ist, keine spezielle Konfiguration erforderlich. Client-VMs senden Pakete an das Backend des Load-Balancers über VPC-Netzwerkrouting mit der Methodebump-in-the-wire.

Die Verwendung eines internen Passthrough-Network-Load-Balancers als nächsten Hop für eine statische Route bietet dieselben Vorteile wie ein eigenständiger interner Passthrough-Network-Load-Balancer. Die Systemdiagnose des Load-Balancers sorgt dafür, dass neue Verbindungen an fehlerfreie Backend-VMs weitergeleitet werden. Wenn Sie eine verwaltete Instanzengruppe als Back-End verwenden, können Sie das Autoscaling so konfigurieren, dass die Gruppe VMs je nach Dienstanforderung erweitert oder verkleinert wird.

Spezifikationen

Im Folgenden finden Sie Spezifikationen für die Verwendung eines internen Passthrough-Network-Load-Balancers als nächsten Hop.

Routen

Sie können eine statische Route erstellen, um TCP-, UDP- und anderen Protokolltraffic an einen internen Passthrough-Network-Load-Balancer zu übergeben, wobei der Load-Balancer der nächste Hop der statischen Route ist. Die Route kann ein externes (öffentlich weiterleitbares) CIDR-Präfix oder ein internes CIDR-Präfix sein, wenn das Präfix nicht mit einer Subnetzroute in Konflikt steht. So können Sie beispielsweise Ihre Standardroute 0.0.0.0/0 durch eine Route ersetzen, die Traffic zur Paketverarbeitung an Back-End-VMs von Drittanbietern weiterleitet.

Optionen zum Festlegen des nächsten Hops

Sie können einen internen Passthrough-Netzwerk-Load-Balancer als nächsten Hop angeben:

  • Name und Region der Weiterleitungsregel verwenden
  • IP-Adresse der Weiterleitungsregel verwenden

Weitere Informationen zum Projekt und zum VPC-Netzwerk, in dem sich ein interner Passthrough-Netzwerk-Load-Balancer befinden kann, finden Sie unter Nächste Hops und Features.

Sie können statische Routen mit internen Netzwerk-Load-Balancern als nächste Hops über VPC-Netzwerk-Peering austauschen. Weitere Informationen finden Sie unter Optionen für den Austausch statischer Routen.

Client-IP-Sitzungsaffinität

Interne Passthrough-Network-Load-Balancer bieten zwei ähnliche Optionen der Sitzungsaffinität für "Client-IP-Adressen":

  • Client-IP (CLIENT_IP): Ein Zwei-Tupel-Hash der Quell-IP-Adresse und der Ziel-IP-Adresse eines Pakets. Wenn ein interner Passthrough-Network-Load-Balancer nicht der nächste Hop einer Route ist, haben Pakete, die an die IP-Adresse der Weiterleitungsregel des Load-Balancers gesendet werden, eine gemeinsame Ziel-IP-Adresse: die IP-Adresse der Weiterleitungsregel. In diesem Fall bleibt eine der vom Zwei-Tupel-Hash verwendeten Adressen konstant. Wenn sich die Anzahl der konfigurierten und fehlerfreien Backends also nicht ändert und Pakete identische Quell-IP-Adressen haben, wählt diese Option für eine Zwei-Tupel-Sitzungsaffinität dasselbe Backend aus.
  • Client-IP, kein Ziel (CLIENT_IP_NO_DESTINATION): Ein-Tupel-Hash der Quell-IP-Adresse eines Pakets. Wenn Sie einen internen Passthrough-Network-Load-Balancer als nächsten Hop verwenden, variiert die Ziel-IP-Adresse häufig, da die Ziel-IP-Adressen durch das Zielattribut der Route angegebenen sind. In diesem Fall kann die Zwei-Tupel-Hash-Sitzungsaffinität Client-IP (CLIENT_IP) nicht dasselbe Backend auswählen, auch wenn sich die Anzahl der konfigurierten und fehlerfreien Backends nicht ändert und Pakete identische Quell-IP-Adressen haben. Eine Ausnahme hiervon ist, wenn nur ein Backend konfiguriert ist. Wenn Pakete mit identischen Quell-IP-Adressen an dasselbe Backend weitergeleitet werden sollen, müssen Sie die Sitzungsaffinitätsoption Client-IP, kein Ziel (CLIENT_IP_NO_DESTINATION) verwenden.

Zielbereich

Das Ziel einer statischen Route kann nicht gleich oder spezifischer als eine Subnetzroute sein. Beachten Sie, dass spezifischer bedeutet, dass die Subnetzmaske länger ist. Diese Regel gilt für alle statischen Routen, auch wenn der nächste Hop ein interner Passthrough-Network-Load-Balancer ist. Angenommen, Ihre Subnetzroute ist 10.140.0.0/20. Das Ziel einer statischen Route kann nicht identisch (10.140.0.0/20) und nicht spezifischer sein (10.140.0.0/22).

Gleiches VPC-Netzwerk und gleiche Region

Statische Routen, die interne Passthrough-Network-Load-Balancer als nächste Hops verwenden, sind auf Folgendes beschränkt:

  • Ein einzelnes VPC-Netzwerk. Der Load-Balancer und die statische Route müssen sich im selben VPC-Netzwerk befinden.

  • Eine einzelne Region oder alle Regionen. Sofern Sie keinen globalen Zugriff konfiguriert haben, ist die statische Route nur für Ressourcen in derselben Region wie der Load-Balancer verfügbar. Diese regionale Beschränkung wird erzwungen, obwohl die Route selbst Teil der Routingtabelle für das gesamte VPC-Netzwerk ist. Wenn Sie den globalen Zugriff aktivieren, ist die statische Route für Ressourcen in jeder Region verfügbar.

Statische Route bewerben

Wenn Sie das Präfix (Ziel) für die statische Route bewerben möchten, können Sie den benutzerdefinierten Advertising-Modus von Cloud Router verwenden. Der Bereich des Route Advertisement hängt von der globalen Zugriffseinstellung des Load Balancers ab:

  • Wenn der globale Zugriff deaktiviert ist, ist der interne Passthrough-Network-Load-Balancer nur für VMs, Cloud VPN-Tunnel und Cloud Interconnect-Anhänge (VLANs) verfügbar, die sich in derselben Region wie der Load-Balancer befinden. Daher ist ein benutzerdefiniertes Route Advertisement für das Präfix einer statischen Route nur sinnvoll, wenn sich der Cloud Router und der Load-Balancer in derselben Region befinden.

  • Wenn der globale Zugriff aktiviert ist, ist der interne Passthrough-Network-Load-Balancer für VMs, Cloud VPN-Tunnel und Cloud Interconnect-Anhänge (VLANs) verfügbar, die sich in einer beliebigen Region befinden. Beim globalen dynamischen Routing können lokale Systeme die statische Route aus jeder verbundenen Region verwenden.

In der folgenden Tabelle wird die Zugänglichkeit des Load-Balancers zusammengefasst.

Globaler Zugriff Dynamischer Routingmodus des VPC-Netzwerks Load-Balancer-Zugriff
Deaktiviert Regional Für Router in derselben Region zugänglich
Deaktiviert Global Für Router in derselben Region zugänglich
Aktiviert Regional Zugriff von allen Routern in beliebigen Regionen
Aktiviert Global Zugriff von allen Routern in beliebigen Regionen

Weitere Informationen finden Sie unter Interne Passthrough-Network-Load-Balancer und verbundene Netzwerke.

Reihenfolge von Vorgängen

Sie müssen einen internen Passthrough-Network-Load-Balancer erstellen, bevor Sie eine statische Route erstellen können, die ihn als nächsten Hop verwendet. Der Load-Balancer muss vorhanden sein, bevor Sie die Route erstellen. Wenn Sie versuchen, eine Route zu erstellen, die auf einen nicht vorhandenen Load-Balancer verweist, gibt Google Cloud einen Fehler zurück.

Sie können einen internen Passthrough-Network-Load-Balancer als nächsten Hop angeben. Verwenden Sie dazu den Namen der Weiterleitungsregel und die Region des Load-Balancers oder die mit der Weiterleitungsregel verknüpfte interne IP-Adresse.

Wenn Sie eine Route mit einem nächsten Hop erstellt haben, der auf einen internen Passthrough-Network-Load-Balancer verweist, können Sie den Load-Balancer erst löschen, nachdem Sie die Route gelöscht haben. Insbesondere können Sie eine interne Weiterleitungsregel erst dann löschen, wenn keine statische Route diesen Load-Balancer als nächsten Hop verwendet.

Back-End-Anforderungen

  • Sie müssen alle Back-End-VMs des internen Passthrough-Network-Load-Balancers so konfigurieren, dass die IP-Weiterleitung zugelassen wird (--can-ip-forward = True). Weitere Informationen finden Sie unter Überlegungen zu Instanzen und internen Passthrough-Network-Load-Balancern, die als nächste Hops dienen.

  • Sie können keinen internen Passthrough-Network-Load-Balancer verwenden, dessen Back-Ends GKE-Knoten (Google Kubernetes Engine) als nächster Hop für eine statische Route sind. Software auf den Knoten kann Traffic nur dann an Pods weiterleiten, wenn das Ziel mit einer vom Cluster verwalteten IP-Adresse übereinstimmt, nicht mit einem beliebigen Ziel.

TCP-, UDP- und anderen Protokoll-Traffic verarbeiten

Wenn ein interner Passthrough-Network-Load-Balancer als nächster Hop bereitgestellt wird, leitet Google Cloud den gesamten Traffic an allen Ports an die Backend-VMs weiter, unabhängig von diesen Faktoren:

  • Protokoll und Portkonfiguration der Weiterleitungsregel
  • Die Protokollkonfiguration des Backend-Dienstes

Der interne Passthrough-Network-Load-Balancer, der als nächster Hop der Route dient, unterstützt die nahtlose Weiterleitung des gesamten Traffics für Protokolle, die von Google Cloud-VPC-Netzwerken unterstützt werden (z. B. TCP, UDP und ICMP).

Weitere Überlegungen

  • Unterstützte Weiterleitungsregeln. Google Cloud unterstützt nur interne Weiterleitungsregeln für Network Load Balancer als nächsten Hop. Google Cloud unterstützt keine Weiterleitungsregeln für den nächsten Hop, die von anderen Load Balancern, Protokollweiterleitungen oder als Private Service Connect-Endpunkten verwendet werden.

  • Spezifikationsmethoden sowie das Netzwerk und Projekt für die Weiterleitungsregel. Sie können eine der folgenden Hop-Weiterleitungsregeln angeben. Die von Ihnen verwendete Spezifikationsmethode bestimmt, ob das Netzwerk der Weiterleitungsregel mit dem Netzwerk der Route übereinstimmen muss und in welchem Projekt sich die Weiterleitungsregel befinden kann:

    • Nach Weiterleitungsregelname (--next-hop-ilb) und Region (--next-hop-ilb-region): Wenn Sie eine Weiterleitungsregel als nächsten Hop nach Name und Region angeben, muss das Netzwerk der Weiterleitungsregel mit dem VPC-Netzwerk der Route übereinstimmen. Die Weiterleitungsregel muss sich in demselben Projekt befinden, das das Netzwerk der Weiterleitungsregel enthält (ein eigenständiges Projekt oder ein freigegebenes VPC-Hostprojekt).

    • Durch Weiterleitung des Links zur Weiterleitungsregelressource: Der Ressourcenlink einer Weiterleitungsregel verwendet das folgende Format: /projects/PROJECT_ID/regions/REGION/forwardingRules/FORWARDING_RULE_NAME, wobei PROJECT_ID die Projekt-ID des Projekts ist, das die Weiterleitungsregel enthält. REGION ist die Region der Weiterleitungsregel und FORWARDING_RULE_NAME ist der Name der Weiterleitungsregel. Wenn Sie eine Weiterleitungsregel für den nächsten Hop über den Ressourcenlink angeben, muss das Netzwerk der Weiterleitungsregel mit dem VPC-Netzwerk der Route übereinstimmen. Die Weiterleitungsregel kann sich in dem Projekt befinden, das das Netzwerk der Weiterleitungsregel enthält (ein eigenständiges Projekt oder ein freigegebenes VPC-Hostprojekt) oder in einem freigegebenen VPC-Dienstprojekt.

    • Durch eine die IPv4-Adresse einer Weiterleitungsregel: Wenn Sie eine Weiterleitungsregel für den nächsten Hop anhand seiner IPv4-Adresse angeben, kann das Netzwerk der Weiterleitungsregel entweder das VPC-Netzwerk der Route oder ein Peering-VPC-Netzwerk sein. Die Weiterleitungsregel kann sich in dem Projekt befinden, das das Netzwerk der Weiterleitungsregel enthält (ein eigenständiges Projekt oder ein freigegebenes VPC-Hostprojekt) oder in einem freigegebenen VPC-Dienstprojekt.

  • Auswirkungen des globalen Zugriffs. Benutzerdefinierte statische Routen, die interne Network Load Balancer als nächste Hops verwenden, werden in allen Regionen programmiert. Ob der nächste Hop verwendet werden kann, hängt von der Einstellung für den globalen Zugriff des Load-Balancers ab. Wenn der globale Zugriff aktiviert ist, ist der Load-Balancer als nächster Hop in allen Regionen des VPC-Netzwerks zugänglich. Wenn der globale Zugriff deaktiviert ist, ist der Load-Balancer als nächster Hop nur in derselben Region wie der Load-Balancer zugänglich. Wenn der globale Zugriff deaktiviert ist, werden Pakete, die aus einer anderen Region an eine Route mit einem internen Passthrough Network Load Balancer gesendet werden, verworfen.

  • Wenn alle Back-Ends fehlerhaft sind. Wenn alle Back-Ends eines internen Passthrough Network Load Balancers bei Systemdiagnosen fehlschlagen, sind die Routen, die diesen nächsten Hop verwenden, noch aktiv. Von der Route verarbeitete Pakete werden gemäß der Trafficverteilung an eines der Back-Ends des nächsten Hop-Load-Balancers gesendet.

  • Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden (--purpose=SHARED_LOADBALANCER_VIP), werden nicht unterstützt. Die Network Load Balancer des nächsten Hops und die Weiterleitungsregeln für internen Passthrough Network Load Balancer mit einer gemeinsamen IP-Adresse schließen sich gegenseitig aus. Der interne Passthrough Network Load Balancer mit nächstem Hop muss eine IP-Adresse verwenden, die für die Weiterleitungsregel des Load-Balancers eindeutig ist, damit nur ein Backend-Dienst (ein Load-Balancer) eindeutig referenziert wird. Es ist möglich, dass Weiterleitungsregeln, die eine gemeinsame interne IP-Adresse verwenden, auf verschiedene Backend-Dienste verweisen (verschiedene interne Passthrough Network Load Balancer).

  • Mehrere Routen mit denselben Zielen und Prioritäten, aber unterschiedlichen internen Passthrough Network Load Balancern für den nächsten Hop. Google Cloud verteilt Traffic nie auf zwei oder mehr interne Passthrough Network Load Balancer als nächsten Hop mit ECMP. Stattdessen wählt Google Cloud mithilfe eines deterministischen internen Algorithmus nur einen internen Passthrough Network Load Balancer als nächsten Hop aus. Zur Vermeidung dieser Mehrdeutigkeit können Sie für jede Route eindeutige Netzwerk-Tags verwenden.

    Google Cloud wählt einen einzelnen nächsten Hop aus, wenn statische Routen mit unterschiedlichen internen Passthrough Network Load Balancern als nächste Hops dieselbe Priorität und dasselbe Ziel haben.

  • Mehrere Routen mit denselben Zielen, Prioritäten und internen Passthrough Network Load Balancern für den nächsten Hop. Ohne Netzwerk-Tag können Sie in Google Cloud nicht mehrere statische Routen mit derselben Kombination aus Ziel, Priorität und internem Passthrough Network Load Balancer als nächsten Hop erstellen. Mit Netzwerk-Tags können Sie mehrere statische Routen mit derselben Kombination aus Ziel, Priorität und internem Passthrough-Network-Load-Balancer als nächsten Hop erstellen.

Anwendungsfälle

Sie können einen internen Passthrough-Network-Load-Balancer als nächsten Hop in mehreren Bereitstellungen und Topologien verwenden.

Beachten Sie für jedes Beispiel die folgenden Richtlinien:

  • Jede VM-Schnittstelle muss in einem separaten VPC-Netzwerk sein.

  • Sie können keine Backend-VMs oder Load-Balancer verwenden, um Traffic zwischen Subnetzwerken im selben VPC-Netzwerk weiterzuleiten, da Subnetzrouten nicht überschrieben werden können.

  • Der interne Passthrough-Network-Load-Balancer ist ein softwarebasierter Passthrough-Load-Balancer. Pakete werden an Backend-VMs ohne Änderungen an den Quell- oder Zielinformationen (Adressen oder Adressen und Ports) gesendet.

    Routing, Paketfilterung, Proxy und Adressübersetzung liegen in der Verantwortung der virtuellen Appliance-VMs, die als Back-Ends für den internen Passthrough-Network-Load-Balancer dienen.

Internen Passthrough-Network-Load-Balancer als nächsten Hop zu einem NAT-Gateway verwenden

Bei diesem Anwendungsfall wird der Traffic per Load-Balancing von internen VMs auf mehrere NAT-Gateway-Instanzen verteilt, die Traffic an das Internet weiterleiten.

NAT-Anwendungsfall.
NAT-Anwendungsfall (zum Vergrößern klicken).

Hub-and-Spoke: Routen mit nächstem Hop über VPC-Netzwerk-Peering austauschen

Zusätzlich zum Austausch von Subnetzrouten können Sie VPC-Netzwerk-Peering konfigurieren, um benutzerdefinierte statische und dynamische Routen zu exportieren und zu importieren. Statische Routen, die einen nächsten Hop im Standard-Internetgateway haben, werden ausgeschlossen. Benutzerdefinierte statische Routen, die interne Passthrough-Network-Load-Balancer als nächsten Hop verwenden, sind enthalten.

Sie können eine Hub-and-Spoke-Topologie mit Ihren virtuellen Firewall-Appliances mit nächstem Hop konfigurieren, die sich im hub-VPC-Netzwerk befinden. Gehen Sie dazu so vor:

  • Erstellen Sie im hub-VPC-Netzwerk einen internen Passthrough-Network-Load-Balancer mit virtuellen Firewall-Appliances als Back-Ends.
  • Erstellen Sie im hub-VPC-Netzwerk eine statische Route und legen Sie als nächsten Hop den internen Passthrough-Network-Load-Balancer fest.
  • Verbinden Sie das hub-VPC-Netzwerk mithilfe von VPC-Netzwerk-Peering mit jedem der spoke-VPC-Netzwerke.
  • Konfigurieren Sie für jedes Peering das hub-Netzwerk, um dessen benutzerdefinierten Routen zu exportieren, und konfigurieren Sie das entsprechende spoke-Netzwerk, um benutzerdefinierte Routen zu importieren. Die Route mit dem nächsten Hop des Load-Balancers ist eine der Routen, die vom hub-Netzwerk exportiert werden.

Je nach Routingreihenfolge ist der Firewall-Appliance-Load-Balancer mit nächstem Hop im VPC-Netzwerk hub in den Spoke-Netzwerken verfügbar:

  • für Clients in derselben Region wie der Load-Balancer, wenn der globale Zugriff deaktiviert ist.
  • für Clients in allen Regionen, wenn der globale Zugriff gemäß der Routingreihenfolge aktiviert ist.
Hub-and-Spoke.
Hub-and-Spoke (zum Vergrößern klicken).

Load-Balancing für mehrere NICs

Im folgenden Anwendungsfall sind die Back-End-VMs virtuelle Appliance-Instanzen (z. B. Paketinspektion, Routing oder Gateway-VMs) mit NICs in mehreren VPC-Netzwerken. Diese virtuellen Appliance-Instanzen können kommerzielle Lösungen von Drittanbietern oder Lösungen sein, die Sie selbst erstellen. Bei den virtuellen Appliances handelt es sich um Compute Engine-VMs mit mehreren NICs.

Dieses Beispiel zeigt eine einzelne Gruppe von virtuellen Backend-Appliances in einer verwalteten VM-Instanzengruppe.

Im testing-VPC-Netzwerk hat der interne Passthrough-Network-Load-Balancer eine Weiterleitungsregel namens fr-ilb1. In diesem Beispiel verteilt der Load-Balancer den Traffic an die Schnittstelle nic0.

Im production-VPC-Netzwerk hat ein anderer interner Passthrough-Network-Load-Balancer eine Weiterleitungsregel namens fr-ilb2. Dieser Load-Balancer verteilt den Traffic auf eine andere Schnittstelle; nic1 in diesem Beispiel.

Traffic mit Multi-NIC-Load-Balancing.
Traffic mit Multi-NIC-Load-Balancing (zum Vergrößern klicken).

Detaillierte Informationen zur Konfiguration finden Sie unter Load-Balancing für mehrere Backend-NICs.

Symmetrisches Hashing

Im vorherigen Beispiel wurde keine Quellnetzwerkadressübersetzung (SNAT, Source Network Address Translation) verwendet. SNAT ist nicht erforderlich, da Google Cloud symmetrisches Hashing verwendet. Das bedeutet, dass Google Cloud denselben Hash berechnet, wenn Pakete zum selben Ablauf gehören. Mit anderen Worten, der Hash ändert sich nicht, wenn Quell-IP-Adresse:port durch Ziel-IP-Adresse:port ersetzt wird.

Hinweise:

  • Symmetrisches Hashing wird ab dem 22. Juni 2021 automatisch aktiviert, wenn Sie die Weiterleitungsregel für den internen Passthrough-Network-Load-Balancer erstellen.

  • Wenn Sie symmetrisches Hashing auf vorhandenen internen Passthrough-Network-Load-Balancern aktivieren möchten, müssen Sie die Weiterleitungsregel und die Route für den nächsten Hop neu erstellen, wie unter symmetrisches Hashing aktivieren beschrieben.

  • Symmetrisches Hashing wird nur bei internen Passthrough-Network-Load-Balancern unterstützt.

  • Symmetrisches Hashing wird mit den folgenden Sitzungsaffinitätstypen für die Protokolle TCP und UDP unterstützt:

    • Client-IP (CLIENT_IP)
    • Client-IP und -Protokoll (CLIENT_IP_PROTO)
    • Client-IP, Protokoll und Port (CLIENT_IP_PORT_PROTO)

    Weitere Informationen zu diesen Einstellungen finden Sie unter Optionen für die Sitzungsaffinität.

  • Sie können SNAT optional verwenden, wenn Ihr Anwendungsfall dies aus irgendeinem Grund erfordert.

Nächste Schritte