Sicher mit VM-Instanzen verbinden

In diesem Dokument werden Best Practices zum Herstellen einer sicheren Verbindung zu Compute Engine-VM-Instanzen beschrieben. Dazu gehört auch das Speichern von Hostschlüsseln durch Aktivieren von Gastattributen und das Verhindern, dass VMs über das öffentliche Internet erreichbar sind.

Hinweise

Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud-Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich wie folgt bei Compute Engine authentifizieren.

Wählen Sie den Tab für die Verwendung der Beispiele auf dieser Seite aus:
Console

Wenn Sie über die Google Cloud Console auf Google Cloud-Dienste und -APIs zugreifen, müssen Sie die Authentifizierung nicht einrichten.
gcloud
1. Installieren Sie die Google Cloud CLI und initialisieren Sie sie mit folgendem Befehl:
```
gcloud init
```
  Hinweis: Wenn Sie die gcloud CLI zuvor installiert haben, prüfen Sie, ob Sie die neueste Version haben, indem Sie gcloud components update ausführen.
2. Legen Sie eine Standardregion und -zone fest.

Hostschlüssel durch Aktivieren von Gastattributen speichern

Ein Hostschlüssel ist ein Schlüsselpaar, das einen bestimmten Host oder Computer identifiziert. Wenn Sie eine Verbindung zu einem Remote-Host herstellen, wird anhand des Hostschlüssels bestätigt, dass die Verbindung zum gewünschten Computer erfolgt.

Wenn Sie die Verbindung zu Ihren Linux-VMs mit gcloud compute ssh herstellen, können Sie Ihre Hostschlüssel als Gastattribute speichern, um die Sicherheit zu erhöhen.

Durch das Speichern von SSH-Hostschlüsseln als Gastattribute erhöhen Sie die Sicherheit der Verbindungen. Sie schützen sie vor Sicherheitslücken wie MITM-Angriffen (Man-in-the-Middle). Wenn beim ersten Start einer VM Gastattribute aktiviert sind, werden die generierten Hostschlüssel in Compute Engine als Gastattribute gespeichert. Anschließend werden in Compute Engine anhand dieser gespeicherten Hostschlüssel alle nachfolgenden Verbindungen zur VM überprüft.

Hostschlüssel können als Gastattribute auf den folgenden öffentlichen Betriebssystem-Images gespeichert werden:

Debian
Ubuntu
Red Hat Enterprise Linux (RHEL)
CentOS
SUSE Linux Enterprise Server (SLES)

Wenn Sie Hostschlüssel in Gastattribute schreiben möchten, müssen Sie Gastattribute vor dem ersten Start der VM aktivieren. Sie können Gastattribute entweder für ausgewählte VMs bei der VM-Erstellung oder für Ihr gesamtes Projekt aktivieren.

Nachdem Sie Gastattribute für ein Projekt oder eine VM aktiviert haben, veröffentlicht der Gastbetriebssystem-Agent den Hostschlüssel automatisch als Gastattribut. Wenn Sie gcloud compute ssh anstelle eines einfachen SSH-Clients verwenden, liest die gcloud CLI die Attribute automatisch und aktualisiert die Datei known_hosts bei der nächsten Verbindung.

Führen Sie die folgenden Schritte aus, um Hostschlüssel als Gastattribute zu speichern:

Bevor Sie Ihre VM zum ersten Mal starten, aktivieren Sie Gastattribute entweder für ausgewählte VMs bei der VM-Erstellung oder für Ihr gesamtes Projekt.
Stellen Sie mit gcloud compute ssh eine Verbindung zu Ihrer VM her.
1. Prüfen Sie, ob Sie die neueste Version des Google Cloud CLI haben:
```
gcloud components update
```
2. Stellen Sie eine Verbindung zur VM her.
```
gcloud compute ssh --project=PROJECT_ID \
 --zone=ZONE \
 VM_NAME
```
  Dabei gilt:
  - PROJECT_ID: Die ID des Projekts, das die VM enthält
  - ZONE: Der Name der Zone, in der sich die VM befindet
  - VM_NAME: Der Name der VM
  Wenn Sie Standardeigenschaften für das Google Cloud CLI festgelegt haben, können Sie die Flags --project und --zone bei diesem Befehl weglassen. Beispiel:
```
gcloud compute ssh VM_NAME
```
3. Überprüfen Sie die Startmeldung. Unter einem Debian-Betriebssystem sehen Sie möglicherweise die folgende Meldung:
```
Writing 3 keys to YOUR_HOME_DIRECTORY/.ssh/google_compute_known_hosts
Linux host-key-2 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) x86_64
```

