GSP016

Überblick

In diesem Lab erfahren Sie, wie Sie einfache Netzwerkaufgaben in Google Cloud (einschließlich Compute Engine-Instanzen) erledigen und wie sich Google Cloud von einer lokalen Konfiguration unterscheidet. Sie entwickeln ein Netzwerk und drei Subnetzwerke. Am Ende sieht Ihre Umgebung dann so aus:

Die Reihenfolge, in der die Aufgaben des Labs gestellt werden, entspricht der üblichen Vorgehensweise bei der Cloud-Entwicklung:

1. Sie richten die Lab-Umgebung ein und lernen, wie Sie die Google Cloud-Umgebung nutzen.
2. Sie stellen ein gemeinsames Netzwerk mit Subnetzen und mehreren Regionen bereit. Dazu setzen Sie gängige Open-Source-Tools ein und überprüfen Ihr weltweites Netzwerk.
3. Sie testen und überwachen das Netzwerk und die Instanzen.

Lerninhalte

• Grundlegende Konzepte und Konstrukte des Google Cloud-Netzwerks
• Standardnetzwerke und von Nutzern erstellte Netzwerke konfigurieren
• Leistungs- und Latenzeigenschaften messen
• Grundlegende Sicherheitskonfigurationen für den Zugriff, die Firewall und das Routing

Vorbereitung

• Grundlegende Kenntnisse zur Compute Engine
• Grundkenntnisse in den Bereichen Netzwerk und TCP/IP
• Grundkenntnisse zu Unix/Linux-Befehlszeilen

Einrichtung und Anforderungen

Vor dem Klick auf „Start Lab“ (Lab starten)

Lesen Sie diese Anleitung. Labs sind zeitlich begrenzt und können nicht pausiert werden. Der Timer beginnt zu laufen, wenn Sie auf Lab starten klicken, und zeigt Ihnen, wie lange die Ressourcen für das Lab verfügbar sind.

In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung selbst durchführen – nicht in einer Simulations- oder Demo-Umgebung. Dazu erhalten Sie neue, temporäre Anmeldedaten, mit denen Sie für die Dauer des Labs auf Google Cloud zugreifen können.

Für dieses Lab benötigen Sie Folgendes:

• Einen Standardbrowser (empfohlen wird Chrome)

Hinweis: Nutzen Sie den privaten oder Inkognitomodus, um dieses Lab durchzuführen. So wird verhindert, dass es zu Konflikten zwischen Ihrem persönlichen Konto und dem Teilnehmerkonto kommt und zusätzliche Gebühren für Ihr persönliches Konto erhoben werden.

• Zeit für die Durchführung des Labs – denken Sie daran, dass Sie ein begonnenes Lab nicht unterbrechen können.

Hinweis: Wenn Sie über ein persönliches Google Cloud-Konto oder -Projekt verfügen, verwenden Sie es nicht für dieses Lab. So werden zusätzliche Kosten für Ihr Konto vermieden.

Lab starten und bei der Google Cloud Console anmelden

1. Klicken Sie auf Lab starten. Wenn Sie für das Lab bezahlen müssen, wird ein Pop-up-Fenster geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können. Auf der linken Seite befindet sich der Bereich Details zum Lab mit diesen Informationen:

   • Schaltfläche Google Cloud Console öffnen
   • Restzeit
   • Temporäre Anmeldedaten für das Lab
   • Ggf. weitere Informationen für dieses Lab

2. Klicken Sie auf Google Cloud Console öffnen (oder klicken Sie mit der rechten Maustaste und wählen Sie Link in Inkognitofenster öffnen aus, wenn Sie Chrome verwenden).

   Im Lab werden Ressourcen aktiviert. Anschließend wird ein weiterer Tab mit der Seite Anmelden geöffnet.

   Tipp: Ordnen Sie die Tabs nebeneinander in separaten Fenstern an.

   Hinweis: Wird das Dialogfeld Konto auswählen angezeigt, klicken Sie auf Anderes Konto verwenden.

3. Kopieren Sie bei Bedarf den folgenden Nutzernamen und fügen Sie ihn in das Dialogfeld Anmelden ein.

   {{{user_0.username | "Username"}}}

   Sie finden den Nutzernamen auch im Bereich Details zum Lab.

4. Klicken Sie auf Weiter.

5. Kopieren Sie das folgende Passwort und fügen Sie es in das Dialogfeld Willkommen ein.

   {{{user_0.password | "Password"}}}

   Sie finden das Passwort auch im Bereich Details zum Lab.

6. Klicken Sie auf Weiter.

   Wichtig: Sie müssen die für das Lab bereitgestellten Anmeldedaten verwenden. Nutzen Sie nicht die Anmeldedaten Ihres Google Cloud-Kontos. Hinweis: Wenn Sie Ihr eigenes Google Cloud-Konto für dieses Lab nutzen, können zusätzliche Kosten anfallen.

7. Klicken Sie sich durch die nachfolgenden Seiten:

   • Akzeptieren Sie die Nutzungsbedingungen.
   • Fügen Sie keine Wiederherstellungsoptionen oder Zwei-Faktor-Authentifizierung hinzu (da dies nur ein temporäres Konto ist).
   • Melden Sie sich nicht für kostenlose Testversionen an.

Nach wenigen Augenblicken wird die Google Cloud Console in diesem Tab geöffnet.

Hinweis: Wenn Sie sich eine Liste der Google Cloud-Produkte und ‑Dienste ansehen möchten, klicken Sie oben links auf das Navigationsmenü.

Cloud Shell aktivieren

Cloud Shell ist eine virtuelle Maschine, auf der Entwicklertools installiert sind. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Mit Cloud Shell erhalten Sie Befehlszeilenzugriff auf Ihre Google Cloud-Ressourcen.

1. Klicken Sie oben in der Google Cloud Console auf Cloud Shell aktivieren .

Wenn Sie verbunden sind, sind Sie bereits authentifiziert und das Projekt ist auf Ihre Project_ID, eingestellt. Die Ausgabe enthält eine Zeile, in der die Project_ID für diese Sitzung angegeben ist:

