Konnektivitätstests

Konnektivitätstests ist ein Diagnosetool, mit dem Sie die Konnektivität zwischen Netzwerkendpunkten prüfen können. Es analysiert Ihre Konfiguration und führt in einigen Fällen eine Analyse der Live-Datenebene zwischen den Endpunkten durch. Ein Endpunkt ist eine Quelle oder ein Ziel des Netzwerktraffics, z. B. eine VM, ein GKE-Cluster (Google Kubernetes Engine), eine Weiterleitungsregel für den Load-Balancer oder eine IP-Adresse im Internet.

Zur Analyse der Netzwerkkonfigurationen simulieren Konnektivitätstests den erwarteten Weiterleitungspfad eines Pakets über Ihr Virtual Private Cloud-Netzwerk (VPC), Cloud VPN-Tunnel oder VLAN-Anhänge. Konnektivitätstests können auch den Weiterleitungspfad für erwarteten eingehenden Traffic zu Ressourcen in Ihrem VPC-Netzwerk simulieren.

In einigen Konnektivitätsszenarien wird mit Konnektivitätstests auch eine Analyse der Live-Datenebene durchgeführt. Mit diesem Feature werden Pakete über die Datenebene gesendet, um die Verbindung zu prüfen und um eine grundlegende Diagnose von Latenz und Paketverlusten zu ermöglichen. Wenn die Route für die Funktion unterstützt wird, enthält jeder Test, den Sie ausführen, ein Ergebnis der Analyse der Live-Datenebene.

Informationen zum Erstellen und Ausführen von Tests für verschiedene Szenarien finden Sie unter Konnektivitätstests erstellen und ausführen.

Die API für Konnektivitätstests ist die Network Management API. Weitere Informationen finden Sie in der API-Dokumentation.

Warum Konnektivitätstests verwenden?

Konnektivitätstests können Ihnen bei der Behebung der folgenden Netzwerkverbindungsprobleme helfen:

  • Unbeabsichtigt uneinheitliche Konfigurationen
  • Veraltete Konfigurationen, die durch Migrationen oder Änderungen der Netzwerkkonfiguration verursacht werden
  • Konfigurationsfehler für eine Vielzahl von Netzwerkdiensten und -funktionen

Wenn Sie von Google verwaltete Dienste testen, können Sie mit Konnektivitätstests auch feststellen, ob es ein Problem in Ihrem VPC-Netzwerk oder im Google-VPC-Netzwerk gibt, das für die Dienstressourcen verwendet wird.

Wie Konnektivitätstests Konfigurationen analysieren

Bei der Analyse von Netzwerkkonfigurationen verwendet Konnektivitätstests eine abstrakte Zustandsmaschine, um zu modellieren, wie ein VPC-Netzwerk Pakete verarbeiten sollte.Google Cloud verarbeitet ein Paket in mehreren logischen Schritten.

Die Analyse kann viele mögliche Wege einschlagen.

Aufgrund der Vielzahl von VPC-Netzwerkdiensten und -features, die von der Konfigurationsanalyse unterstützt werden, kann ein Testpaket, das eine VPC-Netzwerkkonfiguration durchläuft, viele mögliche Pfade haben.

Das folgende Diagramm zeigt ein Modell dafür, wie bei der Konfigurationsanalyse der Trace-Traffic zwischen zwei Compute Engine-Instanzen simuliert wird – eine links und eine rechts.

Die Analyse hängt von Ihrer Netzwerkinfrastruktur ab.

Abhängig von Ihren Google Cloud Netzwerk- und Ressourcenkonfigurationen kann dieser Traffic über einen Cloud VPN-Tunnel, ein VPC-Netzwerk, Google Cloud einen Load Balancer oder ein Peering-VPC-Netzwerk geleitet werden, bevor er die Ziel-Compute Engine-Instanz erreicht.

Die abstrakte Netzwerkzustandsmaschine
Abstrakte Zustandsmaschine des Netzwerks (zum Vergrößern klicken)