Um zu bestätigen, dass Hostschlüssel als Gastattribute für diese VM gespeichert werden, haben Sie zwei Möglichkeiten: Prüfen Sie anhand der Hostschlüsselwerte, ob SSH-Schlüssel in Gastattribute für die VM geschrieben werden (Option 1), oder prüfen Sie den seriellen Port auf Vorhandensein von Hostschlüsseln (Option 2):

Option 1: Hostschlüsselwerte prüfen

Mit dem Google Cloud CLI können Sie prüfen, ob SSH-Schlüssel in Gastattribute geschrieben werden.

gcloud compute instances get-guest-attributes VM_NAME \
  --query-path="hostkeys/" \
  --zone=ZONE

Dabei gilt:

VM_NAME: Der Name der VM
ZONE: Der Name der Zone, in der sich die VM befindet

Die Ausgabe sieht etwa so aus:

NAMESPACE  KEY                  VALUE
hostkeys   ecdsa-sha2-nistp256  AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBJAGpTm
                                V3mFxBTHK1NIu9a7kVQWaHsZVaFUsqF8cLxQRQ+N96/Djiiuz1tucHQ8vBTJI=
hostkeys   ssh-ed25519          AAAAC3NzaC1lZDI1NTE5AAAAIM/WYBn3jIEW5t3BZumx0X/Htm61J6S9FcU8L
hostkeys   ssh-rsa              AAAAB3NzaC1yc2EAAAADAQABAAABAQDU3jReR/MoSttlWYfauW6qEqS2dhe5
                                Zdd3guYk2H7ZyxblNuP56nOl/IMuniVmsFa9v8W6MExViu6G5Cy4iIesot09
                                1hsgkG0U7sbWrXM10PQ8pnpI3B5arplCiEMhRtXy64rlW3Nx156bLdcxv5l+
                                7Unu4IviKlY43uqqwSyTv+V8q4ThpQ9dNbk1Gg838+KzazljzHahtbIaE1rm
                                I0L1lUqKiKLSLKuBgrI2Y/WSuqvqGEz+bMH7Ri4ht+7sAwykph6FbOgKqoBI
                                hVWBo38/Na/gEuvtmgULUwK+xy9zWg9k8k/Qtihc6El9GD9y

Option 2: Seriellen Port prüfen

Sehen Sie sich die Ausgabe des seriellen Ports an.
Wählen Sie Serieller Port 1 aus.
Suchen Sie folgende Meldung:
```
INFO Wrote ssh-rsa host key to guest attributes
```
Wenn das Image ein unterstütztes Betriebssystem verwendet, aber die Einstellung für Gastattribute vor dem ersten VM-Start nicht aktiviert wurde, wird möglicherweise die folgende Meldung angezeigt:
```
Unable to write ssh-rsa host key to guest attributes
```
Dies bedeutet, dass für diese VM Hostschlüssel nicht als Gastattribute gespeichert werden. Wenn Sie Hostschlüssel für zusätzliche VMs speichern möchten, die Sie noch erstellen möchten, aktivieren Sie vor dem ersten Start der VM Gastattribute.

Verhindern, dass VMs über das öffentliche Internet erreichbar sind

Bei der Entwicklung von Projekten in Compute Engine gibt es verschiedene Szenarien, in denen verhindert werden soll, dass VMs aus dem öffentlichen Internet erreichbar sind:

Webdienste sind noch in der Entwicklung und noch nicht bereit, um externen Nutzern zugänglich gemacht zu werden, da ihre Funktionen noch nicht ausgereift sind oder noch nicht mit HTTPS konfiguriert wurden.
Die VM stellt unter Umständen Dienste zur Verfügung, die nur für den Gebrauch durch andere VMs in dem Projekt vorgesehen sind.
VMs sollten nur über entsprechende Verbindungsoptionen für Firmenbüros oder Rechenzentren zugänglich sein.

Auch wenn ein Dienst absichtlich mit dem Internet verbunden ist, ist es wichtig, dass die Kommunikation mit dem Dienst auf die Zielnutzergruppen beschränkt ist und über sichere Kanäle wie SSH oder HTTPS erfolgt, um vertrauliche Informationen zu schützen.