Ihr Cloud-Projekt in dieser Sitzung ist festgelegt als {{{project_0.project_id | "PROJECT_ID"}}}

gcloud ist das Befehlszeilentool für Google Cloud. Das Tool ist in Cloud Shell vorinstalliert und unterstützt die Tab-Vervollständigung.

2. (Optional) Sie können den aktiven Kontonamen mit diesem Befehl auflisten:

gcloud auth list

3. Klicken Sie auf Autorisieren.

Ausgabe:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} Um das aktive Konto festzulegen, führen Sie diesen Befehl aus: $ gcloud config set account `ACCOUNT`

4. (Optional) Sie können die Projekt-ID mit diesem Befehl auflisten:

gcloud config list project

Ausgabe:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Hinweis: Die vollständige Dokumentation für gcloud finden Sie in Google Cloud in der Übersicht zur gcloud CLI.

Regionen und Zonen

Bestimmte Compute Engine-Ressourcen befinden sich in Regionen oder Zonen. Eine Region ist ein bestimmter Ort, an dem Sie Ihre Ressourcen ausführen können. Jede Region hat eine oder mehrere Zonen. „us-central1“ bezeichnet zum Beispiel eine Region in der Mitte der USA und umfasst die Zonen us-central1-a, us-central1-b, us-central1-c und us-central1-f.

Regionen	Zonen
Westen der USA	us-west1-a, us-west1-b
Mitte der USA	us-central1-a, us-central1-b, us-central1-d, us-central1-f
Osten der USA	us-east1-b, us-east1-c, us-east1-d
Westeuropa	europe-west1-b, europe-west1-c, europe-west1-d
Ostasien	asia-east1-a, asia-east1-b, asia-east1-c

Ressourcen, die sich in einer Zone befinden, werden als zonale Ressourcen bezeichnet. VM-Instanzen und nichtflüchtige Speicher befinden sich in einer Zone. Möchten Sie einen nichtflüchtigen Speicher an eine VM-Instanz anbinden, müssen sich beide Ressourcen in derselben Zone befinden. Ebenso verhält es sich, wenn Sie einer Instanz eine statische IP-Adresse zuweisen möchten: Die Instanz muss sich auch hier in derselben Region wie die statische IP-Adresse befinden.

Weitere Informationen zu Regionen und Zonen einschließlich einer vollständigen Liste finden Sie hier.

Google Cloud-Netzwerkkonzepte

In Google Cloud ermöglichen Netzwerke Datenverbindungen zu und von Ihren Cloudressourcen (hauptsächlich Compute Engine-Instanzen). Das Sichern Ihrer Netzwerke ist entscheidend für den Datenschutz und die Zugriffssteuerung für Ihre Ressourcen.

Google Cloud unterstützt Projekte, Netzwerke und Subnetzwerke und ermöglicht so eine flexible, logische Isolierung unabhängiger Ressourcen.

Projekte sind die äußersten Container und werden dazu verwendet, Ressourcen mit derselben Vertrauensgrenze zu gruppieren. Viele Entwickler ordnen Projekte Teams zu, weil jedes Projekt eine eigene Zugriffsrichtlinie (IAM) und Mitgliederliste hat. Projekte dienen auch zum Erfassen von Abrechnungs- und Kontingentdetails, die den Ressourcenverbrauch widerspiegeln. Sie enthalten Netzwerke, die wiederum Subnetzwerke, Firewallregeln und Routen umfassen (wie in den Architekturdiagrammen unten dargestellt).

Netzwerke verbinden Ihre Ressourcen direkt miteinander und mit der Außenwelt. In den Firewalls von Netzwerken werden auch die Zugriffsrichtlinien für ein- und ausgehende Verbindungen angewendet. Netzwerke können global sein (und horizontale Skalierbarkeit über mehrere Regionen hinweg bieten) oder regional (mit niedriger Latenz in einer einzigen Region).

Subnetzwerke ermöglichen es Ihnen, ähnliche Ressourcen (Compute Engine-Instanzen) zu privaten RFC1918-Adressbereichen zu gruppieren. Subnetzwerke können nur regional sein und werden im automatischen oder benutzerdefinierten Modus verwendet.

• Ein Netzwerk im automatischen Modus hat ein Subnetz pro Region – jedes mit einem im Voraus festgelegten IP-Bereich und Gateway. Diese Subnetze werden automatisch angelegt, wenn Sie das Netzwerk im automatischen Modus erstellen, und haben denselben Namen wie das Gesamtnetzwerk.
• Ein Netzwerk im benutzerdefinierten Modus hat bei der Erstellung keine Subnetze. Wenn Sie eine Instanz in einem Netzwerk im benutzerdefinierten Modus erstellen möchten, müssen Sie zuerst ein Subnetzwerk in dieser Region anlegen und den IP-Bereich dafür angeben. Ein Netzwerk im benutzerdefinierten Modus kann null, ein oder viele Subnetze pro Region enthalten.

Region und Zone einrichten

Bestimmte Compute Engine-Ressourcen befinden sich in Regionen und Zonen. Eine Region ist ein bestimmter Ort, an dem Sie Ihre Ressourcen ausführen können. Jede Region hat eine oder mehrere Zonen.

Führen Sie die folgenden gcloud-Befehle in Cloud Shell aus, um die Standardregion und ‑zone für Ihr Lab festzulegen:

gcloud config set compute/zone "{{{project_0.default_zone | Zone}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region | Region}}}" export REGION=$(gcloud config get compute/region)

Aufgabe 1: Blick auf das Standardnetzwerk

Wenn ein neues Projekt erstellt wird, gilt eine Standard-Netzwerkkonfiguration, durch die jede Region ein automatisches Subnetzwerk erhält. Sie können in einem Projekt bis zu vier weitere Netzwerke erstellen. Zusätzliche Netzwerke können automatische oder benutzerdefinierte Subnetzwerke oder alte Netzwerke sein.

Jeder Instanz, die innerhalb eines Subnetzwerks erstellt wird, wird eine IPv4-Adresse aus dem Bereich dieses Subnetzwerks zugewiesen.

