Internetzugriff und Firewallregeln konfigurieren

Dieses Dokument erläutert, wie Sie folgende Aufgaben ausführen:

• Dataflow-VM-Instanzen für den Internetzugriff konfigurieren
• Verwenden Sie Tags, um das Netzwerk von Worker-VMs zu sichern.
• Firewallregeln für das mit Ihren Dataflow-Jobs verknüpfte Netzwerk definieren

Für dieses Dokument sind Grundkenntnisse über Google Cloud -Netzwerke erforderlich. Informationen zum Definieren eines Netzwerks für Ihren Dataflow-Job finden Sie unter Netzwerk und Subnetzwerk angeben. Weitere Informationen zur Fehlerbehebung bei Netzwerkproblemen finden Sie unter Fehlerbehebung bei Dataflow-Netzwerkproblemen.

Hinweis: Das Netzwerk default enthält Konfigurationen, durch die Dataflow-Jobs ausgeführt werden können. Andere Dienste können dieses Netzwerk jedoch auch verwenden. Achten Sie darauf, dass die Änderungen im Netzwerk default mit allen Ihren Diensten kompatibel sind. Erstellen Sie alternativ ein separates Netzwerk für Dataflow.

Zugriff auf Google Cloud -APIs für Dataflow

Virtuelle Maschinen (VMs) von Dataflow-Workern müssenGoogle Cloud -APIs und -Dienste erreichen. Die Gruppe der abhängigen Google Cloud -Endpunkte kann sich im Laufe der Zeit ändern, aber alle unterstützen VPC Service Controls. Verwenden Sie eine der folgenden Methoden, um den Zugriff auf Google Cloud -APIs zu konfigurieren:

• Konfigurieren Sie den privaten Google-Zugriff. Mit dem privater Google-Zugriff können VMs, die nur interne IP-Adressen haben, auf IP-Adressen für Google Cloud und Dienste zugreifen.

• Konfigurieren Sie eine IP-Adresse für den Private Service Connect-Endpunkt, um auf Google Cloud -APIs und -Dienste zuzugreifen.

• Worker-VMs mit externen IP-Adressen konfigurieren

Standardmäßig erlauben Firewallregeln und DNS-Konfigurationen den Zugriff aufGoogle Cloud -APIs. Möglicherweise schränken Sie den Zugriff auf eine Teilmenge von Google Cloud APIs aktiv ein, z. B. wenn Sie VPC Service Controls verwenden. Gewähren Sie in diesem Fall mindestens Zugriff auf restricted.googleapis.com. Wenn Sie Private Service Connect verwenden, gewähren Sie Zugriff auf das vpc-sc-Bundle. Wenn Sie Zugriff auf weniger restriktive Domains wie private.googleapis.com gewähren, wird die erforderliche Funktionalität ebenfalls bereitgestellt.

Damit der Zugriff auf die erforderlichen Google Cloud APIs über eine bestimmte Domain möglich ist, muss Ihre Umgebung die folgenden Anforderungen erfüllen:

• Firewallregeln müssen ausgehenden Traffic zu allen Adressbereichen unter der ausgewählten Domain zulassen.

• Das DNS muss *.googleapis.com in die von Ihnen ausgewählte Domain auflösen.

Wenn Ihre Firewallregeln beispielsweise ausgehenden Traffic auf den Adressbereich restricted.googleapis.com beschränken, muss *.googleapis.com in Adressen innerhalb dieses Bereichs aufgelöst werden. Weitere Informationen finden Sie unter DNS für googleapis.com konfigurieren.

Wenn Sie Private Service Connect verwenden, müssen Sie DNS-Einträge für die Standarddomain googleapis.com erstellen, um den Zugriff auf mindestens alle Dienste im vpc-sc-Bundle zu ermöglichen.

Internetzugang für Dataflow