In diesem Artikel werden mehrere Methoden zum Sichern der Kommunikation mit VMs mit externen IP-Adressen und VMs ohne externe IP-Adressen beschrieben. Unabhängig davon, ob Sie die Kommunikation mit diesen Methoden sichern, ermöglicht Google Cloud immer die Kommunikation zwischen einer VM-Instanz und dem entsprechenden Metadatenserver. Weitere Informationen finden Sie unter Permanent zugelassener Traffic.

Dienste auf Geräten mit externen IP-Adressen schützen

Wenn VMs eine öffentliche IP-Adresse haben, ist es wichtig, dass nur die Dienste und der Traffic, der zugänglich gemacht werden soll, erreichbar sind, und auf den zugänglich gemachten Elementen alle vertraulichen Informationen während der Übermittlung gesichert sind. Es gibt mehrere Methoden zum Schutz von Diensten auf VMs mit externen IP-Adressen, die in diesem Dokument erläutert werden, einschließlich Firewalls, HTTPS und SSL, Portweiterleitung über SSH und SOCKS-Proxy über SSH.

Firewalls

Ihre erste Verteidigungslinie besteht darin, den Zugang auf die VM mithilfe von Firewalls zu beschränken. Mithilfe von Firewallregeln können Sie den gesamten Traffic zu einem Netzwerk oder zu Zielgeräten mit einem bestimmten Satz von Ports auf bestimmte Quell-IP-Adressen beschränken.

Firewalls sind keine eigenständige Lösung. Die Beschränkung des Traffics auf bestimmte Quell-IPs bietet keinen Schutz für vertrauliche Informationen wie Anmeldedaten, Befehle zum Erstellen oder Vernichten von Ressourcen oder Dateien oder Logs. Wenn Sie einen Webdienst auf einer öffentlich zugänglichen Maschine ausführen, wie z. B. eine Compute Engine-VM mit externer IP-Adresse, müssen Sie die gesamte Kommunikation zwischen Ihrem Host und der bereitgestellten VM verschlüsseln, um einen angemessenen Schutz zu gewährleisten.

Darüber hinaus sind Firewalls nicht immer die geeignete Lösung. Firewalls eignen sich zum Beispiel nicht für Entwicklungsumgebungen, die keine statischen IP-Adressen haben, wie z. B. Roaming-Laptops.

HTTPS und SSL

Für Produktionswebsysteme sollten Sie HTTPS/SSL konfigurieren. HTTPS/SSL kann entweder durch Einrichtung einer VM zum Beenden von HTTPS oder durch Konfiguration des HTTPS-Load-Balancings eingerichtet werden. HTTPS/SSL weist eine gewisse Komplexität auf. Aus diesem Grund müssen Sie zur Einrichtung folgende Aufgaben ausführen:

Registrieren Sie einen Domainnamen.
Erwerben Sie ein SSL-Zertifikat von einer Zertifizierungsstelle.
Registrieren Sie das Zertifikat bei Ihrem HTTPS-Load-Balancer und den damit verbundenen VMs oder konfigurieren Sie einen SSL-terminierten Webserver oder Proxy auf einer oder mehreren Compute Engine-VMs.

Portweiterleitung über SSH

Mit der Google Cloud CLI können Sie einen Server auf einem bestimmten lokalen Port starten, der den gesamten Traffic über eine SSH-Verbindung an einen Remote-Host weiterleitet.

Notieren Sie sich zuerst die VM und den Port, die den Dienst bereitstellen soll und zu dem Sie eine gesicherte Verbindung herstellen möchten. Als Nächstes führen Sie folgenden Befehl aus:

gcloud compute ssh VM_NAME \
    --project PROJECT_ID \
    --zone ZONE \
    -- -NL LOCAL_PORT:localhost:REMOTE_PORT

Ersetzen Sie Folgendes:

VM_NAME: Der Name der VM, zu der Sie eine Verbindung herstellen möchten.
PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
ZONE: Die Zone, in der die VM ausgeführt wird, z. B. us-central1-a
LOCAL_PORT: Der lokale Port, der überwacht wird, z. B. 2222
REMOTE_PORT: Der Remote-Port, zu dem Sie eine Verbindung herstellen, z. B. 8888

Wenn Sie beispielsweise den lokalen Port "2222" und den Remote-Port "8888" angeben und http://localhost:2222/ in Ihrem Browser öffnen, verwendet die HTTP-Verbindung den SSH-Tunnel, den Sie für den Remote-Host erstellt haben, um eine Verbindung zur angegebenen VM über SSH herzustellen. Die HTTP-Verbindung verwendet anschließend den SSH-Tunnel, um eine Verbindung zum Port 8888 auf demselben Computer herzustellen, jedoch über eine verschlüsselte, sichere SSH-Verbindung.

