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 Laufzeitprüfung 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 VPC-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.

Für einige Verbindungsszenarien wird bei Konnektivitätstests auch eine Laufzeitprüfung ausgefü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 das Feature unterstützt wird, gibt jeder ausgeführte Test ein dynamisches Prüfungsergebnis aus.

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

Beim Analysieren von Netzwerkkonfigurationen verwenden Konnektivitätstests eine abstrakte Netzwerkzustandsmaschine, um zu modellieren, wie ein VPC-Netzwerk Pakete verarbeiten soll. Google Cloud verarbeitet ein Paket in mehreren logischen Schritten.

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, in dem die Konfigurationsanalyse den Trace-Traffic zwischen zwei Compute Engine-VM-Instanzen simuliert: eine auf der linken und eine auf der rechten Seite.

Abhängig von Ihrem Google Cloud-Netzwerk und Ihren Ressourcenkonfigurationen wird dieser Traffic möglicherweise durch einen Cloud-VPN-Tunnel, einen Google Cloud-Load-Balancer oder ein Peering-VPC-Netzwerk geleitet, bevor die Ziel-VM-Instanz erreicht wird.

Die abstrakte Netzwerkzustandsmaschine
Die abstrakte Netzwerkzustandsmaschine

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 entsprechend der Routenpriorität zuordnen, kann Google Cloud eine Route unter mehreren Routen anhand einer nicht angegebenen Hash-Funktion in der Datenebene auswählen.

Im vorherigen Fall gibt das Trace von Konnektivitätstests alle möglichen Routen zurück, kann jedoch nicht bestimmen, mit welcher Methode Google Cloud die Routen zurückgibt. Dies liegt daran, dass diese Methode Google Cloud-intern ist und Änderungen unterliegen kann.

Von Google verwaltete Dienste

Von Google verwaltete Dienste wie Cloud SQL und Google Kubernetes Engine (GKE) weisen Ressourcen für Kunden in Projekten und VPC-Netzwerken zu, die Google besitzt und verwaltet. Kunden sind nicht berechtigt, auf diese Ressourcen zuzugreifen.

Die Konfigurationsanalyse der Konnektivitätstests kann trotzdem testen und ein Gesamtergebnis zur Erreichbarkeit für von Google verwaltete Dienste liefern. Details zu den getesteten Ressourcen im Google-Projekt werden jedoch nicht geliefert.

Das folgende Diagramm zeigt ein Modell dazu, wie die Konfigurationsanalyse Trace-Traffic von einer VM-Instanz in einem VPC-Netzwerk eines Kunden zu einer Cloud SQL-Instanz im Google-VPC-Netzwerk simuliert. In diesem Beispiel sind die Netzwerke über VPC-Netzwerk-Peering verbunden.

Vergleichbar einem Standardtest zwischen zwei VMs werden in logischen Schritten die Firewallregeln für den relevanten ausgehenden Traffic geprüft und mit der Route abgeglichen. Beim Testen stellt die Konfigurationsanalyse der Konnektivitätstests Details zu diesen Schritten bereit. Für den letzten logischen Schritt der Analyse der Konfiguration im Google-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 aufzurufen.

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 Netzwerkstatusmaschine für von Google verwaltete Dienste

Unterstützte Konfigurationen

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

Trafficflüsse

  • VM-Instanzen zum und vom Internet
  • VM-Instanz zu VM-Instanz
  • Von Google Cloud zu und von lokalen Netzwerken
  • Zwischen zwei lokalen Netzwerken, die über das Network Connectivity Center verbunden sind

VPC-Netzwerkfeatures

Sie können die Konnektivität zwischen Ressourcen testen, die die folgenden Features verwenden:

Google Cloud Hybrid-Netzwerklösungen

Die folgenden Hybrid-Netzwerklösungen werden unterstützt:

Network Connectivity Center

Network Connectivity Center wird unterstützt.