Je nach Anwendungsfall benötigen Ihre VMs möglicherweise auch Zugriff auf Ressourcen außerhalb vonGoogle Cloud. Verwenden Sie eine der folgenden Methoden, um den Internetzugriff für Dataflow zu konfigurieren:

• Konfigurieren Sie Worker-VMs mit einer externen IP-Adresse, damit sie den Anforderungen für den Internetzugriff entsprechen.

• Konfigurieren Sie eine NAT-Lösung, z. B. Cloud NAT. Diese Option dient zum Ausführen von Jobs, die auf APIs und Dienste außerhalb von Google Cloud zugreifen, die Internetzugriff benötigen. Beispielsweise benötigen Python SDK-Jobs möglicherweise Zugriff auf den Python-Paketindex (PyPI), um Pipelineabhängigkeiten herunterzuladen. In diesem Fall müssen Sie entweder Worker-VMs mit externen IP-Adressen konfigurieren oder Cloud NAT verwenden. Sie können auch Python-Pipelineabhängigkeiten während der Jobübermittlung angeben. Sie können beispielsweise benutzerdefinierte Container verwenden, um Python-Pipelineabhängigkeiten bereitzustellen. Dadurch ist es nicht mehr erforderlich, auf PyPI zur Laufzeit zuzugreifen.

  Weitere Informationen finden Sie unter Python-Pipelineabhängigkeiten verwalten in der Apache Beam-Dokumentation.

Externe IP-Adresse deaktivieren

Standardmäßig weist Dataflow Workern sowohl externe als auch interne IP-Adressen zu. Wenn Sie externe IP-Adressen deaktivieren, kann der Dataflow-Job nur auf Ressourcen an den folgenden Orten zugreifen:

• Weitere Instanz im selben VPC-Netzwerk
• Gemeinsam genutztes VPC-Netzwerk
• Netzwerk mit aktiviertem VPC Network-Peering

Auch ohne externe IP-Adressen können Sie Verwaltungs- und Monitoringaufgaben ausführen. Wenn Sie auf Ihre Worker zugreifen möchten, verwenden Sie SSH über die oben aufgeführten Optionen. Die Pipeline kann jedoch nicht auf das Internet zugreifen und Internethosts haben keinen Zugriff auf Ihre Dataflow-Worker.

Wenn Sie keine externen IP-Adressen verwenden, können Sie die Sicherheit der Infrastruktur Ihrer Datenverarbeitung erhöhen. Sie können auch die Anzahl der externen IP-Adressen reduzieren, die Sie im Rahmen Ihres Google Cloud-Projektkontingents nutzen.

Wenn Sie externe IP-Adressen deaktivieren, können Ihre Dataflow-Jobs nicht auf APIs und Dienste außerhalb von Google Cloud zugreifen, die Internetzugriff erfordern.

Führen Sie einen der folgenden Schritte aus, um externe IP-Adressen zu deaktivieren:

Java

1. Aktivieren Sie Privaten Google-Zugriff für Ihr Netzwerk oder Subnetzwerk.
2. Geben Sie in den Parametern Ihres Dataflow-Jobs --usePublicIps=false und --network=NETWORK-NAME oder --subnetwork=SUBNETWORK-NAME an.

   Ersetzen Sie je nach Auswahl einen der folgenden Strings:

   • NETWORK-NAME ist der Name Ihres Compute Engine-Netzwerks
   • SUBNETWORK-NAME ist der Name Ihres Compute Engine-Subnetzwerks

Python

1. Implementieren Sie alle Python-Paketabhängigkeiten gemäß der Anleitung zu den Apache Beam-Pipelineabhängigkeiten.
2. Aktivieren Sie Privaten Google-Zugriff für Ihr Netzwerk oder Subnetzwerk.

3. Geben Sie in den Parametern Ihres Dataflow-Jobs --no_use_public_ips und --network=NETWORK oder --subnetwork=SUBNETWORK an.

   Ersetzen Sie je nach Auswahl einen der folgenden Strings:

   • NETWORK-NAME ist der Name Ihres Compute Engine-Netzwerks
   • SUBNETWORK-NAME ist der Name Ihres Compute Engine-Subnetzwerks