Der Befehl gcloud stellt eine SSH-Verbindung her und hält sie aufrecht, solange die SSH-Sitzung aktiv ist. Wenn Sie die SSH-Sitzung beenden, funktioniert die Portweiterleitung über http://VM_NAME:LOCAL_PORT nicht mehr.

Wenn Sie mehr als eine Portweiterleitungsregel festlegen möchten, können Sie mehrere Regeln mit einem einzelnen Befehl angeben, indem Sie die Flags wiederholen:

gcloud compute ssh VM_NAME \
    --project PROJECT_ID \
    --zone ZONE \
    -- -NL LOCAL_PORT:localhost:REMOTE_PORT \
    -- -NL LOCAL_PORT:localhost:REMOTE_PORT

Alternativ dazu können Sie jedes Mal einen neuen gcloud-Befehl ausführen, um einen separaten Tunnel zu erzeugen. Beachten Sie, dass Sie keine Portweiterleitung von einer vorhandenen Verbindung hinzufügen oder entfernen können, ohne die Verbindung zu trennen und erneut herzustellen.

SOCKS-Proxy über SSH

Wenn Sie eine Verbindung mit einer Reihe von verschiedenen Hosts in Ihrer Cloud-Bereitstellung herstellen möchten, ändern Sie hierfür am besten Ihren Browser, um auf diese direkt aus Ihrem Netzwerk zugreifen zu können. Mit diesem Ansatz können Sie den Kurznamen der Hosts verwenden, anstatt die IP-Adresse jedes einzelnen Hosts aufrufen, Ports für jeden Dienst öffnen oder einen SSH-Tunnel für jedes Host/Portpaar erstellen zu müssen.

Vorgehensweise:

Richten Sie einen einzelnen SSH-Tunnel auf einem der Hosts im Netzwerk ein und erstellen Sie einen SOCKS-Proxy auf diesem Host.
Ändern Sie die Browserkonfiguration, sodass alle Lookups über diesen SOCKS-Proxyhost erfolgen.

Da Sie den gesamten Traffic über diesen Host tunneln, sollten Sie das Internet nicht über diesen Browser oder dieses spezifische Profil nutzen, da Sie die Bandbreite Ihres Cloud-Dienstes dafür verwenden würden. Sie sollten dafür ein separates Browserprofil verwenden und es bei Bedarf wechseln.

Starten Sie den SOCKS-Proxy

Um den SOCKS-Proxy zu starten, führen Sie folgenden Befehl aus:

gcloud compute ssh VM_NAME \
    --project PROJECT_ID \
    --zone ZONE
    --ssh-flag="-D" \
    --ssh-flag="LOCAL_PORT" \
    --ssh-flag="-N"

Dabei gilt:

VM_NAME: Der Name der VM, zu der Sie eine Verbindung herstellen möchten.
PROJECT_ID: Ihre Google Cloud-Projekt-ID
ZONE: Die Zone, in der die VM ausgeführt wird, z. B. us-central1-a
LOCAL_PORT: Der lokale Port, der überwacht wird, z. B. 1080

Beachten Sie, dass in diesem Fall kein Remoteport angegeben werden muss. Da sich ein SOCKS-Proxy nicht mit einem bestimmten Remoteport verbindet, wird jede Verbindung, die Sie über den SOCKS-Proxy herstellen, relativ zum Host aufgelöst, zu dem Sie eine Verbindung herstellen.

Mit einem SOCKS-Proxy können Sie über den Kurznamen der VM eine Verbindung zu jeder VM herstellen, die sich im selben Compute Engine-Netzwerk wie Ihre Proxy-VM befindet. Darüber hinaus haben Sie die Möglichkeit, eine Verbindung zu einem beliebigen Port auf einer bestimmten VM herzustellen.

Dieser Ansatz ist viel flexibler als die einfache Portweiterleitungsmethode, erfordert aber auch die Änderung der Einstellungen Ihres Webbrowsers, um den Proxy nutzen zu können.

Konfigurieren Sie als Nächstes entweder Chrome oder Firefox, um den Proxy zu verwenden.

Chrome

Chrome verwendet standardmäßig systemweite Proxy-Einstellungen, sodass Sie einen anderen Proxy mit Befehlszeilen-Flags angeben müssen. Beim Starten von Chrome wird standardmäßig die VM eines bereits ausgeführten Profils erstellt. Wenn Sie also mehrere Kopien von Chrome gleichzeitig ausführen möchten, von denen eine den Proxy verwendet und andere den Proxy nicht verwenden, benötigen Sie ein neues Profil.