• Sehen wir uns Ihr Netzwerk einmal an. Klicken Sie dazu auf das Navigationsmenü und dann auf VPC-Netzwerk.

Firewalls

Weitere Informationen zum Isolieren von Subnetzwerken anhand von Firewallregeln finden Sie in diesen Artikeln zu Subnetzen und Firewallregeln.

Jedes Netzwerk hat eine Standardfirewall, die den gesamten eingehenden Traffic zu Instanzen blockiert. Damit Traffic in eine Instanz weitergeleitet werden kann, müssen Sie „allow“-Regeln für die Firewall erstellen. Darüber hinaus lässt die Standardfirewall Traffic von Instanzen zu, es sei denn, Sie konfigurieren sie mit einer „egress“-Firewallkonfiguration so, dass ausgehende Verbindungen blockiert werden. Standardmäßig ist es daher sinnvoll, für eingehenden Traffic, den Sie zulassen möchten, „allow“-Regeln zu erstellen, und „deny“-Regeln für ausgehenden Traffic, den Sie unterbinden möchten. Sie können auch eine Standard-Deny-Richtlinie für ausgehenden Traffic erstellen und externe Verbindungen vollständig verbieten.

Es ist normalerweise empfehlenswert, die Firewallregel so einzurichten, dass sie den Traffic möglichst strikt einschränkt, aber den von Ihnen gewünschten Traffic noch passieren lässt. Wenn der Traffic beispielsweise bei bestimmten Instanzen ankommen muss, bei anderen aber nicht ankommen darf, erstellen Sie die Regeln so, dass er nur zu den gewünschten Instanzen gelangt. Diese restriktivere Konfiguration ist berechenbarer als eine umfassende Firewallregel, die den Traffic zu allen Instanzen durchlässt. Wenn Sie möchten, dass „deny“-Regeln bestimmte „allow“-Regeln außer Kraft setzen, können Sie Prioritätsstufen für jede Regel festlegen. Die Regel mit dem niedrigsten Prioritätswert wird dann zuerst ausgewertet. Umfangreiche, komplizierte Sätze von Regeln, die andere Regeln außer Kraft setzen, können jedoch dazu führen, dass Traffic unbeabsichtigt zugelassen oder blockiert wird.

Das Standardnetzwerk enthält automatisch erstellte Firewallregeln, die unten dargestellt werden. Manuell erstellte Netzwerke beliebigen Typs haben keine automatisch erstellten Firewallregeln. Für alle Netzwerke mit Ausnahme des Standardnetzwerks müssen Sie die erforderlichen Firewallregeln selbst erstellen.

Folgende Firewallregeln für eingehenden Traffic werden für das Standardnetzwerk automatisch erstellt:

default-allow-internal	Lässt Netzwerkverbindungen mit beliebigem Protokoll und Port zwischen Instanzen im Netzwerk zu.
default-allow-ssh	Lässt SSH-Verbindungen von einer beliebigen Quelle zu jeder Instanz im Netzwerk über TCP-Port 22 zu.
default-allow-rdp	Lässt RDP-Verbindungen von einer beliebigen Quelle zu jeder Instanz im Netzwerk über TCP-Port 3389 zu.
default-allow-icmp	Lässt ICMP-Traffic von einer beliebigen Quelle zu einer beliebigen Instanz im Netzwerk zu.

• Wenn Sie sich die Standardfirewallregeln ansehen möchten, klicken Sie in der Cloud Console auf das Navigationsmenü und dann auf VPC-Netzwerk > Firewall.

Netzwerkroute

Alle Netzwerke haben automatisch erstellte Routen zum Internet (Standardroute) und zu den IP-Bereichen im Netzwerk. Der Routenname wird automatisch generiert und sieht für jedes Projekt anders aus.

• Wenn Sie Standardrouten prüfen möchten, klicken Sie auf das Navigationsmenü > VPC-Netzwerk > Routen. Wählen Sie dann Netzwerk und Region aus, um Routen anzeigen zu lassen.

Aufgabe 2: Benutzerdefiniertes Netzwerk erstellen

Neues Netzwerk mit benutzerdefinierten Subnetzbereichen erstellen

Bei der manuellen Zuweisung von Subnetzwerkbereichen erstellen Sie zuerst ein benutzerdefiniertes Subnetzwerk. Danach erstellen Sie die gewünschten Subnetzwerke innerhalb einer Region. Sie müssen die Subnetzwerke für alle Regionen nicht sofort oder überhaupt angeben. Sie können aber keine Instanzen in Regionen erstellen, für die kein Subnetzwerk definiert ist.

Wenn Sie ein Subnetzwerk erstellen, muss dessen Name in diesem Projekt für diese Region und selbst über Netzwerke hinweg eindeutig sein. Derselbe Name kann in einem Projekt zweimal verwendet werden, solange er zu unterschiedlichen Regionen gehört. Da dies ein Subnetzwerk ist, gibt es keinen IPv4-Bereich und keine Gateway-IP-Adresse auf Netzwerkebene, sodass auch nichts dergleichen angezeigt wird.

Sie können Ihr benutzerdefiniertes Netzwerk mit der Console oder mit Cloud Shell erstellen. Wir stellen Ihnen beide Möglichkeiten vor, aber Sie müssen sich im Lab für eine Methode entscheiden. Sie können beispielsweise nicht einen Abschnitt mit der Anleitung für die Console durchgehen und dann denselben Abschnitt mit der gcloud-Befehlszeile.

Aufgabe 3: Benutzerdefiniertes Netzwerk mit der Console erstellen

Hinweis: Wenn Sie die Befehlszeile bevorzugen, überspringen Sie diesen Abschnitt und fahren Sie mit Benutzerdefiniertes Netzwerk mit Cloud Shell erstellen fort.

1. Klicken Sie auf Navigationsmenü > VPC-Netzwerk, um ein benutzerdefiniertes Netzwerk zu erstellen.

2. Klicken Sie auf VPC-Netzwerk erstellen und nennen Sie das neue Netzwerk taw-custom-network.