Go

1. Aktivieren Sie Privaten Google-Zugriff für Ihr Netzwerk oder Subnetzwerk.

2. Geben Sie in den Parametern Ihres Dataflow-Jobs --no_use_public_ips und --network=NETWORK oder --subnetwork=SUBNETWORK an.

   Ersetzen Sie je nach Auswahl einen der folgenden Strings:

   • NETWORK-NAME ist der Name Ihres Compute Engine-Netzwerks
   • SUBNETWORK-NAME ist der Name Ihres Compute Engine-Subnetzwerks

gcloud

1. Aktivieren Sie Privaten Google-Zugriff für Ihr Netzwerk oder Subnetzwerk.

2. Fügen Sie beim Starten des Dataflow-Jobs das Flag --disable-public-ips hinzu und geben Sie das Flag --network oder --subnetwork an. Sie können einen der folgenden Befehle verwenden:

   • gcloud dataflow jobs run
   • gcloud dataflow flex-template run
   • gcloud dataflow yaml run

   Im folgenden Beispiel wird der Befehl gcloud dataflow jobs run verwendet:

   gcloud dataflow jobs run JOB_NAME \
       --gcs-location=gs://TEMPLATE_BUCKET/templates/TEMPLATE_NAME \
       --region=REGION \
       --staging-location=gs://TEMP_BUCKET/staging \
       --network=NETWORK_NAME \
       --subnetwork=SUBNETWORK_NAME \
       --disable-public-ips
   

   Ersetzen Sie die folgenden Werte:

   • JOB_NAME: ein eindeutiger Name für Ihren Dataflow-Job.
   • TEMPLATE_BUCKET und TEMPLATE_NAME: Der Cloud Storage-Bucket und der Pfad zu Ihrer Vorlagendatei.
   • REGION: die Dataflow-Region, in der Sie den Job bereitstellen möchten, z. B. us-central1.
   • TEMP_BUCKET: der Cloud Storage-Bucket für temporäre Dateien und Binärdateien.
   • NETWORK_NAME: der Name des VPC-Netzwerks
   • SUBNETWORK_NAME: der Name oder die URL Ihres VPC-Subnetzwerks.

API

1. Aktivieren Sie Privaten Google-Zugriff für Ihr Netzwerk oder Subnetzwerk.

2. Wenn Sie Ihren Dataflow-Job oder Ihre Dataflow-Vorlage mit der Methode projects.locations.templates.launch der Dataflow REST API starten, setzen Sie im Objekt environment das Feld ipConfiguration auf WORKER_IP_PRIVATE und geben Sie network oder subnetwork an:

   POST https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/templates:launch?gcsPath=gs://TEMPLATE_BUCKET/templates/TEMPLATE_NAME
   {
     "jobName": "JOB_NAME",
     "parameters": {
       "PARAM_KEY": "PARAM_VALUE"
     },
     "environment": {
       "tempLocation": "gs://TEMP_BUCKET/temp",
       "network": "NETWORK_NAME",
       "subnetwork": "SUBNETWORK_NAME",
       "ipConfiguration": "WORKER_IP_PRIVATE"
     }
   }
   

   Ersetzen Sie die folgenden Werte:

   • PROJECT_ID: Projekt-ID in Google Cloud .
   • REGION: die Dataflow-Region, in der Sie den Job bereitstellen möchten, z. B. us-central1.
   • TEMPLATE_BUCKET und TEMPLATE_NAME: Der Cloud Storage-Bucket und der Pfad zu Ihrer Vorlagendatei.
   • JOB_NAME: ein eindeutiger Name für Ihren Dataflow-Job.
   • PARAM_KEY und PARAM_VALUE: alle Vorlagenparameter, die für Ihre Pipeline erforderlich sind.
   • TEMP_BUCKET: Der Name Ihres Cloud Storage-Bucket für temporäre Dateien.
   • NETWORK_NAME: der Name des VPC-Netzwerks
   • SUBNETWORK_NAME: die vollständige URL oder der vollständige Pfad Ihres VPC-Subnetzwerks.

   Das Feld ipConfiguration ist vom Typ WorkerIPAddressConfiguration und unterstützt die folgenden enum-Werte:

   • WORKER_IP_PRIVATE: Den Workern werden nur interne IP-Adressen zugewiesen. Öffentliche IP-Adressen sind deaktiviert. Erfordert privater Google-Zugriff.
   • WORKER_IP_PUBLIC: Workern werden sowohl öffentliche als auch interne IP-Adressen zugewiesen.
   • WORKER_IP_UNSPECIFIED: Verwendet die Standardkonfiguration (Worker erhalten sowohl öffentliche als auch interne IP-Adressen).