Die Analyse folgt einem der vielen endlichen Zustände.

Die begrenzte Anzahl von Schritten zwischen abstrakten Zuständen, bis ein Paket zugestellt oder verworfen wurde, wird als endlicher Automat modelliert. Dieser endliche Automat kann sich jederzeit in einem von vielen endlichen Zuständen befinden und kann mehrere nachfolgende Zustände haben.

Wenn bei Konnektivitätstests beispielsweise mehrere Routen gemäß der Routenpriorität übereinstimmen, Google Cloud kann eine Route aus mehreren Routen basierend auf einer nicht angegebenen Hash-Funktion auf der Datenebene ausgewählt werden. Wenn eine richtlinienbasierte Route konfiguriert ist, leitet Connectivity Test das Paket an den nächsten Hop weiter, der ein interner Load Balancer ist.

Im vorherigen Fall gibt der Trace für Konnektivitätstests alle möglichen Routen zurück, kann aber nicht die Methode Google Cloud ermitteln, die zum Zurückgeben der Routen verwendet wurde. Das liegt daran, dass diese Methode intern für Google Cloudist und sich ändern kann.

Von Google verwaltete Dienste

Bei von Google verwalteten Diensten wie Cloud SQL und Google Kubernetes Engine (GKE) werden Ressourcen für Kunden in Projekten und VPC-Netzwerken zugewiesen, die Google gehören und von Google verwaltet werden. Kunden sind nicht berechtigt, auf diese Ressourcen zuzugreifen.

Die Konfigurationsanalyse für Konnektivitätstests kann weiterhin einen Test ausführen und ein Gesamtergebnis zur Erreichbarkeit für Google-verwaltete Dienste liefern. Sie enthält jedoch keine Details zu den getesteten Ressourcen im Projekt, das Google gehört.

Das folgende Diagramm zeigt ein Modell dafür, wie bei der Konfigurationsanalyse der Trace-Traffic von einer Compute Engine-Instanz in einem VPC-Netzwerk des Kunden zu einer Cloud SQL-Instanz im Google-eigenen VPC-Netzwerk simuliert wird. In diesem Beispiel sind die Netzwerke über VPC-Netzwerk-Peering verbunden.

Ähnlich wie bei einem Standardtest zwischen zwei Compute Engine-Instanzen umfassen die logischen Schritte das Prüfen der relevanten Egress-Firewallregeln und das Abgleichen der Route. Wenn Sie einen Test ausführen, liefert die Konfigurationsanalyse von Konnektivitätstests Details zu diesen Schritten. Für den letzten logischen Schritt der Analyse der Konfiguration im Google-eigenen VPC-Netzwerk wird jedoch nur ein Gesamtergebnis zur Erreichbarkeit bereitgestellt. Konnektivitätstests enthalten keine Details zu den Ressourcen im Google-Projekt, da Sie nicht berechtigt sind, diese anzusehen.

Weitere Informationen finden Sie in den Testbeispielen unter Verbindung zu und von Google-verwalteten Diensten testen.

Grafik: die abstrakte Netzwerkstatusmaschine für von Google verwaltete Dienste
Die abstrakte Zustandsmaschine für von Google verwaltete Dienste (zum Vergrößern klicken).

Unterstützte Konfigurationen

Die Konfigurationsanalyse der Konnektivitätstests unterstützt das Testen der in den folgenden Abschnitten beschriebenen Netzwerkkonfigurationen.

Quellendpunkte

Die Konfigurationsanalyse der Konnektivitätstests unterstützt die folgenden Quellendpunkte:

Zielendpunkte

Die Konfigurationsanalyse von Konnektivitätstests unterstützt die folgenden Zielendpunkte:

Google Cloud -Netzwerkfunktionen

Sie können die Konnektivität zwischen Ressourcen testen, die die folgenden Funktionen verwenden (sowohl IPv4 als auch IPv6 werden unterstützt, sofern zutreffend):