3. Auf dem Tab Benutzerdefiniert erstellen Sie Folgendes:

   • Subnetzname: subnet-
   • Region:
   • IP-Adressbereich: 10.0.0.0/16

4. Klicken Sie auf Fertig.

   

5. Klicken Sie nun auf Subnetz hinzufügen und fügen Sie zwei weitere Subnetze in den entsprechenden Regionen hinzu:

   • subnet-, , 10.1.0.0/16
   • subnet-, , 10.2.0.0/16

6. Klicken Sie auf Erstellen, um den Vorgang abzuschließen.

An dieser Stelle verfügt das Netzwerk über Routen zum Internet und zu allen Instanzen, die Sie erstellen. Es hat aber keine Firewallregeln, die den Zugriff auf Instanzen zulassen, auch nicht von anderen Instanzen. Um Zugriff zu gewähren, müssen Sie Firewallregeln erstellen.

Fahren Sie mit dem Abschnitt Firewallregeln hinzufügen fort.

Aufgabe 4: Benutzerdefiniertes Netzwerk mit Cloud Shell erstellen

Hinweis: Wenn Sie gerade ein Netzwerk mit der Console erstellt haben, dürfen Sie den gleichen Vorgang nicht noch einmal mit Cloud Shell durchführen. Gehen Sie das Lab stattdessen noch einmal von vorn durch, um das Ganze mit der gcloud-Befehlszeile zu üben.

• Geben Sie in Cloud Shell den folgenden Befehl ein, um das benutzerdefinierte Netzwerk zu erstellen:

gcloud compute networks create taw-custom-network --subnet-mode custom

Ausgabe:

NAME MODE IPV4_RANGE GATEWAY_IPV4 taw-custom-network custom Instanzen in diesem Netzwerk können nicht erreicht werden, bis Firewallregeln erstellt sind. So können Sie zum Beispiel jeglichen internen Traffic zwischen Instanzen zulassen, ebenso SSH-, RDP- und ICMP-Traffic. Führen Sie dazu Folgendes aus: $ gcloud compute firewall-rules create --network taw-custom-network --allow tcp,udp,icmp --source-ranges $ gcloud compute firewall-rules create --network taw-custom-network --allow tcp:22,tcp:3389,icmp

Jetzt erstellen Sie Subnetze für Ihr neues benutzerdefiniertes Netzwerk. Sie werden drei davon erstellen.

1. Erstellen Sie subnet- mit einem IP-Präfix:

gcloud compute networks subnets create subnet-{{{project_0.default_region | Region}}} \ --network taw-custom-network \ --region {{{project_0.default_region | Region}}} \ --range 10.0.0.0/16

Ausgabe:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.default_region | Region}}}/subnetworks/subnet-{{{project_0.default_region | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.default_region | Region}}} {{{project_0.default_region | Region}}} taw-custom-network 10.0.0.0/16

2. Erstellen Sie subnet- mit einem IP-Präfix:

gcloud compute networks subnets create subnet-{{{project_0.default_region_2 | Region}}} \ --network taw-custom-network \ --region {{{project_0.default_region_2 | Region}}} \ --range 10.1.0.0/16

Ausgabe:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.default_region_2 | Region}}}/subnetworks/subnet-{{{project_0.default_region_2 | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.default_region_2 | Region}}} {{{project_0.default_region_2 | Region}}} taw-custom-network 10.1.0.0/16

3. Erstellen Sie subnet- mit einem IP-Präfix:

gcloud compute networks subnets create subnet-{{{project_0.default_region_3 | Region}}} \ --network taw-custom-network \ --region {{{project_0.default_region_3 | Region}}} \ --range 10.2.0.0/16

Ausgabe:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/regions/{{{project_0.default_region_3 | Region}}}/subnetworks/subnet-{{{project_0.default_region_3 | Region}}}]. NAME REGION NETWORK RANGE subnet-{{{project_0.default_region_2 | Region}}} {{{project_0.default_region_2 | Region}}} taw-custom-network 10.2.0.0/16

4. Listen Sie die Netzwerke auf:

gcloud compute networks subnets list \ --network taw-custom-network

Wenn Sie im vorherigen Abschnitt ein automatisches Subnetzwerk erstellt haben, werden diese Subnetze ebenfalls aufgeführt.

Ausgabe:

NAME REGION NETWORK RANGE subnet-{{{project_0.default_region_3 | Region}}} {{{project_0.default_region_3 | Region}}} taw-custom-network 10.1.0.0/16 subnet-{{{project_0.default_region_2 | Region}}} {{{project_0.default_region_2 | Region}}} taw-custom-network 10.2.0.0/16 subnet-{{{project_0.default_region | Region}}} {{{project_0.default_region | Region}}} taw-custom-network 10.0.0.0/16

An dieser Stelle verfügt das Netzwerk über Routen zum Internet und zu allen Instanzen, die Sie erstellen. Es hat aber keine Firewallregeln, die den Zugriff auf Instanzen zulassen, auch nicht von anderen Instanzen. Um Zugriff zu gewähren, müssen Sie Firewallregeln erstellen.

Aufgabe 5: Firewallregeln hinzufügen

Um den Zugriff auf VM-Instanzen zuzulassen, müssen Sie Firewallregeln anwenden. Hierfür verwenden Sie ein Instanztag. Die Firewallregel gilt für alle VMs mit demselben Instanztag.

Hinweis: Netzwerke und Firewalls nutzen Instanztags, um bestimmte Firewallregeln auf VM-Instanzen mit dem entsprechenden Tag anzuwenden. Wenn z. B. verschiedene Instanzen dieselbe Aufgabe wie etwa das Bereitstellen einer großen Website ausführen, können Sie diese Instanzen mit einem gemeinsam verwendeten Wort oder Begriff taggen und dieses Tag dann verwenden, um den Instanzen mithilfe einer Firewallregel HTTP-Zugriff zu gewähren.

Tags werden auch auf dem Metadatenserver berücksichtigt, damit sie für Anwendungen verwendet werden können, die auf den Instanzen ausgeführt werden.