Tags zum Sichern des Worker-VM-Netzwerks verwenden

Mit Tags können Sie Netzwerk-Firewallregeln auf bestimmte VM-Instanzen anwenden. Wenn Sie einen Dataflow-Job ausführen, können Sie Tags für die Dataflow-Worker-VMs angeben, die den Job ausführen. Alle Firewallregeln für diese Tags werden dann auf die Dataflow-Worker-VMs angewendet.

Dataflow unterstützt zwei Arten von Tags für das VM-Netzwerk:

• Sichere Tags
• Netzwerk-Tags

Sichere Tags mit Dataflow verwenden

Sichere Tags, auch als IAM-gesteuerte Tags (Identity and Access Management) bezeichnet, sind Schlüssel/Wert-Paare, die Sie in Resource Manager erstellen und verwalten. Im Gegensatz zu Netzwerk-Tags unterstützen sichere Tags die Zugriffssteuerung mit IAM.

Die Verwendung von sicheren Tags anstelle von Netzwerktags bietet unter anderem folgende Vorteile:

• Sichere Tags verhindern die unbefugte Änderung von Tags und die daraus resultierenden unerwünschten Änderungen an Firewallregeln.

• Die globalen und regionalen Netzwerk-Firewallrichtlinien unterstützen sichere Tags. Mit sicheren Tags können Sie mehrere Firewallregeln gruppieren und gleichzeitig aktualisieren. Die Aktualisierungen unterliegen IAM-Zugriffssteuerungen.

• Sichere Tags werden von übergeordneten Ressourcen in der Google Cloud -Hierarchie übernommen. So können Sie Tags auf höheren Ebenen definieren, z. B. auf Organisationsebene. Weitere Informationen finden Sie unter Tag-Übernahme.

• Mit sicheren Tags können Firewallregeln für eingehenden Traffic Quellen in VPC-Netzwerken enthalten, die über VPC-Netzwerk-Peering verbunden sind. Bei Dataflow-Jobs bedeutet dies, dass eine Firewallregel Quellen sowohl im Worker-VM-Netzwerk als auch in Peering-VPC-Netzwerken enthalten kann.

Weitere Informationen zu den Unterschieden zwischen sicheren Tags und Netzwerktags finden Sie unter Vergleich von Tags und Netzwerktags.

So wenden Sie sichere Tags auf einen Dataflow-Job an:

1. Sichere Tags für Ihre Firewallrichtlinien konfigurieren Weitere Informationen finden Sie unter Sichere Tags konfigurieren.

2. Weisen Sie dem Dataflow-Dienstkonto für die Ressource (Tag-Werte) die Rolle Tag-Nutzer (roles/resourcemanager.tagUser) zu. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Tags für Ressourcen verwalten.

3. Verwenden Sie beim Erstellen des Dataflow-Jobs die Dienstoption use_vm_tags im folgenden Format:

Java

--dataflowServiceOptions=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

Python

--dataflow_service_options=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

Go

--dataflow_service_options=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

gcloud