Cloud NAT

Cloud NAT wird unterstützt.

Cloud Load Balancing

  • Die Konnektivität zu den folgenden Google Cloud-Load-Balancern wird unterstützt: externe HTTP(S)-Load-Balancer, Netzwerk-Load-Balancer, interne HTTP(S)-Load-Balancer, interne TCP/UDP-Load-Balancer, TCP-Proxy-Load-Balancer und SSL-Proxy-Load-Balancer.
  • Die Konnektivität zu IP-Adressen des Load Balancers wird unterstützt.
  • Die Konnektivität von Systemdiagnosen für Cloud Load Balancing mit Back-Ends wird unterstützt. Back-Ends können Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs) sein.

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

Google Kubernetes Engine (GKE)

  • Die Verbindung zu und zwischen GKE-Knoten und der GKE-Steuerungsebene wird unterstützt.
    • Beim Testen der privaten IP-Adresse einer GKE-Steuerungsebene bestimmt die Konfigurationsanalyse für Konnektivitätstests, ob das Paket an die Steuerungsebene zugestellt werden kann. Das schließt die Analyse der Konfiguration im Google-VPC-Netzwerk ein.
    • Beim Testen der öffentlichen IP-Adresse einer GKE-Steuerungsebene bestimmt die Konfigurationsanalyse der Konnektivitätstests, ob das Paket an das Google-VPC-Netzwerk gesendet werden kann, in dem die Steuerungsebene ausgeführt wird. Die Analyse der Konfiguration innerhalb des Google-VPC-Netzwerks ist nicht eingeschlossen.
  • Die Konnektivität zu dem GKE-Dienst über Cloud Load Balancing wird unterstützt.
  • Die Verbindung zu einem GKE-Pod in einem VPC-nativen Cluster wird unterstützt.

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

Andere Google Cloud-Produkte und -Dienste

Die folgenden zusätzlichen Google Cloud-Produkte oder -Dienste werden unterstützt:

  • Cloud SQL-Instanzen werden unterstützt.
    • Beim Testen der privaten IP-Adresse einer Cloud SQL-Instanz bestimmt die Konfigurationsanalyse, ob das Paket an die Instanz zugestellt werden kann. Das schließt die Analyse der Konfiguration im Google-VPC-Netzwerk ein.
    • Beim Testen der öffentlichen IP-Adresse einer Cloud SQL-Instanz bestimmt die Konfigurationsanalyse, ob das Paket an das Google-VPC-Netzwerk gesendet werden kann, in dem die Instanz ausgeführt wird. Die Analyse der Konfiguration innerhalb des Google-VPC-Netzwerks ist nicht eingeschlossen.

Nicht unterstützte Konfigurationen

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

  • Google Cloud Armor-Richtlinien werden beim Tracing der Konnektivität zu einer externen IP-Adresse des HTTP(S)-Load-Balancers nicht berücksichtigt oder verwendet.
  • GKE-Netzwerkrichtlinie. Konnektivitätstests enthalten keine Netzwerkrichtlinien, wenn die Konnektivität zu IP-Adressen in GKE-Clustern verfolgt wird.
  • Ein externer HTTP(S)-Load-Balancer, der Cloud Storage-Buckets verwendet, wird nicht unterstützt.

So analysieren Konnektivitätstests die Live-Datenebene

Das Feature der dynamischen Prüfung testet die Konnektivität. Dazu werden mehrere Trace-Pakete vom Quellendpunkt an das Ziel gesendet. In den Ergebnissen der dynamischen Prüfung sehen Sie die Anzahl der gesendeten Prüfungen, die das Ziel erfolgreich erreicht haben, und den Erreichbarkeitsstatus. Dieser Status wird anhand der Anzahl der erfolgreich zugestellten Prüfungen ermittelt, wie in der folgenden Tabelle dargestellt.

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