Starten Sie Chrome mit einem neuen Profil. Es wird automatisch erstellt, wenn keines vorhanden ist.

Linux:

/usr/bin/google-chrome \
    --user-data-dir="$HOME/chrome-proxy-profile" \
    --proxy-server="socks5://localhost:1080"

macOS:

"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
    --user-data-dir="$HOME/chrome-proxy-profile" \
    --proxy-server="socks5://localhost:1080"

Windows:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" ^
    --user-data-dir="%USERPROFILE%\chrome-proxy-profile" ^
    --proxy-server="socks5://localhost:1080"

Setzen Sie den Localhost-Port auf denselben Wert, den Sie zuvor im gcloud-Befehl verwendet haben (in unserem Beispiel 1080).

Firefox

Bevor Sie diese Einstellungen ändern, sollten Sie ein neues Firefox-Profil erstellen. Andernfalls betrifft die Nutzung dieses Hosts als Proxy alle VMs von Firefox, was Sie wahrscheinlich nicht möchten.

Nachdem Sie Firefox mit einem separaten Profil ausgeführt haben, können Sie den SOCKS-Proxy einrichten:

Öffnen Sie Einstellungen.
Klicken Sie auf Erweitert > Netzwerke > Einstellungen, um das Dialogfenster Verbindungseinstellungen zu öffnen.
Wählen Sie die Option Manuelle Proxykonfiguration.
1. Geben Sie im Abschnitt SOCKS-Host localhost als Host und den Port an, den Sie im zuvor ausgeführten Befehl von gcloud ausgewählt haben.
2. Wählen Sie SOCKS v5.
3. Markieren Sie das Feld Remote DNS.
4. Lassen Sie alle anderen Felder leer.
Klicken Sie auf OK und schließen Sie das Dialogfeld Einstellungen.

Verbindung zu VMs ohne externe IP-Adressen herstellen

Wenn VMs keine externen IP-Adressen haben (einschließlich VMs, die Back-Ends für HTTPS- und SSL-Proxy-Load-Balancer sind), können sie nur von Folgendem erreicht werden:

Von anderen VMs im Netzwerk
TCP-Weiterleitungsfeature von Identity-Aware Proxy
Über den Metadatenserver
Google Cloud SDK
Verwaltetes VPN-Gateway

Sie können VMs in Ihrem Netzwerk als vertrauenswürdige Relays für eingehende Verbindungen (auch als Bastion Hosts bezeichnet) bereitstellen. Darüber hinaus können Sie ein Cloud NAT für ausgehenden Netzwerktraffic konfigurieren oder die interaktive serielle Konsole zur Verwaltung oder Fehlerbehebung von VMs ohne externe IP-Adressen einrichten.

Bastion Hosts

Bastion Hosts stellen einen Zugangspunkt von außen in ein Netzwerk mit privaten Netzwerkinstanzen dar.

Die Architektur von Bastion Hosts stellt einen nach außen gerichteten Einstiegspunkt für ein Netzwerk privater Instanzen dar.

Dieser Host kann als ein einziger Verteidigungs- oder Prüfpunkt dienen und gestartet und gestoppt werden, um die eingehende SSH-Kommunikation aus dem Internet zu aktivieren oder zu deaktivieren. Durch die Nutzung eines Bastion Hosts können Sie eine Verbindung zu einer VM herstellen, die keine externe IP-Adresse hat. So können Sie beispielsweise eine Verbindung zu einer Entwicklungsumgebung herstellen oder die Datenbankinstanz für Ihre externe Anwendung verwalten, ohne zusätzliche Firewallregeln zu konfigurieren.

Die vollständige Härtung eines Bastion Hosts kann dieser Artikel nicht darstellen, erste Schritte könnten jedoch folgende sein:

Einschränkung des CIDR-Bereichs der Quell-IPs, die mit dem Bastion-Host kommunizieren können.
Konfigurieren von Firewallregeln, um nur SSH-Traffic an private VMs zuzulassen, der vom Bastion Host kommt