Führen Sie den Befehl gcloud dataflow jobs run mit der Option additional-experiments aus. Wenn Sie flexible Vorlagen verwenden, verwenden Sie den Befehl gcloud dataflow flex-template run.

--additional-experiments=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

Netzwerk-Tags mit Dataflow verwenden

Netzwerk-Tags sind Textattribute, die Sie für Firewallregeln festlegen und an Compute Engine-VMs anhängen können. Im Gegensatz zu sicheren Tags sind Netzwerktags Textstrings. Sie sind keine Ressource, die von Resource Manager verwaltet wird.

Wenn Sie Netzwerk-Tags auf einen Dataflow-Job anwenden möchten, verwenden Sie das use_network_tags-Experiment so:

Java

--dataflowServiceOptions=use_network_tags=TAG_NAME

Python

--dataflow_service_options=use_network_tags=TAG_NAME

Go

--dataflow_service_options=use_network_tags=TAG_NAME

gcloud

Führen Sie den Befehl gcloud dataflow jobs run mit der Option additional-experiments aus. Wenn Sie flexible Vorlagen verwenden, verwenden Sie den Befehl gcloud dataflow flex-template run.

--additional-experiments=use_network_tags=TAG_NAME

Wenn Sie das Netzwerk-Tag angeben, wird auch das Standard-Netzwerk-Tag Dataflow zu Flexible Vorlage-Launcher-VMs hinzugefügt.

Ersetzen Sie TAG_NAME durch die Namen Ihrer Tags. Wenn Sie mehr als ein Tag hinzufügen, trennen Sie jedes Tag mit einem Semikolon (;) ab, wie im folgenden Format gezeigt: TAG_NAME_1;TAG_NAME_2;TAG_NAME_3;....

Nachdem ein Job gestartet wurde, können Sie ihm keine weiteren Netzwerk-Tags mehr hinzufügen.

Dataflow fügt jeder erstellten Worker-VM immer das Standard-Netzwerk-Tag dataflow hinzu.

Informationen zu den Limits für Netzwerk-Tags.

Firewallregeln für Dataflow

Mit Firewallregeln können Sie Traffic zu und von Ihren VMs zulassen oder ablehnen. Wenn Ihre Dataflow-Jobs Dataflow Shuffle oder Streaming Engine verwenden, müssen Sie nur dafür sorgen, dass Firewallregeln den Zugriff auf Google Cloud -APIs zulassen. Andernfalls müssen Sie zusätzliche Firewallregeln konfigurieren, damit Dataflow-VMs Netzwerkverkehr über den TCP-Port 12345 für Streamingjobs und über den TCP-Port 12346 für Batchjobs senden und empfangen können. Ein Projektinhaber, Projektbearbeiter oder Sicherheitsadministrator muss die erforderlichen Firewallregeln im VPC-Netzwerk erstellen, das von Ihren Dataflow-VMs verwendet wird.

Bevor Sie Firewallregeln für Dataflow konfigurieren, lesen Sie die folgenden Dokumente:

• Übersicht über VPC-Firewallregeln und VPC-Firewallregeln verwenden

• Übersicht über hierarchische Firewallrichtlinien und Hierarchische Firewallrichtlinien und -regeln verwenden

Geben Sie beim Erstellen von Firewallregeln für Dataflow die Dataflow-Netzwerk-Tags an. Andernfalls gelten die Firewallregeln für alle VMs im VPC-Netzwerk.

Gegebenenfalls werden hierarchische Firewallrichtlinien zuerst ausgewertet und diese Regeln haben Vorrang vor VPC-Firewallregeln. Wenn sich der Dataflow-Job in einem Projekt befindet, das Teil eines Ordners oder einer Organisation ist, in der hierarchische Firewallrichtlinien verwendet werden, ist die Rolle compute.orgFirewallPolicyAdmin erforderlich, um Richtlinienänderungen vorzunehmen.

