Konnektivitätstests

Konnektivitätstests sind ein statisches Konfigurationsanalyse- und Diagnosetool, mit dem Sie die Konnektivität auf folgende Weise prüfen können:

  • Zwischen Quell- und Zielendpunkten in Ihrem VPC-Netzwerk (Virtual Private Cloud)
  • Zwischen Ihrem VPC-Netzwerk und von Google verwalteten Diensten wie Google Kubernetes Engine-Clustermastern und Cloud SQL-Instanzen (Alpha)
  • Von Ihrem VPC-Netzwerk zum und vom Internet
  • Von Ihrem VPC-Netzwerk zu und von Ihrem lokalen Netzwerk

Konnektivitätstests simulieren den erwarteten Weiterleitungspfad eines Testpakets über Ihr VPC-Netzwerk, Ihre Cloud VPN-Tunnel oder Cloud Interconnect-Anhänge zu Ihrem lokalen Netzwerk. Konnektivitätstests können auch den erwarteten eingehenden Weiterleitungspfad zu Ressourcen in Ihrem VPC-Netzwerk simulieren.

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 aufgrund einer Fehlkonfiguration helfen:

  • Inkonsistente Konfigurationen, die nicht beabsichtigt sind
  • Veraltete Konfigurationen aufgrund von Änderungen oder Migrationen der Netzwerkkonfiguration
  • Konfigurationsfehler für eine Vielzahl von Netzwerkdiensten und -funktionen

Wenn Sie von Google verwaltete Dienste (Alpha) 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

Konnektivitätstests führen eine statische Erreichbarkeitsanalyse durch, um Konfigurationen in Ihrem Google Cloud-Netzwerk zu bewerten. Diese Art der Analyse bewertet nicht die tatsächliche Datenebene.

Um diese Analyse durchzuführen, 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. Aufgrund der Vielzahl von VPC-Netzwerkdiensten und -features, die von Konnektivitätstests unterstützt werden, kann ein Testpaket, das eine VPC-Netzwerkkonfiguration durchläuft, viele mögliche Pfade haben.

Das folgende Diagramm zeigt ein Modell, das zeigt, wie die Konnektivitätstests Trace-Traffic zwischen zwei VM-Instanzen simulieren: die VM-Box links und eine andere rechts.

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 diskreten Zuständen, bis ein Paket zugestellt oder verworfen wurde, wird in Konnektivitätstests 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 (Alphaphase)

Von Google verwaltete Dienste wie Cloud SQL und 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.

Konnektivitätstests können trotzdem testen und ein Gesamtergebnis zur Erreichbarkeit für von Google verwaltete Dienste liefern. Sie bieten jedoch keine Details zu den getesteten Ressourcen im Google-Projekt.

Das folgende Diagramm zeigt ein Modell für die Simulation von Konnektivitätstests von einer VM-Instanz in einem VPC-Netzwerk eines Kunden zu einer Cloud SQL-Instanz im Google-VPC-Netzwerk. In diesem Beispiel sind die Netzwerke über VPC-Netzwerk-Peering verbunden.

Ähnlich einem Standardtest zwischen zwei VMs werden in logischen Schritten die Firewallregeln für ausgehenden Traffic des VPC-Netzwerks geprüft und die Route abgeglichen. Bei einem Test werden durch Konnektivitätstests Details zu diesen Schritten bereitgestellt. Für den letzten logischen Schritt der Analyse der Konfiguration im Google-VPC-Netzwerk liefern Konnektivitätstests 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 im Dokument Häufige Anwendungsfälle im Abschnitt Von Google verwaltete Dienste testen (Alpha).

Grafik: die abstrakte Netzwerkstatusmaschine für von Google verwaltete Dienste
Die abstrakte Netzwerkstatusmaschine für von Google verwaltete Dienste

Unterstützte Konfigurationen

Konnektivitätstests unterstützen das Testen der Netzwerkkonfigurationen, wie in den folgenden Abschnitten beschrieben.

Trafficabläufe

  • VM-Instanzen zum und vom Internet
  • VM-Instanz zu VM-Instanz
  • Von Google Cloud zu und von lokalen Netzwerken

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:

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 dem GKE-Master wird unterstützt.
    • Beim Testen der privaten IP-Adresse eines GKE-Clustermasters wird anhand der Konnektivitätstests ermittelt, ob das Paket an den Master gesendet werden kann. Das schließt die Analyse der Konfiguration im Google-VPC-Netzwerk ein. Dies ist ein Alphafeature.
    • Beim Testen der öffentlichen IP-Adresse eines GKE-Clustermasters wird anhand von Konnektivitätstests ermittelt, ob das Paket an das Google-VPC-Netzwerk gesendet werden kann, in dem der Master 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 wird geprüft, ob das Paket an die Instanz geliefert werden kann. Das schließt die Analyse der Konfiguration im Google-VPC-Netzwerk ein. Dies ist ein Alphafeature.
    • Beim Testen der öffentlichen IP-Adresse einer Cloud SQL-Instanz wird ermittelt, 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