• Öffnen Sie als Erstes die Firewall für HTTP-Internetanfragen. Anschließend fügen Sie weitere Firewallregeln hinzu. Firewallregeln können über die Konsole oder über Cloud Shell hinzugefügt werden.

Firewallregeln über die Console hinzufügen

1. Rufen Sie die Option VPC-Netzwerke in der Cloud Console auf und klicken Sie auf taw-custom-network:

2. Klicken Sie auf den Tab Firewalls und dann auf Firewallregel hinzufügen.

3. Tragen Sie folgende Werte ein:

Feld	Wert	Kommentare
Name	nw101-allow-http	Name der neuen Regel
Ziele	Angegebene Zieltags	Die Instanzen, für die die Firewallregel gelten soll
Zieltags	http	Das von uns erstellte Tag
Quellfilter	IPv4-Bereiche	Firewall ist für alle IP-Adressen geöffnet
Quell-IPv4-Bereiche	0.0.0.0/0	Firewall ist für alle IP-Adressen geöffnet
Protokolle und Ports	Wählen Sie Angegebene Protokolle und Ports und dann tcp aus und geben Sie 80 ein	Nur HTTP

Ihr Bildschirm sieht dann so aus:

4. Klicken Sie auf Erstellen und warten Sie, bis der Befehl erfolgreich ausgeführt wurde. Als Nächstes erstellen Sie die weiteren benötigten Firewallregeln.

Firewallregeln über Cloud Shell hinzufügen

Hinweis: Wenn Sie gerade ein Netzwerk mit der Cloud Console erstellt haben, dürfen Sie den gleichen Vorgang nicht noch einmal mit Cloud Shell durchführen. Gehen Sie das Lab stattdessen noch einmal von vorn durch, um das Ganze mit der gcloud-Befehlszeile zu üben.

• Führen Sie den folgenden Befehl aus, um Firewallregeln in Cloud Shell zu erstellen:

gcloud compute firewall-rules create nw101-allow-http \ --allow tcp:80 --network taw-custom-network --source-ranges 0.0.0.0/0 \ --target-tags http

Ausgabe:

Weitere Firewallregeln erstellen

Diese zusätzlichen Firewallregeln lassen ICMP, interne Kommunikation, SSH und RDP zu. Sie können sie mit der Console oder in Cloud Shell erstellen. Denken Sie daran, für jede Art von Firewallregel entweder die eine oder die andere Methode zu verwenden, nicht beide.

• ICMP

Feld	Wert	Kommentare
Name	nw101-allow-icmp	Name der neuen Regel
Ziele	Angegebene Zieltags	Aus dem Drop-down-Menü „Ziele“ auswählen
Zieltags	Regeln	Tag
Quellfilter	IPv4-Bereiche	Wir öffnen die Firewall für jede IP-Adresse aus dieser Liste
Quell-IPv4-Bereiche	0.0.0.0/0	Firewall ist für alle IP-Adressen geöffnet
Protokolle und Ports	Wählen Sie Angegebene Protokolle und Ports, Andere Protokolle aus und geben Sie dann icmp ein	Die Protokolle und Ports, auf die die Firewall angewendet wird

(Cloud Shell-Befehle)

gcloud compute firewall-rules create "nw101-allow-icmp" --allow icmp --network "taw-custom-network" --target-tags rules

• Interne Kommunikation

Feld	Wert	Kommentare
Name	nw101-allow-internal	Name der neuen Regel
Ziele	Alle Instanzen im Netzwerk	Aus dem Drop-down-Menü „Ziele“ auswählen
Quellfilter	IPv4-Bereiche	Der Filter, durch den die Regel auf bestimmte Zugriffsquellen angewendet wird
Quell-IPv4-Bereiche	10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16	Firewall ist für alle IP-Adressen geöffnet
Protokolle und Ports	Wählen Sie Angegebene Protokolle und Ports und dann tcp aus und geben Sie 0-65535 ein; wählen Sie udp aus und geben Sie 0-65535 ein; wählen Sie Andere Protokolle aus und geben Sie icmp ein	Erlaubt tcp:0-65535, udp:0-65535, icmp

(Cloud Shell-Befehle)

gcloud compute firewall-rules create "nw101-allow-internal" --allow tcp:0-65535,udp:0-65535,icmp --network "taw-custom-network" --source-ranges "10.0.0.0/16","10.2.0.0/16","10.1.0.0/16"

• SSH

Feld	Wert	Kommentare
Name	nw101-allow-ssh	Name der neuen Regel
Ziele	Angegebene Zieltags	ssh
Zieltags	ssh	Die Instanzen, auf die die Firewallregel angewendet wird
Quellfilter	IPv4-Bereiche	Der Filter, durch den die Regel auf bestimmte Zugriffsquellen angewendet wird
Quell-IPv4-Bereiche	0.0.0.0/0	Firewall ist für alle IP-Adressen geöffnet
Protokolle und Ports	Wählen Sie Angegebene Protokolle und Ports und dann tcp aus und geben Sie 22 ein	Erlaubt tcp:22

(Cloud Shell-Befehle)

gcloud compute firewall-rules create "nw101-allow-ssh" --allow tcp:22 --network "taw-custom-network" --target-tags "ssh"

• RDP

Feld	Wert	Kommentare
Name	nw101-allow-rdp	Name der neuen Regel
Ziele	Alle Instanzen im Netzwerk	Aus dem Drop-down-Menü „Ziele“ auswählen
Quellfilter	IPv4-Bereiche	IP-Adressen filtern
Quell-IPv4-Bereiche	0.0.0.0/0	Firewall ist für alle IP-Adressen geöffnet
Protokolle und Ports	Wählen Sie Angegebene Protokolle und Ports und dann tcp aus und geben Sie 3389 ein	Erlaubt tcp:3389

(Cloud Shell-Befehle)

gcloud compute firewall-rules create "nw101-allow-rdp" --allow tcp:3389 --network "taw-custom-network"

• Sehen Sie sich die Firewallregeln in Ihrem Netzwerk in der Console an. Das sollte so aussehen:

Hinweis: Was hat es mit den Routen auf sich, die ich in der Netzwerkkonsole sehe?