Wenn Sie beim Ausführen des Pipelinecodes keine benutzerdefinierten Netzwerk-Tags erstellen, verwenden Dataflow-VMs das Standard-Tag dataflow. Wenn keine benutzerdefinierten Netzwerk-Tags vorhanden sind, erstellen Sie Firewallregeln mit dem Standard-Tag dataflow.

Wenn Sie beim Ausführen des Pipelinecodes benutzerdefinierte Netzwerk-Tags erstellen, werden diese Tags von Dataflow-VMs verwendet. Erstellen Sie die Firewallregeln mit den benutzerdefinierten Tags.

Einige VPC-Netzwerke, wie das automatisch erstellte Netzwerk default, enthalten die Regel default-allow-internal, die die Firewallanforderung für Dataflow erfüllt.

Beispiel einer Firewallregel für eingehenden Traffic

Die Firewallregel für eingehenden Traffic ermöglicht Dataflow-VMs, Pakete voneinander zu empfangen. Sie müssen immer Firewallregeln zum Zulassen von eingehendem Traffic erstellen, da der Traffic sonst immer blockiert wird, auch wenn Regeln für ausgehenden Traffic diesen Traffic zulassen.

Im folgenden Beispiel wird für Dataflow eine Firewallregel für eingehenden Traffic erstellt, wobei alle Worker-VMs das Standard-Netzwerk-Tag dataflow haben. Ein Project Owner, Editor oder Security Admin kann mit dem folgenden gcloud-Befehl eine Ingress-Zulassungsregel erstellen, die Traffic auf den TCP-Ports 12345 und 12346 von VMs mit dem Netzwerk-Tag dataflow zu anderen VMs mit demselben Tag zulässt:

gcloud compute firewall-rules create FIREWALL_RULE_NAME_INGRESS \
    --action=allow \
    --direction=ingress \
    --network=NETWORK  \
    --target-tags=CUSTOM_TAG \
    --source-tags=CUSTOM_TAG \
    --priority=PRIORITY_NUM \
    --rules tcp:12345-12346

Dabei gilt:

• FIREWALL_RULE_NAME_INGRESS ist ein Name für die Firewallregel.

• NETWORK: der Name des Netzwerks, das die Worker-VMs verwenden

• CUSTOM_TAG ist eine durch Kommas getrennte Liste von Netzwerk-Tags.

  Die folgende Liste enthält Richtlinien zur Verwendung von Netzwerk-Tags:

  • Wenn Sie --target-tags weglassen, gilt die Regel für alle VMs im VPC-Netzwerk.

  • Wenn Sie --source-tags und alle anderen Quellspezifikationen weglassen, ist Traffic von jeder Quelle zulässig.

  • Wenn Sie keine benutzerdefinierten Netzwerk-Tags angegeben haben und die Regel für Dataflow-VMs spezifisch sein soll, verwenden Sie dataflow als Netzwerk-Tag.

  • Wenn Sie benutzerdefinierte Netzwerk-Tags angegeben haben und die Regel für Dataflow-VMs spezifisch sein soll, verwenden Sie Ihre benutzerdefinierten Netzwerk-Tags.

• PRIORITY_NUM: die Priorität der Firewallregel

  Niedrigere Zahlen haben eine höhere Priorität und 0 ist die höchste Priorität.

Beispiel für eine Firewallregel für ausgehenden Traffic

Die Firewallregel für ausgehenden Traffic ermöglicht Dataflow-VMs, Pakete aneinander zu senden. Wenn Sie Firewallregeln für abzulehnenden ausgehenden Traffic erstellt haben, müssen Sie möglicherweise benutzerdefinierte Firewallregeln zum Zulassen von ausgehendem Traffic in Ihrem VPC-Netzwerk erstellen.

