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 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 Analyse der Live-Datenebene 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 Analyseergebnis der Live-Datenebene aus.
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
Beim Analysieren 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 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, in dem die Konfigurationsanalyse den Trace-Traffic zwischen zwei Compute Engine-Instanzen simuliert: eine auf der linken und eine auf der rechten Seite.
Die Analyse hängt von Ihrer Netzwerkinfrastruktur ab.
Abhängig von Ihrem Google Cloud Netzwerk und Ihren Ressourcenkonfigurationen wird dieser Traffic möglicherweise durch einen Cloud VPN-Tunnel, ein VPC-Netzwerk, einen Google Cloud Load Balancer oder ein Peering-VPC-Netzwerk geleitet, bevor die Ziel-Compute Engine-Instanz erreicht wird.
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 entsprechend der Routenpriorität zuordnen, Google Cloud kann eine Route unter mehreren Routen anhand einer nicht angegebenen Hash-Funktion in der Datenebene ausgewählt werden. Wenn eine richtlinienbasierte Route konfiguriert ist, leitet der Connectivity Test das Paket an den nächsten Hop weiter, der ein interner Load Balancer ist.
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ückgegeben werden. 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 Compute Engine-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.
Ähnlich einem Standardtest zwischen zwei Compute Engine-Instanzen 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.
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:
- Compute Engine-Instanz
- Cloud Run-Überarbeitung
- Cloud Run Functions (1. Generation)
- App Engine-Standardumgebung
- Cloud SQL-Instanz
- GKE-Steuerungsebene
- Internet-IP-Adresse
- IP-Adresse aus einem lokalen Netzwerk
- IP-Adresse einer Compute Engine-Instanz
- IP-Adresse einer Cloud SQL-Instanz
- IP-Adresse einer GKE-Steuerungsebene
- Nicht zugewiesene IP-Adresse in einem Virtual Private Cloud-Netzwerk
Zielendpunkte
Die Konfigurationsanalyse der Konnektivitätstests unterstützt die folgenden Zielendpunkte:
- Compute Engine-Instanz
- Cloud SQL-Instanz
- GKE-Steuerungsebene
- Externe und interne Application Load Balancer
- Externe und interne Proxy-Network Load Balancer
- Externer und interner Passthrough-Network Load Balancer
- Private Service Connect-Endpunkt
- Memorystore for Redis Cluster
- Memorystore for Redis-Instanz
- Internet-IP-Adresse
- IP-Adresse aus einem lokalen Netzwerk
- IP-Adresse einer Weiterleitungsregel
- IP-Adresse einer Compute Engine-Instanz
- IP-Adresse einer Cloud SQL-Instanz
- IP-Adresse einer GKE-Steuerungsebene
- IP-Adresse eines Memorystore for Redis-Clusters
- IP-Adresse einer Memorystore for Redis-Instanz
Google Cloud Netzwerkfunktionen
Sie können die Konnektivität zwischen Ressourcen testen, die die folgenden Features verwenden (sowohl IPv4 als auch IPv6 werden unterstützt, sofern zutreffend):
- VPC-Netzwerke
- VPC-Netzwerk-Peering
- Freigegebene VPC
- Privater Google-Zugriff
- Cloud Load Balancing
- Alias-IP-Bereiche
- Privat verwendete öffentliche IPv4-Adressen
- Compute Engine-Instanzen mit mehreren Netzwerkschnittstellen
- VPC-Routing
- VPC-Firewallregeln
- Regionale Netzwerk-Firewallrichtlinien
- Hierarchische Firewallrichtlinien und globale Netzwerk-Firewallrichtlinien
- Resource Manager-Tags für Firewalls, auch wenn sie an Compute Engine-Instanzen mit mehreren Netzwerkschnittstellen angehängt sind
- Richtlinienbasierte Routen
- Private Service Connect
- Instanzen mit IPv6-Adressen, einschließlich Instanzen mit mehreren Netzwerkschnittstellen
- VPC- und Hybrid-Spokes für Network Connectivity Center
- Public NAT und Private NAT
- Cloud VPN
- Cloud Interconnect
- Cloud Router, einschließlich dynamischer Routen, die BGP- und statische Routen verwenden
Hinweise zu Cloud Load Balancing
Für Cloud Load Balancing unterstützt die Konfigurationsanalyse von Konnektivitätstests die folgenden Funktionen:
- Konnektivität zu den IP-Adressen des Load Balancers testen
- Konnektivität von Systemdiagnosen für Cloud Load Balancing mit Back-Ends prüfen
- Interne TCP/UDP-Load-Balancer können als nächste Hops verwendet werden
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 zu Google Kubernetes Engine
Für GKE unterstützt die Konfigurationsanalyse der Konnektivitätstests die folgenden Funktionen:
- Verbindung zu und zwischen GKE und der GKE-Steuerungsebene
- Konnektivität zum GKE-Dienst über Cloud Load Balancing
Die Verbindung zu einem GKE-Pod in einem VPC-nativen Cluster wird unterstützt. Einige GKE-Netzwerkfunktionen wie GKE-Netzwerkrichtlinien werden jedoch nicht unterstützt.
Informationen zu nicht unterstützten GKE-Features finden Sie im Abschnitt Nicht unterstützte Konfigurationen.
Ü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 von 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:
- Informationen zur externen Konnektivität finden Sie unter IP-Adressen.
- Informationen zur Verbindung über einen Connector für Serverloser VPC-Zugriff finden Sie unter Serverlosen Traffic an ein VPC-Netzwerk senden.
- Informationen zur Konnektivität über ausgehenden Direct VPC-Traffic finden Sie unter IP-Adressenzuweisung. Dieser Verbindungstyp ist nur für Cloud Run verfügbar.
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 Features finden Sie im Abschnitt Nicht unterstützte Konfigurationen.
Nicht unterstützte Konfigurationen
Die Konfigurationsanalyse der Konnektivitätstests unterstützt keine Tests der folgenden Netzwerkkonfigurationen:
- Firewallrichtlinien-Regeln mit Standortobjekten, Threat Intelligence-Daten oder FQDN-Objekten werden nicht unterstützt. Wenn solche Firewalls einen bestimmten Traffic-Fluss beeinträchtigen können, wird von Konnektivitätstests eine entsprechende Warnung zurückgegeben.
- Internet-NEG-Backends, die auf FQDNs ausgerichtet sind, werden nicht unterstützt. Internet-NEG-Backends, die auf IP-Adressen ausgerichtet sind, werden jedoch unterstützt.
- Cloud Service Mesh-Load Balancer mit den Weiterleitungsregeln
INTERNAL_SELF_MANAGEDwerden nicht unterstützt. - Google Cloud Armor-Richtlinien werden beim Tracing der Konnektivität zu einer externen IP-Adresse des Application Load Balancers nicht berücksichtigt oder verwendet.
- HA VPN-Gateways, die mit Compute Engine-Instanzen verbunden sind, werden nicht unterstützt.
- GKE-Netzwerkrichtlinien und IP-Masquerading-Konfigurationen werden beim Tracing der Konnektivität zu IP-Adressen in GKE-Clustern und -Knoten nicht berücksichtigt oder verwendet.
- Cloud SQL-Replikate für externe Server, die durch DNS-Namen definiert werden, werden nicht unterstützt. Externe Serverreplikate, die durch IP-Adressen definiert werden, werden jedoch unterstützt.
- Cloud Run Functions (2. Generation) werden nicht unterstützt. Sie können die Verbindung von einer Cloud Run-Funktion (2. Generation) jedoch 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.
- Die flexible App Engine-Umgebung wird nicht unterstützt.
- Cloud Run-Jobs werden nicht unterstützt. Weitere Informationen finden Sie unter Dienste, Jobs und Worker-Pools: drei Möglichkeiten zum Ausführen von Code.
So analysieren Konnektivitätstests die Live-Datenebene
Das Feature der Analyse der Live-Datenebene testet die Konnektivität. Dazu werden mehrere Probe-Pakete vom Quellendpunkt an das Ziel gesendet. Wenn das Ziel keine Google Cloud -Ressource ist, wird die Verbindung zwischen dem Quellendpunkt und dem Edge-Standort des Netzwerks getestet.
In den Ergebnissen der Analyse der Live-Datenebene 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 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
Bei der Analyse der Live-Datenebene werden möglicherweise nicht alle möglichen Netzwerkpfade berücksichtigt:
- Wenn der Zielendpunkt ein Google Cloud Load-Balancer mit mehreren Back-Ends ist, wird jede Live-Datenebenenanalyse-Sonde an ein zufälliges Back-End gesendet. Einige Back-Ends können mit vielen Probes getestet werden, andere möglicherweise gar nicht.
- Beim ECMP-Routing (Equal Cost Multipath) wird jede Live-Datenebenenanalyse-Sonde über eine zufällige Route weitergeleitet. Einige Routingpfade werden möglicherweise von vielen Tests abgedeckt, andere hingegen gar nicht.
- Die Anzahl der Analysen der Live-Datenebene hängt nicht von der Anzahl der vorhandenen Netzwerkpfade ab. Möglicherweise gibt es nicht genügend Analysen 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:
- Compute Engine-Instanz
- Serverloser Endpunkt, der mit einem Connector für Serverloser VPC-Zugriff konfiguriert und einer der folgenden Ressourcen zugeordnet ist:
- Cloud SQL-Instanz
- GKE-Steuerungsebene
Zielendpunkte
Die Analyse der Live-Datenebene unterstützt die folgenden Zielendpunkte:
- Compute Engine-Instanz
- Interner Passthrough-Network Load Balancer
- Private Service Connect mit einem internen Passthrough-Network Load Balancer des Erstellers
- Internet-IP-Adresse, getestet am Netzwerkrand
- VLAN-Anhang für Cloud Interconnect
- Privater Endpunkt, der einer der folgenden Ressourcen zugeordnet ist:
- Cloud SQL-Instanz
- Memorystore for Redis Cluster
- Memorystore for Redis-Instanz
- GKE-Steuerungsebene
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:
- VPC-Netzwerke
- VPC-Netzwerk-Peering
- Shared VPC
- VPC-Spokes und Hybrid-Spokes im Network Connectivity Center
- Alias-IP-Bereiche
- Externe IP-Adressen
- Interne IP-Adressen, einschließlich privat verwendeter öffentlicher IPv4-Adressen
- Compute Engine-Instanzen mit mehreren Netzwerkschnittstellen
- VPC-Routing
- Public NAT und Private NAT, mit Ausnahme von NAT64
- VPC-Firewallregeln
- Hierarchische Firewallrichtlinien, globale Netzwerk-Firewallrichtlinien und regionale Netzwerk-Firewallrichtlinien
- Sichere Tags für Firewalls, auch wenn sie an Compute Engine-Instanzen mit mehreren Netzwerkschnittstellen angehängt sind
- Richtlinienbasierte Routen
- Instanzen mit IPv6-Adressen, einschließlich Instanzen mit mehreren Netzwerkschnittstellen
Nicht unterstützte Konfigurationen
Die Analyse der Live-Datenebene wird für die folgenden Netzwerkkonfigurationen nicht unterstützt und nicht ausgeführt:
- Nicht-Google Cloud -Ressourcen als Quellendpunkte:
- Internet-IP-Adressen
- Eingehender Traffic zu Google Cloud über Cloud Interconnect, Cloud VPN und Hybrid-Spokes des Network Connectivity Center
- Nicht zugewiesene IP-Adressen in einem VPC-Netzwerk als Quellendpunkte
- Quell- und Zielendpunkte sind dieselbe Compute Engine-Instanz
- Compute Engine-Instanzen, die nicht ausgeführt werden
- Google-APIs und ‑Dienste
- Externe und interne Application Load Balancer
- Externe und interne Proxy-Network Load Balancer
- Externer Passthrough-Network Load Balancer
- Cloud VPN
- NAT64
Überlegungen und Einschränkungen
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-Netzwerk 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 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 der Konnektivitätstests unterstützt kein Tracking von Firewall-Verbindungen, da sich die Tabelle der Firewall-Verbindungen 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 Trackings von Firewallverbindungen.
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 für die Ausführung in der Datenebene als Router, Firewalls, NAT-Gateways oder VPNs konfiguriert wurden. Diese Art der Konfiguration macht es schwierig, die auf der Compute Engine-Instanz ausgeführte Umgebung zu bewerten. Außerdem wird dieses 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 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 Compute Engine-Instanzen, einen Cloud VPN-Tunnel und Google Cloud-Load-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 kontinuierliches Monitoring vorgesehen
Bei der Analyse der Live-Datenebene wird eine einmalige Prüfung der Netzwerkverbindung zu Diagnosezwecken durchgeführt. 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
ICMP-Probleme identifizieren und beheben (Anleitung)