Die dynamische Prüfung zeigt nicht nur an, wie viele Pakete erfolgreich zugestellt wurden, sondern auch Informationen zum Medianwert und zum 95. Perzentil der Einweg-Latenz.

Die dynamische Prüfung hängt nicht von der Konfigurationsanalyse ab. Die dynamische Prüfung bietet stattdessen eine unabhängige Bewertung des Verbindungsstatus.

Wenn es deutliche Diskrepanzen zwischen der Konfigurationsanalyse und den Ergebnissen der dynamischen Überprüfung gibt, lesen Sie die Informationen unter Fehlerbehebung bei Konnektivitätstests.

Unterstützte Konfigurationen

Die dynamische Prüfung unterstützt die folgenden Netzwerkkonfigurationen.

Trafficflüsse

  • VM-Instanz zu VM-Instanz
  • IP-Protokolle: TCP, UDP

VPC-Netzwerkfeatures

Sie können die Konnektivität zwischen Ressourcen mit den folgenden Features dynamisch prüfen:

Nicht unterstützte Konfigurationen

Konfigurationen, die nicht explizit als "unterstützt" aufgeführt sind, werden nicht unterstützt. Konfigurationen, bei denen Verbindungen durch Firewallregeln für ausgehenden Traffic blockiert werden, werden ebenfalls nicht unterstützt.

Wenn bei einem bestimmten Test das Feature der dynamischen Prüfung nicht ausgeführt wird, wird im Feld Ergebnis der letzten Paketübertragung der Wert N/A oder - angezeigt.

Hinweise

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

Die Konfigurationsanalyse, die von den Konnektivitätstests ausgeführt wird, basiert vollständig auf Konfigurationsinformationen für Google Cloud-Ressourcen und spiegelt möglicherweise nicht den tatsächlichen Zustand oder den Status der Datenebene eines VPC-Netzwerks wider.

Während Konnektivitätstests einige dynamische Konfigurationsinformationen wie den Cloud VPN-Tunnelzustand und dynamische Routen auf Cloud Router abrufen, wird nicht auf den Integritätszustand der internen Produktionsinfrastruktur und Datenebenenkomponenten von Google zugegriffen oder dieser beibehalten.

Der Packet could be delivered-Status für einen Konnektivitätstest garantiert nicht, dass Traffic durch die Datenebene geleitet werden 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 werden die Ergebnisse der Konfigurationsanalyse durch die Ergebnisse der dynamischen Prüfung ergänzt. Dazu wird geprüft, 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 der Konnektivitätstests unterstützt kein Tracking von Firewall-Verbindungen, da sich die Tabelle der Firewall-Verbindungen in der Datenebene für eine VM-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 dynamische Prüfung unterstützt nicht das Testen des Trackings von Firewallverbindungen.

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

Konnektivitätstests können keine VM-Instanzen testen, die für die Ausführung in der Datenebene als Router, Firewalls, NAT-Gateways, VPNs usw. konfiguriert wurden. Diese Art der Konfiguration macht es schwierig, die auf der VM-Instanz ausgeführte Umgebung zu bewerten. Darüber hinaus wird dieses Testszenario nicht von der dynamischen Prüfung 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 der VPC-Netzwerkkonfiguration und der Anzahl der von Ihnen 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 VM-Instanzen, einen Cloud VPN-Tunnel und Google Cloud-Load-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 dynamische Prüfung ist nicht für kontinuierliches Monitoring vorgesehen.

Die dynamische Prüfung führt eine einmalige Prüfung der Netzwerkverbindung zu Diagnosezwecken durch. Für ein kontinuierliches Monitoring von Konnektivität und Paketverlusten verwenden Sie das Dashboard zur Leistungsüberwachung.

Bei der dynamischen Prüfung werden nicht mehrere Traces getestet

Die dynamische Prüfung wird nicht unterstützt, wenn die Route nicht deterministisch ist.

Was ist Erreichbarkeit?

