Erreichbarkeit messen

Auf dieser Seite wird beschrieben, wie Konnektivitätstests die Erreichbarkeit messen. Außerdem wird erläutert, wie die Konfigurationsanalyse und die Analyse der Live-Datenebene funktioniert.

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.

Beachten Sie die folgenden Aspekte dazu, wie Konnektivitätstests die Erreichbarkeit messen:

  • Konnektivitätstests messen 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 messen die Erreichbarkeit für ein bestimmtes Protokoll und einen bestimmten Zielport. Die Tatsache, dass VM1 VM2 auf tcp:443 erreichen kann, bedeutet nicht, dass sie die VM2 auch unter tcp:80 erreichen kann.
  • Konnektivitätstests testen nur Google Cloud-VPC-Netzwerkkonfigurationen, die sich auf die Paketübermittlung 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 Status 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 umfassen zwei Hauptkomponenten: eine Konfigurationsanalyse und die Analyse der Live-Datenebene. 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 durch, bei der die Google Cloud-Ressourcen in Ihrem Testpfad anhand eines idealen Konfigurationsmodells bewertet werden. Er wird durch das Analysefeature der Live-Datenebene erweitert, das Pakete sendet, um den Status der Datenebene zu prüfen und Referenzinformationen für unterstützte 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. Sie haben beispielsweise 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:
    • Einen VM-Instanznamen
    • Eine Quell-IP-Adresse
    • Einen App Engine-Quelldienst
    • Eine Cloud Function-Umgebung (1. Generation)
    • Ein Cloud Run-Dienst
    • Einen Cloud SQL-Instanznamen
    • Einen Clusternamen für eine GKE-Steuerungsebene
  • Einen Zielendpunkt, der aus einem der folgenden Werte und einer Portnummer besteht:
    • Einen VM-Instanznamen
    • Eine Ziel-IP-Adresse
    • Einen Cloud SQL-Instanznamen
    • Einen Clusternamen für eine GKE-Steuerungsebene
    • Ein Private Service Connect-Endpunkt

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 Netzwerkprotokolle werden für VM, IP-Adresse und von Google verwaltete Dienste unterstützt:

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

Die folgenden Netzwerkprotokolle werden von Connectors für Serverloser VPC-Zugriff unterstützt:

  • TCP
  • UDP

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 state 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 Status der Konfigurationsanalyse.

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üfungsmechanismus für die Analyse der Live-Datenebene bezieht das Gastbetriebssystem nicht mit ein und ist für den Nutzer vollkommen 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.

Nächste Schritte