In diesem Beispiel wird eine Firewallregel für ausgehenden Traffic für Dataflow erstellt, wobei alle Worker-VMs das Standard-Netzwerk-Tag dataflow haben. Ein Projektinhaber, Projektbearbeiter oder Sicherheitsadministrator kann mit dem folgenden gcloud-Befehl die Regel „ausgehenden Traffic zulassen“ erstellen. Diese lässt Traffic von den TCP-Ports 12345 und 12346 auf VMs mit dem Netzwerk-Tag dataflow zu anderen VMs mit demselben Tag zu:

gcloud compute firewall-rules create FIREWALL_RULE_NAME_EGRESS \
    --network=NETWORK \
    --action=allow \
    --direction=egress \
    --target-tags=CUSTOM_TAG \
    --source-tags=CUSTOM_TAG \
    --destination-ranges=DESTINATION-RANGES\
    --priority=PRIORITY_NUM  \
    --rules tcp:12345-12346

Ersetzen Sie Folgendes:

• FIREWALL_RULE_NAME_EGRESS ist ein Name für die Firewallregel.

• NETWORK: der Name des Netzwerks, das die Worker-VMs verwenden

• CUSTOM_TAG ist eine durch Kommas getrennte Liste von Netzwerk-Tags.

  Die folgende Liste enthält Richtlinien zur Verwendung von Netzwerk-Tags:

  • Wenn Sie --target-tags weglassen, gilt die Regel für alle VMs im VPC-Netzwerk.

  • Wenn Sie --source-tags und alle anderen Quellspezifikationen weglassen, ist Traffic von jeder Quelle zulässig.

  • Wenn Sie keine benutzerdefinierten Netzwerk-Tags angegeben haben und die Regel für Dataflow-VMs spezifisch sein soll, verwenden Sie dataflow als Netzwerk-Tag.

  • Wenn Sie benutzerdefinierte Netzwerk-Tags angegeben haben und die Regel für Dataflow-VMs spezifisch sein soll, verwenden Sie Ihre benutzerdefinierten Netzwerk-Tags.

• DESTINATION-RANGES: eine durch Kommas getrennte Liste von CIDRs

  Schließen Sie den primären IP-Adressbereich des ausgewählten Subnetzwerks ein.

• PRIORITY_NUM: die Priorität der Firewallregel

  Niedrigere Zahlen haben eine höhere Priorität und 0 ist die höchste Priorität.

Die von Dataflow verwendeten TCP-Ports finden Sie im Projekt-Containermanifest. Das Containermanifest gibt explizit die Ports an, um dem Container Host-Ports zuzuordnen.

SSH-Zugriff auf Worker-VMs

Dataflow erfordert kein SSH. Dieses ist jedoch für die Problembehandlung hilfreich.

Wenn Ihre Worker-VM über eine externe IP-Adresse verfügt, können Sie entweder über die Google Cloud Console oder mithilfe der Google Cloud CLI eine Verbindung zur VM herstellen. Wenn Sie eine Verbindung über SSH herstellen möchten, müssen Sie eine Firewallregel haben, die eingehende Verbindungen am TCP-Port 22 von mindestens der IP-Adresse des Systems zulässt, auf dem gcloud ausgeführt wird, oder der IP-Adresse des Systems, auf dem der Webbrowser ausgeführt wird, mit dem Sie auf dieGoogle Cloud Console zugreifen.

Sie können sich die Netzwerkkonfiguration und -aktivität ansehen, indem Sie eine SSH-Sitzung auf einem Ihrer Worker öffnen und iproute2 ausführen. Weitere Informationen finden Sie auf der Seite iproute2 im Linux Foundation-Wiki.

Informationen zum Herstellen einer Verbindung zu einer Worker-VM, die lediglich eine interne IP-Adresse hat, finden Sie unter Verbindungsoption für ausschließlich interne VMs auswählen.

Nächste Schritte

• Weitere Informationen zu Konnektivitätstests Konnektivitätstests ist ein Diagnosetool, mit dem Sie die Konnektivität zwischen Netzwerkendpunkten prüfen können.
• Konnektivitätstests erstellen und ausführen