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 Live-Datenebenenanalyse 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 führen Konnektivitätstests auch eine Analyse der Live-Datenebene durch. 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 das Feature unterstützt wird, enthält jeder von Ihnen ausgeführte Test ein Analyseergebnis 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 verwenden Konnektivitätstests eine abstrakte Zustandsmaschine, um zu modellieren, wie ein VPC-Netzwerk Pakete verarbeiten soll.Google Cloud verarbeitet ein Paket in mehreren logischen Schritten.
Die Analyse kann viele mögliche Wege nehmen
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 die Konfigurationsanalyse den Trace-Traffic zwischen zwei Compute Engine-Instanzen simuliert – eine links und eine rechts.
Die Analyse hängt von Ihrer Netzwerkinfrastruktur ab.
Je nach Konfiguration Ihres Google Cloud -Netzwerks und Ihrer Ressourcen kann dieser Traffic über einen Cloud VPN-Tunnel, ein VPC-Netzwerk, einen Google Cloud -Load-Balancer oder ein Peering-VPC-Netzwerk geleitet werden, bevor er die Compute Engine-Zielinstanz erreicht.
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 Konnektivitätstests beispielsweise mehrere Routen gemäß der Routenpriorität abgleichen, kann Google Cloud eine Route aus mehreren Routen basierend auf einer nicht angegebenen Hash-Funktion auf der Datenebene auswählen. Wenn eine richtlinienbasierte Route konfiguriert ist, leitet der Konnektivitätstest das Paket an den nächsten Hop weiter, der ein interner Load Balancer ist.
Im vorherigen Fall gibt der Trace von Konnektivitätstests alle möglichen Routen zurück, kann aber nicht die Methode bestimmen, die Google Cloud zum Zurückgeben der Routen verwendet hat. Das liegt daran, dass diese Methode intern für Google Cloudist und sich ändern kann.
Von Google verwaltete Dienste
Von Google verwaltete Dienste wie Cloud SQL und die Google Kubernetes Engine (GKE) weisen Kunden Ressourcen in Projekten und VPC-Netzwerken zu, die Google gehören und von Google verwaltet werden. Kunden sind nicht berechtigt, auf diese Ressourcen zuzugreifen.
Die Konfigurationsanalyse von Konnektivitätstests kann weiterhin einen Test ausführen und ein Gesamtergebnis zur Erreichbarkeit für von Google verwaltete Dienste liefern. Sie liefert jedoch keine Details zu den getesteten Ressourcen im Google-Projekt.
Das folgende Diagramm zeigt ein Modell dafür, wie die Konfigurationsanalyse den Trace-Traffic von einer Compute Engine-Instanz in einem Kunden-VPC-Netzwerk zu einer Cloud SQL-Instanz im Google-eigenen VPC-Netzwerk simuliert. 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 Firewallregeln für ausgehenden Traffic 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 liefert die Analyse jedoch nur ein Gesamtergebnis zur Erreichbarkeit. 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.
So analysieren Konnektivitätstests die Live-Datenebene
Bei der Analyse der Live-Datenebene wird die Konnektivität getestet, indem mehrere TCP- oder UDP-Prüfpakete vom Quellendpunkt an das Ziel gesendet werden. Wenn das Ziel keineGoogle Cloud -Ressource ist, wird die Verbindung zwischen dem Quellendpunkt und dem Edge-Standort des Netzwerks getestet.
Die Analyseergebnisse der Live-Datenebene zeigen 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 zugestellten Prüfungen 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 Prüfungen gesendet und die Ergebnisse für jeden Google-Netzwerk-Edge-Router angezeigt, über den der Traffic möglicherweise weitergeleitet wird.
Die Analyse der Live-Datenebene deckt möglicherweise nicht alle Netzwerkpfade ab:
- Wenn der Zielendpunkt ein Google Cloud Load Balancer mit mehreren Backends ist, wird jede Analyseprüfung der Live-Datenebene an ein zufälliges Backend gesendet. Einige Back-Ends können von vielen Prüfungen getestet werden, während andere Back-Ends möglicherweise überhaupt nicht getestet werden.
- Beim ECMP-Routing (Equal Cost Multipath) wird jede Analyseprüfung der Live-Datenebene über eine zufällige Route weitergeleitet. Einige Routingpfade können von vielen Prüfungen getestet werden, während andere Routingpfade möglicherweise überhaupt nicht getestet werden.
- Die Anzahl der Prüfungen für die Analyse der Live-Datenebene hängt nicht von der Anzahl der vorhandenen Netzwerkpfade ab. Möglicherweise gibt es nicht genügend Prüfungen 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 Endpunkte
In den Tabellen in den folgenden Abschnitten sind die Quell- und Zielendpunkte zusammengefasst, die von Konnektivitätstests unterstützt werden. Informationen zu den Netzwerkkonfigurationen und -funktionen vonGoogle Cloud , die bei Konnektivitätstests analysiert werden, finden Sie unter Unterstützte Netzwerkkonfigurationen.
Quellendpunkte
In der folgenden Tabelle sind die Quellendpunkte zusammengefasst, die von der Konfigurations- und Live-Datenebenenanalyse von Konnektivitätstests unterstützt werden.
| Quellendpunkt | Konfigurationsanalyse | Analyse der Live-Datenebene |
|---|---|---|
| Compute Engine-VM-Instanz | (nur für laufende Instanzen) |
|
| Steuerungsebene des GKE-Clusters | ||
| GKE-Pod | ||
| Cloud Run-Dienst | 1 | |
| Cloud Run-Job | 1 | |
| Cloud Run Functions (1. Generation) | 1 | |
| App Engine-Standardumgebung | 1 | |
| Cloud SQL-Instanz | ||
| Private Verbindung von Database Migration Service | ||
| Interne IP-Adresse in einem VPC-Netzwerk2 | (nur für unterstützte Google Cloud -Ressourcen) |
|
| Externe IP-Adresse3 | (nur für unterstützte Google Cloud -Ressourcen) |
|
| Interne IP-Adresse in einem Nicht-Google Cloud -Netzwerk (verbunden mit einem VPC-Netzwerk über Cloud Interconnect, Cloud VPN oder Router-Appliance) |
Für Quellendpunkte gelten die folgenden zusätzlichen Überlegungen:
- Für Compute Engine-VM-Instanzen wird die Analyse der Live-Datenebene nur für ausgeführte Instanzen unterstützt. Es wird nicht unterstützt, wenn der Quell- und der Zielendpunkt dieselbe VM-Instanz sind.
- Für GKE-Cluster-Steuerungsebenen und Cloud SQL-Instanzen unterstützt Konnektivitätstests nur Endpunkte, die Private Service Connect nicht verwenden.
- Cloud Run Functions, früher Cloud Functions (2nd gen), wird nicht unterstützt. Sie können jedoch die Konnektivität von einer Cloud Run-Funktion testen, indem Sie einen Konnektivitätstest für die zugrunde liegende Cloud Run-Version erstellen. Bei jeder Bereitstellung einer Cloud Run-Funktion wird eine Cloud Run-Überarbeitung erstellt.
Zielendpunkte
In der folgenden Tabelle sind die Zielendpunkte zusammengefasst, die von der Konfigurations- und Live-Datenebenenanalyse von Konnektivitätstests unterstützt werden.
| Zielendpunkt | Konfigurationsanalyse | Analyse der Live-Datenebene |
|---|---|---|
| Compute Engine-VM-Instanz | (nur für laufende Instanzen) |
|
| Steuerungsebene des GKE-Clusters | (nur für interne IP-Adressen) |
|
| GKE-Pod | ||
| Interner und externer Application Load Balancer | ||
| Interne und externe Proxy-Network-Load-Balancer | ||
| Interner Passthrough-Network Load Balancer | ||
| Externer Passthrough-Network Load Balancer | ||
| Private Service Connect-Endpunkt | (nur für veröffentlichte Dienste mit einem internen Passthrough-Network-Load-Balancer des Erstellers) |
|
| Cloud SQL-Instanz | (nur für interne IP-Adressen) |
|
| Memorystore for Redis-Instanz | ||
| Memorystore for Redis Cluster | ||
| Interne IP-Adresse in einem VPC-Netzwerk1 | (nur für unterstützte Google Cloud -Ressourcen) |
|
| Externe IP-Adresse2 | (nur für Internet-IP-Adressen und unterstützte Google Cloud-Ressourcen) |
|
| Interne IP-Adresse in einem Nicht-Google Cloud -Netzwerk (über Cloud Interconnect mit einem VPC-Netzwerk verbunden) | ||
| Interne IP-Adresse in einem Nicht-Google Cloud -Netzwerk (über Cloud VPN oder Router-Appliance mit einem VPC-Netzwerk verbunden) |
Für Zielendpunkte gelten die folgenden zusätzlichen Überlegungen:
- Für Compute Engine-VM-Instanzen wird die Analyse der Live-Datenebene nur für ausgeführte Instanzen unterstützt. Es wird nicht unterstützt, wenn der Quell- und der Zielendpunkt dieselbe VM-Instanz sind.
- Konnektivitätstests unterstützen externe Cloud SQL-Serverreplikate, die durch IP-Adressen definiert sind.
- Bei Internet-IP-Adressen und internen IP-Adressen in einem Nicht-Google Cloud -Netzwerk, das über Cloud Interconnect verbunden ist, wird die Konnektivität bis zum Netzwerk-Edge-Standort bzw. VLAN-Anhang für Cloud Interconnect getestet.
Überlegungen und Einschränkungen
Berücksichtigen Sie die folgenden Überlegungen, wenn Sie entscheiden, ob Konnektivitätstests verwendet werden sollen.
- Die von Konnektivitätstests durchgeführte Konfigurationsanalyse basiert vollständig auf Konfigurationsinformationen für Google Cloud -Ressourcen und spiegelt möglicherweise nicht den tatsächlichen Zustand oder Status der Datenebene für ein VPC-Netzwerk wider.
- Konnektivitätstests erfassen zwar einige dynamische Konfigurationsinformationen, z. B. den Status des Cloud VPN-Tunnels und dynamische Routen, die sich auf dem Cloud Router befinden, greifen jedoch nicht auf den Zustand der internen Produktionsinfrastruktur und der Datenebenenkomponenten von Google zu und verwalten diesen auch nicht.
- Der Status
Packet could be deliveredfür einen Konnektivitätstest garantiert nicht, dass Traffic die Datenebene passieren 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 kein Firewall-Verbindungs-Tracking, 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 nicht das Testen des Firewall-Verbindungstrackings.
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 sind, dass sie in der Datenebene als Router, Firewalls, NAT-Gateways oder VPNs fungieren. Diese Art von Konfiguration erschwert die Bewertung der Umgebung, die auf der Compute Engine-Instanz ausgeführt wird. Außerdem wird diese Art von Testszenario von der Analyse der Live-Datenebene nicht 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.
| 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 zu Diagnosezwecken einmalig ü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.