Hinweise zu Cloud Load Balancing

Für Cloud Load Balancing unterstützt die Konfigurationsanalyse von Konnektivitätstests die folgenden Funktionen:

  • Konnektivität zur IP-Adresse des Load Balancers testen, einschließlich der Analyse der zugrunde liegenden Ressourcen (z. B. Backend-Dienste, Backend-Buckets und Zielpools)
  • Verbindung von Cloud Load Balancing-Systemdiagnosen zu Backends prüfen
  • Statische Routen analysieren, die einen internen Passthrough-Network Load Balancer als nächsten Hop verwenden (geben Sie eine IP-Adresse aus dem IP-Adressbereich der statischen Route als Zielendpunkt an)

Informationen zu nicht unterstützten Cloud Load Balancing-Features finden Sie im Abschnitt Nicht unterstützte Konfigurationen.

Informationen dazu, wie Konnektivitätstests Backends eines Load Balancers analysieren, finden Sie unter Anzahl der Traces in einem Test zu einem Load Balancer.

Überlegungen zur Google Kubernetes Engine

Für GKE unterstützt die Konfigurationsanalyse von Konnektivitätstests die folgenden Funktionen:

Das Testen der Verbindung zu einem GKE-Dienst über Cloud Load Balancing wird unterstützt. Wenn Sie jedoch GKE-Netzwerkrichtlinien und IP-Maskierung auswerten möchten, müssen Sie Pods als Testendpunkte verwenden.

Überlegungen zu serverlosen Endpunkten

Die Quell-IP-Adressen serverloser Endpunkte sind in der Regel nicht deterministisch. Für jeden Testlauf wird von Konnektivitätstests eine zufällige IP-Adresse aus dem Pool der Adressen ausgewählt, die für den serverlosen Endpunkt verfügbar sind. Allgemeine Informationen zur Zuweisung von IP-Adressen für serverlose Endpunkte finden Sie unter:

In einigen Fällen sind ausgehender Direct VPC-Traffic und Connectors für Serverloser VPC-Zugriff so konfiguriert, dass Traffic von serverlosen Endpunkten je nach den Einstellungen für ausgehenden Traffic über externe Verbindungen anstelle des Virtual Private Cloud-Netzwerks weitergeleitet wird.

Informationen zu nicht unterstützten serverlosen Funktionen finden Sie im Abschnitt Nicht unterstützte Konfigurationen.

Nicht unterstützte Konfigurationen

Die Konfigurationsanalyse von Konnektivitätstests unterstützt keine Tests der folgenden Netzwerkkonfigurationen:

So analysieren Konnektivitätstests die Live-Datenebene

Mit dem Feature „Analyse der Live-Datenebene“ wird die Verbindung getestet, indem mehrere Prüfpakete vom Quellendpunkt zum Ziel gesendet werden. Wenn das Ziel keine Google Cloud -Ressource ist, wird die Verbindung zwischen dem Quellendpunkt und dem Edge-Standort des Netzwerks getestet.

Die Ergebnisse der Analyse der Live-Datenebene enthalten die Anzahl der gesendeten Prüfungen, die Anzahl der Prüfungen, die das Ziel erfolgreich erreicht haben, und einen Erreichbarkeitsstatus. Dieser Status wird anhand der Anzahl der erfolgreich ausgelieferten Probes ermittelt, wie in der folgenden Tabelle beschrieben.

Status Anzahl der Prüfungen, die ihr Ziel erreicht haben
Erreichbar Mindestens 95 %
Unerreichbar –
Teilweise erreichbar Mehr als 0 und weniger als 95 %

Die Analyse der Live-Datenebene zeigt nicht nur an, wie viele Pakete erfolgreich zugestellt wurden, sondern auch Informationen zum Medianwert und zum 95. Perzentil der Einweg-Latenz. Wenn das Ziel eine Internet-IP-Adresse ist, werden bei der Analyse der Live-Datenebene Probes gesendet und die Ergebnisse für jeden Google-Netzwerk-Edge-Router angezeigt, über den der Traffic möglicherweise weitergeleitet wird.

