Konnektivität zu Google Cloud-Load-Balancern testen

Auf dieser Seite werden häufige Szenarien zum Testen der Konnektivität zu Google Cloud-Load-Balancern beschrieben.

Die Konfigurationsanalyse der Konnektivitätstests unterstützt das Tracing simulierter Pakete für alle Arten von Google Cloud-Load-Balancern. Der Trace-Pfad für einen externen Application Load Balancer gilt auch für externe Proxy-Network Load Balancer. Weitere Informationen finden Sie in der Übersicht über Cloud Load Balancing.

Im folgenden Beispiel führen Konnektivitätstests ein Tracing eines simulierten Pakets von einem externen Host zu einer virtuellen IP-Adresse (VIP) für einen externen Application Load Balancer durch. Die TCP-Verbindung vom externen Host wird beim Proxy für den externen Application Load Balancer beendet. Der externe Application Load Balancer initiiert dann eine neue TCP-Verbindung zu einer VM, die als Load-Balancer-Back-End dient.

Ein typischer Trace-Pfad zu einem externen Application Load Balancer.
Typischer Trace-Pfad zu einem externen Application Load Balancer

Für Trace-Diagramme auf dieser Seite werden die in der folgenden Legende beschriebenen Symbole verwendet.
Symbol Name Bedeutung
Graue Raute
Grafik: Legende für das Paket-Trace-Diagramm: graue Raute.
Logo: Check Point Ein Entscheidungspunkt, an dem Konnektivitätstests eine Konfiguration prüfen und entscheiden, ob ein Trace-Paket weitergeleitet, zugestellt oder verworfen werden soll.
Blaues Rechteck
Legende für das Paket-Trace-Diagramm: blaues Rechteck.
Hop Ein Schritt im Weiterleitungspfad für ein Trace-Paket, das eine Google Cloud-Ressource darstellt, die ein Paket an den nächsten Hop in einem VPC-Netzwerk weiterleitet (z. B. zu einem Cloud Load Balancing-Proxy oder zu einem Cloud VPN-Tunnel).
Orangefarbenes Sechseck
Legende für das Paket-Trace-Diagramm: orangefarbenes Sechseck.
Endpunkt Die Quelle oder das Ziel eines Trace-Pakets.

Im folgenden Trace-Pfad stellt die Konfigurationsanalyse der Konnektivitätstests drei Traces bereit, einen für jeden möglichen Pfad zu den drei Load-Balancer-Back-Ends. Das liegt daran, dass sie nur Konfigurationen und nicht die Live-Datenebene prüft.

Paket-Trace zu einem externen Application Load Balancer.
Paket-Trace zu einem externen Application Load Balancer

Erfolgreicher Test in einem Load-Balancer

Dieser Abschnitt beschreibt ein Beispiel für einen erfolgreichen Test des zuvor beschriebenen externen Application Load Balancers.

In der eigentlichen Datenebene wählt der Load-Balancer-Algorithmus für jede Back-End-Verbindung eine VM-Instanz aus. Da es in diesem Beispiel drei Load-Balancer-Back-Ends gibt, können Sie im Menü Trace-Auswahl auf dem Bildschirm Ergebnisse das gewünschte Trace auswählen.

Das folgende erfolgreiche Testergebnis bestätigt, dass alle folgenden Google Cloud-Ressourcen für den externen Application Load Balancer korrekt konfiguriert sind:

  • Weiterleitungsregel
  • Die Load-Balancer-Back-Ends, einschließlich der Fähigkeit des Load-Balancers, Systemdiagnosen erfolgreich an diese Back-Ends zu senden
  • Proxyverbindung
  • VPC-Firewallregeln

Dieses Ergebnis bestätigt, dass ein simuliertes Paket von einer externen IP-Adresse die Back-End-VM-Instanzen erfolgreich erreichen kann:

Ein detailliertes Beispiel für ein Trace zu allen drei Back-Ends finden Sie unter Ungültige oder inkonsistente Konfigurationen erkennen.

Beispielausgabe für einen erfolgreichen Test an einen externen Application Load Balancer.
Beispielausgabe für einen erfolgreichen Test an einen externen Application Load Balancer

Auch wenn Sie keine Berechtigung zum Prüfen der Google Cloud-Ressourcen im Netzwerkpfad für den externen Application Load Balancer haben, werden in der Google Cloud Console dennoch weiterhin Ergebnisse angezeigt, einschließlich erfolgreicher Ergebnisse. Auf der Karte für jede getestete Ressource wird jedoch "Sie sind nicht berechtigt, die Ressource in PROJECT_NAME anzusehen" angezeigt.

Test, der eine fehlende Firewallregel für eine Systemdiagnose anzeigt

Ein Load-Balancer-Trace prüft viele derselben zuvor beschriebenen Google Cloud-Ressourcenkonfigurationen. Wenn die folgenden Load-Balancer-Ressourcen jedoch falsch konfiguriert sind, zeigt die Analyse das Ergebnis Paket konnte verworfen werden (der endgültige Zustand des Trace ist Drop).

Das folgende Testergebnis zeigt, dass die Firewallregeln für eingehenden Traffic des VPC-Netzwerks keine Systemdiagnose für die Load-Balancer-Back-Ends zulassen. Dadurch sind die Back-Ends für den Load-Balancer nicht verfügbar.

Beispielausgabe für eine fehlende Firewallregel
Beispielausgabe für eine fehlende Firewallregel

Zusätzlich zu ungültigen VPC-Firewallregeln finden Sie in der folgenden Tabelle häufige Konfigurationsprobleme, die von Konnektivitätstests für Google Cloud Load-Balancer erkannt werden. Zur Behebung dieser Probleme verwenden Sie die in der Tabelle dargestellten Lösungen.

Konfigurationsproblem Lösung
Die Eingabeparameter stimmen nicht mit dem Protokoll oder Port überein, den Sie in der Weiterleitungsregel für den Load-Balancer definiert haben. Ändern Sie vor dem Testen den Eingabeparameter so, dass er mit dem Protokoll oder Port übereinstimmt, den Sie in der Weiterleitungsregel definiert haben.
Für die Weiterleitungsregel für den Load-Balancer sind keine Back-Ends konfiguriert. Konfigurieren Sie vor dem Testen die Back-Ends für den Load-Balancer.
Der Load-Balancer hat ungültige oder inkonsistente Konfigurationen. Korrigieren Sie vor dem Testen die ungültigen oder inkonsistenten Konfigurationen.
Der Traffic kann keinen internen Passthrough-Network-Load-Balancer mit einer nicht übereinstimmenden Region erreichen, da der interne Passthrough-Network-Load-Balancer ein regionaler Dienst ist. Vor dem Testen konfigurieren Sie die Komponenten des Load-Balancers, damit diese sich in derselben Region befinden.

Nächste Schritte