Google Cloud Networking verwendet Routen, um Pakete zwischen Subnetzwerken und zum Internet weiterzuleiten. Wenn in Ihrem Netzwerk ein Subnetzwerk erstellt (oder vorab erstellt) wird, werden automatisch in jeder Region Routen erstellt, damit Pakete zwischen Subnetzwerken weitergeleitet werden können. Diese Routen können nicht geändert werden.

Weitere Routen können erstellt werden, um Traffic an eine Instanz, ein VPN-Gateway oder ein Standard-Internetgateway zu senden. Diese Routen lassen sich ändern, sodass Sie die Netzwerkarchitektur nach Wunsch gestalten können. Das Zusammenspiel von Routen und Firewalls sorgt dafür, dass Ihr Traffic dorthin gelangt, wo er benötigt wird.

Klicken Sie auf Fortschritt prüfen.

Erstellen Sie ein benutzerdefiniertes Netzwerk, Subnetzwerke und Firewallregeln.

Aufgabe 6: Verbindung zu den Lab-VMs herstellen und die Latenz testen

• Klicken Sie im Menü links auf VPC-Netzwerke, damit das ganze Netzwerk angezeigt wird. Das „taw-custom-network“ hat drei Subnetzwerke und die Firewallregeln werden angewendet.

Sie müssten Folgendes sehen:

Die nächsten Schritte bestehen darin, in jedem Subnetz eine VM zu erstellen und dafür zu sorgen, dass Sie Verbindungen zu diesen VMs herstellen können.

In jeder Zone eine VM erstellen

Für diesen Abschnitt des Labs arbeiten Sie in Cloud Shell.

1. Erstellen Sie mit dem Befehl unten im Subnetz subnet- eine Instanz mit dem Namen us-test-01.