SSH ist auf VMs standardmäßig so konfiguriert, dass private Schlüssel für die Authentifizierung verwendet werden. Bei Verwendung eines Bastion Hosts melden Sie sich zuerst beim Bastion Host und dann bei der privaten Ziel-VM an. Aufgrund dieser zweistufigen Anmeldung, aus der sich auch die Bezeichnung "Jump-Server" für Bastion Hosts ableitet, sollten Sie die ssh-Weiterleitung verwenden, anstatt den privaten Schlüssel des Zielcomputers auf dem Bastion Host zu speichern, um den Zielcomputer zu erreichen. Sie müssen selbst dann so vorgehen, wenn Sie dasselbe Schlüsselpaar für den Bastion Host und die Ziel-VMs verwenden, da der Bastion Host nur auf die öffentliche Hälfte des Schlüsselpaars direkten Zugriff hat.

Informationen zum Verwenden einer Bastion Host-Instanz, um eine Verbindung zu anderen VMs in Ihrem Google Cloud-Netzwerk herzustellen, finden Sie unter Verbindung zu Linux-VMs über einen Bastion Host herstellen.

Informationen, wie Sie mithilfe der ssh-Weiterleitung und anderer Methoden eine Verbindung zu VMs herstellen, die keine externe IP-Adresse haben, erhalten Sie unter Verbindung zu VMs herstellen, die keine externen IP-Adressen haben.

IAP für die TCP-Weiterleitung

Wenn Sie SSH mit dem TCP-Weiterleitungsfeature von IAP verwenden, wird eine SSH-Verbindung in HTTPS eingebunden. Das TCP-Weiterleitungsfeature von IAP sendet sie dann an die Remote-VM.

Informationen zum Herstellen einer Verbindung zu einer Remote-VM mit IAP finden Sie unter Verbindung zu Linux-VMs über Identity-Aware Proxy herstellen.

VPN

Cloud VPN ermöglicht es Ihnen, Ihr bestehendes Netzwerk über eine IPsec-Verbindung zu einem VPN-Gateway mit Ihrem Google Cloud-Netzwerk zu verbinden. So wird das direkte Routing des lokalen Traffics zu den privaten IP-Schnittstellen von Compute Engine-VMs ermöglicht. Der Traffic wird verschlüsselt, während er über öffentliche Links an Google weitergeleitet wird.

Ausführliche Informationen zum Einrichten, Konfigurieren und Verwenden von VPN mit Compute Engine finden Sie in der Cloud VPN-Dokumentation.

Informationen zum Herstellen einer Verbindung zu VMs in Ihrem Google Cloud-Netzwerk über ein vorhandenes VPN statt über externe IP-Adressen der VMs finden Sie unter Verbindung zu Linux-VMs über Cloud VPN oder Cloud Interconnect herstellen.

Ausgehender Traffic mit Cloud NAT

Wenn einer VM keine externe IP-Adresse zugewiesen wurde, kann sie keine direkte Verbindung zu externen Diensten herstellen, einschließlich anderer Google Cloud-Dienste. Damit Dienste im öffentlichen Internet für diese VMs erreichbar sind, können Sie Cloud NAT einrichten und konfigurieren, das Traffic im Namen einer beliebigen VM im Netzwerk weiterleiten kann. Eine einzelne VM kann aber nicht als hochverfügbar angesehen werden und für mehrere VMs wird kein hoher Trafficdurchsatz unterstützt.

Interaktiver serieller Konsolenzugriff

Wenn eine VM keine externe IP-Adresse hat, müssen Sie zur Fehlerbehebung oder zu Wartungszwecken möglicherweise weiterhin mit der VM interagieren. Die Einrichtung eines Bastion Hosts, wie oben ausgeführt, ist eine Option, erfordert aber möglicherweise eine umfassendere Einrichtung, als für Ihren Bedarf sinnvoll wäre. Wenn Sie Fehler auf einer Instanz ohne externe IP-Adresse beheben möchten, sollten Sie den interaktiven Zugriff auf die serielle Konsole aktivieren. Hierdurch können Sie mithilfe von SSH mit der seriellen Konsole einer Instanz interagieren und Befehle über die serielle Konsole ausführen.

Weitere Informationen finden Sie unter Mit der seriellen Konsole interagieren.

HTTPS- und SSL-Proxy-Load-Balancer

VMs, die als Back-Ends für HTTPS- und SSL-Proxy-Load-Balancer dienen, müssen für den Zugriff über den Load-Balancer keine externen IP-Adressen haben. Für den direkten Zugriff auf diese Ressourcen verwenden Sie die unter Verbindung zu VMs ohne externe IP-Adressen herstellen aufgeführten Methoden.

Weitere Informationen finden Sie in der Dokumentation zu Load-Balancing.