Eine Ressource ist von einem anderen Endpunkt aus erreichbar, wenn Netzwerkkonfigurationen wie Firewalls und Routen den Traffic von einem Netzwerk zum anderen erlauben. Wenn die Netzwerkkonfiguration beispielsweise VM1 das Senden von Paketen an VM2 erlauben soll, wird VM2 als von VM1 erreichbar bezeichnet.

Konnektivitätstests misst die Erreichbarkeit von einer bestimmten Quelle zu einem bestimmten Ziel. Die Tatsache, dass VM1 VM2 erreichen kann, bedeutet nicht unbedingt, dass VM3 VM2 erreichen kann.

Konnektivitätstests misst die unidirektionale Erreichbarkeit. Die Tatsache, dass VM1 eine Verbindung zu VM2 öffnen kann, bedeutet nicht, dass VM2 eine Verbindung zu VM1 öffnen kann. Firewallregeln lassen möglicherweise Traffic in eine Richtung zu, aber nicht in die andere.

Konnektivitätstests misst die Erreichbarkeit für ein bestimmtes Protokoll und einen bestimmten Zielport. Die Tatsache, dass VM1 VM2 über tcp:443 erreichen kann, bedeutet nicht, dass es VM2 auch über tcp:80 erreichen kann.

Konnektivitätstests testet nur Google Cloud VPC-Netzwerkkonfigurationen, die sich auf die Paketbereitstellung von der Quelle zum Ziel auswirken können. Es wird nicht geprüft, ob ein gültiger Server am Ziel ausgeführt wird, ob Firewallregeln des Betriebssystems den Traffic blockieren können oder ob ein Sicherheitsprogramm ein Paket mit einer Virennutzlast blockiert.

Das Konzept der Erreichbarkeit stammt aus der Graphentheorie. Im Prinzip enthält der gesamte Erreichbarkeitsgraph eines Netzwerks alle Endpunkte als Knoten und Richtungskanten, die die Erreichbarkeit von Quellknoten zu Zielknoten angeben.

Erreichbarkeitsanalyse ist ein allgemeinerer Begriff, der eine Reihe von Analysen beschreibt, die durchgeführt werden können, um die Erreichbarkeit des Netzwerks zu bestimmen. Einer der Anwendungsfälle einer Erreichbarkeitsanalyse ist ein Konnektivitätstest. Konnektivität bezieht sich in diesem Fall auf den Zustand der Netzwerkverbindungen.

Für jeden Schritt auf dem Netzwerkweiterleitungspfad wird eine Erreichbarkeitsanalyse getestet und Ergebnisse für die zugrunde liegende Netzwerkkonfiguration bereitgestellt. Beispielsweise analysiert Konnektivitätstests die Google Cloud-Firewallregeln und -Routen, die auf ein simuliertes Testpaket angewendet werden.

Funktionsweise von Konnektivitätstests

Konnektivitätstests bestehen aus zwei Hauptkomponenten: Konfigurationsanalyse und dynamische Prüfung. In diesem Abschnitt wird die Funktionsweise dieser beiden Arten von Analysen erläutert.

Funktionsweise von Konfigurationsanalysen

In diesem Abschnitt wird beschrieben, wie Konnektivitätstests und ihre Komponenten funktionieren.

Konnektivitätstests führen eine Erreichbarkeitsanalyse aus, mit der die Google Cloud-Ressourcen in Ihrem Testpfad anhand eines idealen Konfigurationsmodells bewertet werden. Sie werden um das Feature der dynamischen Prüfung erweitert, das Pakete sendet, um den Status der Datenebene zu prüfen und Basisinformationen zu unterstützten Konfigurationen bereitzustellen. Ausführliche Informationen zur Funktionsweise der dynamischen Prüfung finden Sie unter Funktionsweise von Analysen der Live-Datenebene.