gcloud compute instances create us-test-01 \ --subnet subnet-{{{project_0.default_region | Region}}} \ --zone {{{project_0.default_zone | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules

Notieren Sie sich die externe IP. Sie wird in diesem Lab später noch benötigt.

Ausgabe:

Created [https://www.googleapis.com/compute/v1/projects/cloud-network-module-101/zones/{{{project_0.default_zone | ZONE}}}/instances/us-test-01]. NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS us-test-01 {{{project_0.default_zone | ZONE}}} e2-standard-2 10.0.0.2 104.198.230.22 RUNNING

2. Erstellen Sie jetzt die VMs „us-test-02“ und „us-test-03“ in den korrelierten Subnetzen:

gcloud compute instances create us-test-02 \ --subnet subnet-{{{project_0.default_region_2 | REGION}}} \ --zone {{{project_0.default_zone_2 | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules gcloud compute instances create us-test-03 \ --subnet subnet-{{{project_0.default_region_3 | REGION}}} \ --zone {{{project_0.default_zone_3 | ZONE}}} \ --machine-type e2-standard-2 \ --tags ssh,http,rules

Klicken Sie auf Fortschritt prüfen.

Erstellen Sie drei Instanzen in angegebenen Zonen für Traceroute und Leistungstests.

Verbindung zu VMs testen

Führen Sie einige Übungen durch, um die Verbindung zu den VMs zu testen.

1. Wechseln Sie zurück zur Console und gehen Sie zu Compute Engine.

2. Klicken Sie auf die zur Instanz us-test-01 gehörende Schaltfläche SSH. Damit wird in einem neuen Fenster eine SSH-Verbindung zur Instanz geöffnet.

3. Geben Sie den folgenden Befehl in das Fenster „SSH“ für us-test-01 ein. Mit diesem Befehl wird ein ICMP-Echo bei us-test-02 ausgelöst. Geben Sie dabei in jeder Zeile die externe IP-Adresse für die VM an:

ping -c 3 <us-test-02-external-ip-address> Hinweis: Sie finden die externe IP-Adresse der virtuellen Maschinen im Browsertab Compute Engine unter dem Feld Externe IP-Adresse.

Ihre IP-Adressen werden nicht mit denen im Bild übereinstimmen.

4. Lösen Sie mit dem folgenden Befehl ein ICMP-Echo bei us-test-03 aus. Geben Sie dabei in jeder Zeile die externe IP-Adresse für die VM an:

ping -c 3 <us-test-03-external-ip-address>

Beispielausgabe:

PING 35.187.149.67 (35.187.149.67) 56(84) bytes of data. 64 bytes from 35.187.149.67: icmp_seq=1 ttl=76 time=152 ms 64 bytes from 35.187.149.67: icmp_seq=2 ttl=76 time=152 ms 64 bytes from 35.187.149.67: icmp_seq=3 ttl=76 time=152 ms

5. Prüfen Sie nun, ob SSH auch für die Instanzen us-test-02 und us-test-03 funktioniert. Testen Sie ein ICMP-Echo bei us-test-01.

Mit „ping“ die Latenz messen

Mit dem „ping“-Befehl messen Sie die Latenz zwischen den Instanzen aller Regionen.

• Öffnen Sie ein SSH-Fenster auf der Instanz us-test-01. Mit dem folgenden Befehl ermitteln Sie die Latenz von der Region Central United States zur Region Westeuropa:

ping -c 3 us-test-02.{{{project_0.default_zone_2 | ZONE}}}

Befehlsausgabe:

PING us-test-02.{{{project_0.default_zone_2 | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2) 56(84) bytes of data. 64 bytes from us-test-02.{{{project_0.default_zone_2 | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=1 ttl=64 time=105 ms 64 bytes from us-test-02.{{{project_0.default_zone_2 | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=2 ttl=64 time=104 ms 64 bytes from us-test-02.{{{project_0.default_zone_2 | ZONE}}}.c.cloud-network-module-101.internal (10.2.0.2): icmp_seq=3 ttl=64 time=104 ms

Die Latenz wird in Form der Umlaufzeit (Round Trip Time, RTT) angezeigt. Das ist die Zeit, die das Paket von us-test-01 nach us-test-02 benötigt.

Die Verbindung wird bei „ping“ mit den ICMP-Nachrichten Echo-Anfrage und Echo-Antwort getestet.

Hinweis: Denkanstöße

Wie hoch ist die Latenz zwischen den Regionen? Was wäre unter idealen Bedingungen zu erwarten? Welche Besonderheiten gibt es bei der Verbindung von „us-test-02“ zu „us-test-03“? Hinweis: Internes DNS: Wie wird das DNS für VM-Instanzen bereitgestellt?

Jede Instanz hat einen Metadatenserver, der auch als DNS-Resolver für diese Instanz fungiert. DNS-Suchvorgänge werden für Instanznamen durchgeführt. Der Metadatenserver selbst speichert alle DNS-Informationen für das lokale Netzwerk und fragt die öffentlichen DNS-Server von Google nach Adressen außerhalb des Netzwerks ab.

Ein interner vollqualifizierter Domainname (FQDN) für eine Instanz sieht so aus: hostName.[ZONE].c.[PROJECT_ID].internal.

Mit diesem FQDN können Sie jederzeit eine Verbindung von einer Instanz zu einer anderen herstellen. Wenn Sie z. B. nur mit „hostName“ eine Verbindung zu einer Instanz herstellen möchten, benötigen Sie Informationen aus dem internen DNS-Resolver, der mit Compute Engine bereitgestellt wird.

Aufgabe 7: (Optional) Traceroute und Leistungstests

Optionale Übung

Traceroute ist ein Tool, mit dem Sie den Pfad zwischen zwei Hosts nachvollziehen können. Eine solche Traceroute ist ein nützlicher erster Anhaltspunkt zur Klärung vieler verschiedener Netzwerkprobleme. Support-Entwickler sowie Network Engineers bitten oft um einen Traceroute-Test, wenn sie Netzwerkprobleme untersuchen.

Hinweis: Funktionalität

Traceroute zeigt alle Schicht-3-Hops zwischen den Hosts an (Schicht 3 ist die Vermittlungsschicht). Dazu werden Pakete mit aufsteigendem TTL-Wert (Time To Live) an das Remote-Ziel gesendet (beginnend mit 1). Das Feld „TTL“ ist ein Feld im IP-Paket, dessen Wert bei jedem Router um 1 verringert wird. Sobald der TTL-Wert null erreicht, wird das Paket verworfen und die ICMP-Nachricht „TTL überschritten“ an den Absender zurückgegeben. Dadurch werden Schleifen beim Routing vermieden. Pakete können nicht endlos eine Schleife durchlaufen, weil der TTL-Wert irgendwann auf null verringert wird. Standardmäßig wird der TTL-Wert vom Betriebssystem hoch eingestellt (64, 128, 255 oder vergleichbar), sodass dies nur in ungewöhnlichen Situationen geschehen dürfte.

Traceroute sendet die Pakete zuerst mit einem TTL-Wert von 1, dann einem TTL-Wert von 2 usw. Dadurch verfallen diese Pakete jeweils am ersten, zweiten usw. Router im Pfad. Aus der Quell-IP bzw. dem Host, der in der ICMP-Nachricht „TTL überschritten“ genannt wird, wird dann der Name bzw. die IP-Adresse des erreichten Hops ermittelt und angezeigt. Sobald der TTL-Wert hoch genug ist, erreicht das Paket sein Ziel und das Ziel antwortet.

Die Art des gesendeten Pakets ist von der Implementierung abhängig. Unter Linux werden UDP-Pakete an einen hohen, unbenutzten Port gesendet. Das endgültige Ziel antwortet dann mit der Meldung „ICMP-Port nicht erreichbar“. Bei Windows und dem mtr-Tool werden standardmäßig ICMP-Echo-Anfragen (wie Ping) verwendet. Das endgültige Ziel antwortet dann mit einer ICMP-Echo-Antwort.

Probieren Sie es jetzt aus. Richten Sie dazu eine Traceroute auf einer Ihrer virtuellen Maschinen ein.

1. Dabei kommen wieder die VMs us-test-01 und us-test-02 zum Einsatz und Sie stellen eine SSH-Verbindung zu beiden her.

2. Installieren Sie im SSH-Fenster für us-test-01 die folgenden Performancetools:

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege traceroute www.icann.org

3. Probieren Sie nun andere Ziele und Quellen aus:

   • VMs in derselben oder einer anderen Region (eu1-vm, asia1-vm, w2-vm)
   • www.wikipedia.org
   • www.adcash.com
   • bad.horse (funktioniert am besten, wenn Sie den TTL-Wert auf das Maximum setzen, also „traceroute -m 255 bad.horse“)
   • Alles, was Ihnen sonst noch einfällt

4. Möchten Sie Traceroute beenden, drücken Sie im SSH-Fenster die Tastenkombination Strg + C und kehren Sie zur Befehlszeile zurück.

Hinweis: Denkanstöße

Was fällt Ihnen bei den verschiedenen Traceroutes auf?

Aufgabe 8: (Optional) Leistung mit „iperf“ testen

Zwischen zwei Hosts

Optionale Übung

Wenn Sie die Leistung zwischen zwei Hosts mit iperf testen möchten, muss eine Seite als „iperf“-Server eingerichtet werden, der Verbindungen akzeptiert.

Wichtig: Durch die folgenden Befehle werden Gigabyte an Traffic zwischen Regionen übertragen. Dies wird zum Tarif für ausgehenden Internet-Traffic abgerechnet. Denken Sie an diese Kosten, wenn Sie die Befehle verwenden. Wenn Sie weder mit einem Projekt arbeiten, das auf der Zulassungsliste steht, noch die kostenlose Testversion nutzen, sollten Sie diesen Abschnitt möglicherweise überspringen oder nur überfliegen. (Die Kosten dürften unter 1 $ liegen.)

Probieren Sie es mit einem ganz einfachen Test:

1. Stellen Sie eine SSH-Verbindung zu us-test-02 her und installieren Sie folgende Leistungstools:

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege

2. Stellen Sie eine SSH-Verbindung zu us-test-01 her und führen Sie folgenden Befehl aus:

iperf -s #run in server mode

3. Führen Sie diesen iperf-Befehl auf us-test-02 aus:

iperf -c us-test-01.{{{project_0.default_zone | ZONE}}} #run in client mode

Die Ausgabe sieht ungefähr so aus:

Client connecting to eu-vm, TCP port 5001 TCP window size: 45.0 KByte (default) [ 3] local 10.20.0.2 port 35923 connected with 10.30.0.2 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 298 MBytes 249 Mbits/sec

4. Wenn Sie fertig sind, können Sie die Serverseite auf us-test-01 mit der Tastenkombination Strg + C verlassen.

Zwischen VMs innerhalb einer Region

Optionale Übung

Jetzt stellen Sie eine andere Instanz (us-test-04) bereit, die sich in einer anderen Zone befindet als us-test-01. Sie werden feststellen, dass die Bandbreite innerhalb einer Region durch die Obergrenze für ausgehenden Traffic von 2 Gbit/s pro Kern eingeschränkt wird.

1. Erstellen Sie us-test-04 in Cloud Shell:

gcloud compute instances create us-test-04 \ --subnet subnet-{{{project_0.default_region | REGION}}} \ --zone {{{project_0.default_zone | ZONE}}} \ --tags ssh,http

2. Stellen Sie eine SSH-Verbindung zu us-test-04 her und installieren Sie die Leistungstools:

sudo apt-get update sudo apt-get -y install traceroute mtr tcpdump iperf whois host dnsutils siege

Die zwischen verschiedenen Regionen erreichbare Leistung ist deutlich niedriger. Das liegt hauptsächlich an Beschränkungen der TCP-Fenstergröße und der Single-Stream-Leistung. Wenn Sie die Bandbreite zwischen Hosts erhöhen möchten, verwenden Sie andere Parameter, zum Beispiel UDP.

3. Führen Sie unter „SSH“ für us-test-02 den folgenden Befehl aus:

iperf -s -u #iperf server side

4. Führen Sie unter „SSH“ für us-test-01 den folgenden Befehl aus:

iperf -c us-test-02.{{{project_0.default_zone_2 | ZONE}}} -u -b 2G #iperf client side - send 2 Gbits/s

Damit sollten Sie eine höhere Geschwindigkeit zwischen der EU und den USA erreichen. Durch paralleles Ausführen mehrerer TCP iperfs können noch höhere Geschwindigkeiten erreicht werden. Probieren wir es aus.

5. Führen Sie im SSH-Fenster für us-test-01 folgenden Befehl aus:

iperf -s

6. Führen Sie im SSH-Fenster für us-test-02 folgenden Befehl aus:

iperf -c us-test-01.{{{project_0.default_zone | ZONE}}} -P 20

Die kombinierte Bandbreite dürfte sehr nahe an der maximal erreichbaren Bandbreite liegen.

7. Probieren Sie es noch mit einigen weiteren Kombinationen aus. Wenn Sie auf Ihrem Laptop Linux verwenden, können Sie den Test auch darauf durchführen. (Außerdem können Sie iperf3 ausprobieren, das für viele Betriebssysteme verfügbar ist. Das ist aber nicht Gegenstand dieses Labs.)

Wie Sie sehen, lässt sich die maximale Bandbreite mit einem einzelnen TCP-Stream (z. B. Kopieren von Dateien) nicht erreichen. Sie brauchen dazu mehrere parallele TCP-Sitzungen. Die Gründe dafür sind TCP-Parameter wie „Window Size“ und Funktionen wie „Slow Start“.

Weitere Informationen zu diesem und allen anderen TCP/IP-Themen finden Sie unter TCP/IP Illustrated.

Tools wie bbcp können dabei helfen, Dateien so schnell wie möglich zu kopieren. Sie parallelisieren die Übertragungen und nutzen konfigurierbare Fenstergrößen.

Aufgabe 9: Wissen testen

Lab beenden

Wenn Sie das Lab abgeschlossen haben, klicken Sie auf Lab beenden. Ihr Konto und die von Ihnen genutzten Ressourcen werden von der Labplattform entfernt.

Anschließend erhalten Sie die Möglichkeit, das Lab zu bewerten. Wählen Sie die entsprechende Anzahl von Sternen aus, schreiben Sie einen Kommentar und klicken Sie anschließend auf Senden.

Die Anzahl der Sterne hat folgende Bedeutung:

• 1 Stern = Sehr unzufrieden
• 2 Sterne = Unzufrieden
• 3 Sterne = Neutral
• 4 Sterne = Zufrieden
• 5 Sterne = Sehr zufrieden

Wenn Sie kein Feedback geben möchten, können Sie das Dialogfeld einfach schließen.

Verwenden Sie für Feedback, Vorschläge oder Korrekturen den Tab Support.

Das wars! Sie haben das Lab erfolgreich abgeschlossen.

Sie wissen jetzt, wie sowohl Standardnetzwerke als auch von Nutzern erstellte Netzwerke konfiguriert werden, wie Sie Zugriff gewähren und verweigern und wie Leistung und Latenz gemessen werden.

Weitere Informationen

Wenn Sie soweit sind, können Sie es mit dem Kurs Networking Fundamentals in the Google Cloud versuchen.

Google Cloud-Schulungen und -Zertifizierungen

In unseren Schulungen erfahren Sie alles zum optimalen Einsatz unserer Google Cloud-Technologien und können sich entsprechend zertifizieren lassen. Unsere Kurse vermitteln technische Fähigkeiten und Best Practices, damit Sie möglichst schnell mit Google Cloud loslegen und Ihr Wissen fortlaufend erweitern können. Wir bieten On-Demand-, Präsenz- und virtuelle Schulungen für Anfänger wie Fortgeschrittene an, die Sie individuell in Ihrem eigenen Zeitplan absolvieren können. Mit unseren Zertifizierungen weisen Sie nach, dass Sie Experte im Bereich Google Cloud-Technologien sind.

Anleitung zuletzt am 14. Mai 2024 aktualisiert

Lab zuletzt am 14. Mai 2024 getestet

© 2024 Google LLC. Alle Rechte vorbehalten. Google und das Google-Logo sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen können Marken der jeweils mit ihnen verbundenen Unternehmen sein.