Beschränkungen

Die Analyse der Live-Datenebene deckt möglicherweise nicht alle möglichen Netzwerkpfade ab:

  • Wenn der Zielendpunkt ein Google Cloud Load Balancer mit mehreren Backends ist, wird jede Live-Datenebenenanalyse-Sonde an ein zufälliges Backend gesendet. Einige Back-Ends können mit vielen Tests getestet werden, während andere möglicherweise gar nicht getestet werden.
  • Beim ECMP-Routing (Equal Cost Multipath) wird jeder Live-Datenebenenanalyse-Probe über eine zufällige Route weitergeleitet. Einige Routingpfade können von vielen Tests geprüft werden, während andere möglicherweise gar nicht getestet werden.
  • Die Anzahl der Sonden für die Analyse der Live-Datenebene hängt nicht von der Anzahl der vorhandenen Netzwerkpfade ab. Möglicherweise gibt es nicht genügend Sonden für die Analyse der Live-Datenebene, um jeden möglichen Pfad zu testen.

Wenn es deutliche Diskrepanzen zwischen der Konfigurationsanalyse und den Ergebnissen der Analyse der Live-Datenebene gibt, lesen Sie die Informationen unter Fehlerbehebung bei Konnektivitätstests.

Unterstützte Konfigurationen

Die Analyse der Live-Datenebene unterstützt eine Teilmenge der Konfigurationen, die von der Konfigurationsanalyse der Konnektivitätstests getestet werden.

Quellendpunkte

Die Analyse der Live-Datenebene unterstützt die folgenden Quellendpunkte:

Zielendpunkte

Die Analyse der Live-Datenebene unterstützt die folgenden Zielendpunkte:

Protokolle

Die Analyse der Live-Datenebene unterstützt die TCP- und UDP-Protokolle.

Google Cloud -Netzwerkfunktionen

Die Analyse der Live-Datenebene unterstützt die folgenden Funktionen:

Nicht unterstützte Konfigurationen

Die Analyse der Live-Datenebene wird für die folgenden Netzwerkkonfigurationen nicht unterstützt und nicht ausgeführt:

Überlegungen und Einschränkungen

Berücksichtigen Sie die folgenden Überlegungen, wenn Sie entscheiden, ob Konnektivitätstests verwendet werden sollen.

  • Die Konfigurationsanalyse, die von Konnektivitätstests durchgeführt wird, basiert vollständig auf Konfigurationsinformationen für Google Cloud Ressourcen und spiegelt möglicherweise nicht den tatsächlichen Zustand der Datenebene für ein VPC-Netzwerk wider.
  • Bei Konnektivitätstests werden zwar einige dynamische Konfigurationsinformationen erfasst, z. B. der Cloud VPN-Tunnelstatus und dynamische Routen, die sich auf Cloud Router befinden. Der Gesundheitsstatus der internen Produktionsinfrastruktur und der Datenebenenkomponenten von Google wird jedoch nicht abgerufen oder verwaltet.
  • Ein Status von Packet could be delivered für einen Konnektivitätstest garantiert nicht, dass Traffic die Datenebene durchlaufen kann. Der Zweck des Tests besteht darin, Konfigurationsprobleme zu prüfen, die zu einer Unterbrechung des Traffics führen können.

Bei unterstützten Routen ergänzen die Analyseergebnisse der Live-Datenebene die Ergebnisse der Konfigurationsanalyse, indem sie testen, ob übertragene Pakete am Ziel ankommen.

Konnektivitätstests kennen keine Netzwerke außerhalb von Google Cloud