Als Netzwerkadministrator haben Sie die Kontrolle über viele Konfigurationen, die sich auf das Analyseergebnis auswirken können. Allerdings gibt es auch Ausnahmen. Beispielsweise haben Sie keine Kontrolle über VPC-Netzwerke, in denen von Google verwaltete Dienste wie Cloud SQL-Instanzen gehostet werden. Außerdem haben Sie aufgrund von Berechtigungseinschränkungen möglicherweise keine Kontrolle über Firewallrichtlinienregeln, die sich auf Ihr Netzwerk auswirken.

Wenn Sie einen Konnektivitätstest ausführen, geben Sie einen bestimmten Parametersatz ein und erhalten formatierte Ergebnisse in Form eines Netzwerk-Trace oder einer Abfrage. Ein Konnektivitätstest erstellt mehr als einen Trace, wenn ein Test mehrere mögliche Pfade im Netzwerk hat. Beispiel: Der Zielendpunkt ist ein Google Cloud-Load-Balancer mit mehreren Back-Ends.

  • Eine Übereinstimmung bedeutet, dass Konnektivitätstests eine Google Cloud-Konfiguration finden, mit der das simulierte Paket den Testpfad durchlaufen kann.
  • Keine Übereinstimmung bedeutet, dass Konnektivitätstests keine Übereinstimmung finden können. Daher existiert die Konfiguration nicht.
  • Eine verweigerte Übereinstimmung bedeutet, dass Konnektivitätstests eine Google Cloud-Konfiguration finden, in der das simulierte Testpaket verworfen werden muss.

Komponenten von Konnektivitätstests

Ein Konnektivitätstest ist die Komponente der obersten Ebene, die alle anderen Testunterkomponenten enthält, die für die Konfigurationsanalyse erforderlich sind. Diese Komponenten sind:

  • Quell- und Zielendpunkte
  • Details zur Erreichbarkeit für den Test und seine Traces, einschließlich eines mit der Konfigurationsanalyse ermittelten Gesamtergebnisses zur Erreichbarkeit.
  • Ein oder mehrere Traces, die jeweils einen oder mehrere Schritte enthalten
  • Ein Zustand für jeden Schritt

Jeder Test hat einen eindeutigen Namen und jedem Schritt sind ein Zustand und Info-Metadaten zugeordnet. Wenn ein Schritt beispielsweise eine Route prüft, sind RouteInfo-Metadaten in diesem Schritt enthalten.

Das folgende Diagramm zeigt einen Test von einer Compute Engine-VM-Instanz zu einer anderen. Beschreibungen der Testkomponenten finden Sie in den folgenden Abschnitten.

Zustandsautomat für ein VM-zu-VM-Trace
Zustandsautomat für ein VM-zu-VM-Trace

Quell- und Zielendpunkte

Die Konfigurationsanalyse der Konnektivitätstests unterstützt einen 5-Tupel-Paketheader ohne Quellport. Dies liegt daran, dass der Quellport nicht zum Prüfen von Ressourcen in Google Cloud-Netzwerkkonfigurationen verwendet wird. Daher müssen Sie ihn beim Ausführen von Tests nicht angeben.

Der Paket-Header enthält die folgenden Komponenten:

  • Ein Netzwerkprotokoll
  • Einen Quellendpunkt, der aus einem der folgenden Elemente besteht:
    • Eine Quell-IP-Adresse
    • Einen VM-Instanznamen
    • Einen Clusternamen für eine GKE-Steuerungsebene
    • Einen Cloud SQL-Instanznamen
  • Einen Zielendpunkt, der aus einem der folgenden Werte und einer Portnummer besteht:
    • Eine Ziel-IP-Adresse
    • Einen VM-Instanznamen
    • Einen Clusternamen für eine GKE-Steuerungsebene
    • Einen Cloud SQL-Instanznamen