Konnektivitätstests unterstützen das Testen der folgenden Netzwerkkonfigurationen nicht:

  • 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.
  • Konnektivitätstests werden beim Tracing der Konnektivität derzeit nicht für hierarchische Firewallrichtlinienregeln ausgewertet.
  • 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.
  • Cloud SQL-Instanzen, die öffentliche IP-Adressen verwenden, werden nicht unterstützt.

Hinweise

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

Konnektivitätstests testen Konfigurationen, nicht die Datenebene

Die statische Analyse, die durch die 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. Sie führen auch keine aktive Prüfung der Datenebene durch und messen keine Leistungsdaten wie Paketverlustrate und Latenz.

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 einigen Netzwerkproblemen können Sie anhand von Konnektivitätstests feststellen, dass das Trace-Paket zugestellt werden kann, die Netzwerkverbindung jedoch weiterhin blockiert ist. In solchen Fällen können Sie die möglichen Ursachen in der Netzwerkkonfiguration eingrenzen, um das Problem in der Netzwerkdatenebene (z. B. physische Probleme oder andere Fehler) selbst zu beheben.

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.

Konnektivitätstests unterstützen kein Tracking von Firewall-Verbindungen, da sich die Firewall-Verbindungstabelle in der Datenebene für eine VM-Instanz befindet und nicht zugänglich ist. Konnektivitätstests können jedoch das Verbindungs-Tracking simulieren, indem sie eine Rückverbindung zulassen, die normalerweise von einer Firewallregel für eingehenden Traffic verweigert wird, solange Konnektivitätstests die ausgehende Verbindung initiieren.

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.

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

Was ist Erreichbarkeit?

Erreichbarkeit ist die Möglichkeit, eine Google Cloud-Ressource zu erreichen oder festzustellen, ob ein Pfad von einer Google Cloud-Ressource zu einer anderen vorhanden ist. Dieser Begriff stammt aus der Graphentheorie für Computernetzwerke. Der gesamte Erreichbarkeitsgraph enthält alle Netzwerkendpunkte und die Erreichbarkeit zwischen zwei Netzwerkendpunkten.

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 Status der Netzwerkverbindungen.

Für jeden Schritt auf dem Netzwerkweiterleitungspfad wird eine Erreichbarkeitsanalyse getestet und Ergebnisse für die zugrunde liegende Netzwerkkonfiguration bereitgestellt. Beispielsweise analysieren Konnektivitätstests die Routen, die auf das simulierte Testpaket angewendet werden, sowie VPC-Firewallregeln. Konnektivitätstests werten derzeit keine hierarchischen Firewallrichtlinienregeln aus.

Funktionsweise von Konnektivitätstests

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

Konnektivitätstests führen eine statische Erreichbarkeitsanalyse durch, bei der die Google Cloud-Ressourcen in Ihrem Testpfad anhand eines idealen Konfigurationsmodells und nicht anhand der Live-Datenebene bewertet werden.

Als Netzwerkadministrator haben Sie die vollständige Kontrolle über alle Konfigurationen, die sich auf das Analyseergebnis auswirken können. Die einzige Ausnahme sind VPC-Netzwerke, in denen von Google verwaltete Dienste wie Cloud SQL-Instanzen gehostet werden. Beispielsweise können Sie mit der Konfiguration der Firewallregeln des VPC-Netzwerks steuern, welche Art von Traffic auf den VM-Instanzen zugelassen wird.

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. Beispiele:

  • Quell- und Zielendpunkte
  • Details zur Erreichbarkeit für den Test und seine Traces, einschließlich eines allgemeinen Erreichbarkeitsergebnisses
  • 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

Konnektivitätstests unterstützen einen 5-Tupel-Paket-Header 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 einen GKE-Master (Alpha)
    • Einen Cloud SQL-Instanznamen (Alpha)
  • Einen Zielendpunkt, der aus einem der folgenden Werte und einer Portnummer besteht:
    • Eine Ziel-IP-Adresse
    • Einen VM-Instanznamen
    • Einen Clusternamen für einen GKE-Master (Alpha)
    • Einen Cloud SQL-Instanznamen (Alpha)

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

Ein Konnektivitätstest enthält einen 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 stellen eine Konfigurationsprüfung für jede Google Cloud-Ressource im Testpfad dar, z. B. eine VM-Instanz, einen Endpunkt, eine VPC-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

Konnektivitätstests liefern auch ein Gesamtergebnis zur Erreichbarkeit, das einen von vier Werten annehmen 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.

Konnektivitätstests stellen Metadaten für den Test selbst und Metadaten für jeden Schritt in einem Test bereit.

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