Externe Netzwerke sind so definiert:

  • Lokale Netzwerke, die sich in Ihrem Rechenzentrum oder einer anderen Einrichtung befinden, in der Sie Ihre Hardwaregeräte und Softwareanwendungen betreiben.
  • Andere Cloud-Anbieter, bei denen Sie Ressourcen ausführen.
  • Ein Host im Internet, der Traffic an Ihr VPC-Netzwerk sendet.

Konnektivitätstests führen kein Tracking von Firewall-Verbindungen durch

Das Verbindungstracking für VPC-Firewalls speichert Informationen zu neuen und hergestellten Verbindungen und ermöglicht das Zulassen oder Einschränken des nachfolgenden Traffics anhand dieser Informationen.

Die Konfigurationsanalyse von Konnektivitätstests unterstützt keine Firewall-Verbindungsüberwachung, da sich die Firewall-Verbindungstabelle in der Datenebene für eine Compute Engine-Instanz befindet und nicht zugänglich ist. Die Konfigurationsanalyse kann jedoch das Verbindungs-Tracking simulieren, indem sie eine Rückverbindung zulässt, die normalerweise von einer Firewallregel für eingehenden Traffic verweigert wird, solange Konnektivitätstests die ausgehende Verbindung initiieren.

Die Analyse der Live-Datenebene unterstützt keine Tests zur Firewall-Verbindungsüberwachung.

Konnektivitätstests können keine Compute Engine-Instanzen testen, die zum Ändern des Weiterleitungsverhaltens konfiguriert sind

Konnektivitätstests können keine Compute Engine-Instanzen testen, die so konfiguriert wurden, dass sie in der Datenebene als Router, Firewalls, NAT-Gateways oder VPNs fungieren. Bei dieser Art von Konfiguration ist es schwierig, die Umgebung zu bewerten, die auf der Compute Engine-Instanz ausgeführt wird. Außerdem wird diese Art von Testszenario nicht von der Analyse der Live-Datenebene unterstützt.

Die Ergebniszeiten von Konnektivitätstests können variieren

Die Ergebnisse der Konnektivitätstests können zwischen 30 Sekunden und 10 Minuten dauern. Die Dauer eines Tests hängt von der Größe Ihrer VPC-Netzwerkkonfiguration und der Anzahl der verwendeten Google Cloud Ressourcen ab.

Die folgende Tabelle zeigt die Antwortzeiten, die Sie für alle Nutzer erwarten können, die einen Test für eine Beispielkonfiguration in einer Abfrage ausführen. Diese Konfiguration enthält Compute Engine-Instanzen, einen Cloud VPN-Tunnel und Google CloudLoad Balancer.

Antwortzeiten pro Abfrage
Projektgröße Anzahl der Google Cloud Ressourcen Antwortlatenz
Kleines Projekt Weniger als 50 60 Sekunden für 95 % der Anfragen aller Nutzer
Mittelgroßes Projekt Mehr als 50, aber weniger als 5.000 120 Sekunden für 95 % der Anfragen aller Nutzer
Großes Projekt Größer als 5.000 600 Sekunden für 95 % der Anfragen aller Nutzer

Die Analyse der Live-Datenebene ist nicht für die kontinuierliche Überwachung gedacht

Bei der Analyse der Live-Datenebene wird die Netzwerkverbindung einmalig zu Diagnosezwecken überprüft. Für ein kontinuierliches Monitoring von Konnektivität und Paketverlusten verwenden Sie das Dashboard zur Leistungsüberwachung.

Unterstützung durch VPC Service Controls

VPC Service Controls bietet zusätzliche Sicherheit für Konnektivitätstests, um das Risiko einer Daten-Exfiltration zu verringern. Mithilfe von VPC Service Controls können Sie Projekte in Perimeterbereiche einfügen, die Ressourcen und Services vor Anfragen schützen, die ihren Ursprung außerhalb des Perimeters haben.

Weitere Informationen zu Dienstperimetern finden Sie auf der Seite Details und Konfiguration von Dienstperimetern der VPC Service Controls-Dokumentation.

Nächste Schritte