Sie können auch einen Google Cloud-Netzwerktyp oder einen Google Cloud-fremden Netzwerktyp oder eine Kombination aus einem Netzwerktyp und einer IP-Adresse oder einem VM-Instanznamen angeben, um einen Netzwerkstandort eindeutig zu identifizieren.

Die folgenden Zielprotokolle werden für alle unterstützten Google Cloud-Ressourcen unterstützt:

  • TCP
  • UDP
  • ICMP
  • ESP
  • AH
  • SCTP
  • IPIP

Zielports für die TCP- oder UDP-Protokolle werden unterstützt. Wenn Sie keinen Port angeben, ist die Standardeinstellung Port 80.

Traces, Schritte und Zustände

Die Konfigurationsanalyse enthält ein oder mehrere Traces. Jedes Trace repräsentiert einen eindeutigen simulierten Paketweiterleitungspfad in einem Test.

  • Jedes Trace enthält mehrere geordnete Schritte.
  • Jeder Schritt enthält einen Zustand zur Google Cloud-Konfiguration, die Konnektivitätstests für diesen Schritt prüfen.
  • Zustände werden in nicht endgültige und endgültige Zustände kategorisiert.
Nicht endgültige Zustände

Nicht endgültige Zustände stehen für eine Konfigurationsprüfung für jede Google Cloud-Ressource im Testpfad, z. B. eine VM-Instanz, ein Endpunkt, eine Firewallregel, eine Route oder einen Google Cloud-Load-Balancer.

Es gibt vier nicht endgültige Zustände:

  • Start
  • Konfigurationsprüfung
  • Weiterleiten
  • Übergang

Weitere Informationen finden Sie unter Testzustände

Endgültiger Zustand

Jedes Trace muss mit einem endgültigen Zustand enden, der der letzte Schritt in dem Trace ist.

Es gibt vier mögliche endgültige Zustände:

  • Drop
  • Abort
  • Forward
  • Deliver

Jedem Zustand ist ein Grund zugeordnet. Weitere Informationen finden Sie in den Details zu jedem endgültigen Zustand.

Gesamtergebnis zur Erreichbarkeit

Die Konfigurationsanalyse liefert auch ein Gesamtergebnis zur Erreichbarkeit, das einen der folgenden vier Werte haben kann: Reachable, Unreachable, Ambiguous oder Undetermined.

Die Kenntnis des Gesamtergebnisses zur Erreichbarkeit kann hilfreich sein, um Monitoring oder Automation einzurichten.

Weitere Informationen finden Sie unter Gesamtergebnis zur Erreichbarkeit.

Spoof-Prüfung

Konnektivitätstests führen eine Spoof-Prüfung durch, wenn ein simuliertes Paket an oder von einer VM-Instanz eine IP-Adresse verwendet, die dieser Instanz nicht gehört. Zu den IP-Adressen einer VM gehören alle internen und sekundären IP-Adressen der VM.

Wenn die Adresse scheinbar aus externem Traffic stammt (auch als fremde Adresse bezeichnet), besteht die IP-Adresse die Spoof-Prüfung nicht.

Metadaten

Jedem Zustand können Metadaten in Form eines Info-Felds zugeordnet sein. Beispielsweise enthält InstanceInfo Details für eine VM-Instanz, einschließlich Name und IP-Adresse.

Die Konfigurationsanalyse liefert Metadaten für den Test selbst und Metadaten für jeden Schritt in einem Test.

Funktionsweise von Analysen der Live-Datenebene

Der Prüfmechanismus für die dynamische Prüfung umfasst nicht das Gastbetriebssystem und ist für den Nutzer vollständig transparent. Prüfungen werden im Namen des Quellendpunkts in das Netzwerk eingefügt und kurz vor der Zustellung an den Zielendpunkt verworfen. Prüfungen werden von der regulären Netzwerkabrechnung, Telemetriemesswerten und Flusslogs ausgeschlossen.

Unterstützung von VPC Service Controls (Vorschau)

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