DoiT acquires SELECT to optimize Snowflake and BigQuery
Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Privater Zugriff auf Dienste in überlappenden Netzwerken in Google Cloud

By Chimbu ChinnaduraiMay 23, 20235 min read

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

gcp-vpc-doit-international

In der Google Cloud Platform (GCP) startet jedes neue Projekt mit einem Standard-VPC-Netzwerk, sobald Sie die Compute Engine API aktivieren – sofern Sie es nicht deaktivieren.

Das vereinfacht die Nutzung von GCP, weil Sie keine eigene VPC und keine Subnetze anlegen müssen. Der Haken am Standardnetzwerk: Alle automatisch erstellten Subnetze nutzen vordefinierte IPv4-Bereiche innerhalb des CIDR-Blocks 10.128.0.0/9.

Aufgrund dieser überlappenden Netzwerke ist eine private interne Kommunikation zwischen Projekten nicht möglich. Die Einschränkung gilt sowohl für VPC Peering als auch für Cloud VPN.

In diesem Blogbeitrag zeigen wir Ihnen, wie Sie mit Private Service Connect privat auf Dienste zugreifen, die in VM- oder GKE-Clustern mit überlappenden Netzwerken laufen. Das funktioniert für überlappende Netzwerke innerhalb derselben oder unterschiedlicher GCP-Organisationen.

Referenzarchitektur

default-vpc

Ziel-Setup für Private Service Connect

Projekt B ist das Service-Producer-Projekt, in dem ein nginx-Beispieldienst auf einer Instanz innerhalb einer Managed Instance Group läuft.

Projekt A ist das Service-Consumer-Projekt und benötigt privaten Zugriff auf den Dienst in Projekt B. Den Instanzen in beiden Projekten ist keine externe IP zugewiesen.

  • GCP-Region für die Ressourcen: us-west4
  • Die API compute.googleapis.com ist in Projekt A und Projekt B aktiviert
  • Cloud NAT, damit private Instanzen Pakete aus dem Internet herunterladen können

Beispieldienst und Testinstanz bereitstellen

Passen Sie die Variablen in den folgenden Befehlen an Ihre Umgebung an.

  • Legen Sie ein Instanz-Template in Projekt B an.
gcloud compute instance-templates create nginx-service-instance-template \
--machine-type=e2-medium \
--network-interface=network=default,no-address \
--metadata=startup-script=\ \#\!\ /bin/bash
google


    

  • Legen Sie eine Managed Instance Group in Projekt B an.
    • 



gcloud beta compute instance-groups managed create nginx-service-instance-group \
--base-instance-name=nginx-service \
--size=1 \
--template=nginx-service-instance-template \
--zone=us-west4-a \
--list-managed-instances-results=PAGELESS \
--no-force-update-on-repair \
--project=$PROJECT_B
Nach erfolgreicher Erstellung startet die Managed Instance Group automatisch eine Instanz in der Zielzone.


Verbinden Sie sich per SSH mit der Instanz und prüfen Sie den Status des nginx-Dienstes.


nginx


gcp


gcp


    

  • Legen Sie eine Testinstanz für die Konnektivitätsprüfung in Projekt A an.
    • 



gcloud compute instances create instance-1 \
    --zone=us-west4-b \
    --machine-type=e2-medium \
    --network-interface=stack-type=IPV4_ONLY,subnet=default,no-address \
    --maintenance-policy=MIGRATE \
    --provisioning-model=STANDARD \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --create-disk=auto-delete=yes,boot=yes,device-name=instance-2,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=projects/project-a-385206/zones/us-west4-b/diskTypes/pd-balanced \
    --no-shielded-secure-boot \
    --shielded-vtpm \
    --shielded-integrity-monitoring \
    --labels=ec-src=vm_add-gcloud \
    --reservation-affinity=any \
    --project=$PROJECT_A
google cloud shared vpc


Zwischen den Netzwerken von Projekt A und Projekt B besteht keine interne Verbindung. Die Instanz in Projekt A kann daher nicht auf den Dienst in Projekt B zugreifen.


VPC Peering scheidet wegen der überlappenden Bereiche im Standardnetzwerk aus.


Internen Load Balancer einrichten


Damit Private Service Connect den Dienst über ein Service Attachment bereitstellen kann, ist ein interner Load Balancer erforderlich. Für dieses Setup richten wir in Projekt B einen internen TCP-Load-Balancer ein.


    

  • Legen Sie einen neuen regionalen HTTP-Health-Check an, der die HTTP-Konnektivität zu den VMs auf Port 80 prüft.
    • 



gcloud compute health-checks create http nginx-service-health-check \
    --region=us-west4 \
    --port=80 \
    --project=$PROJECT_B
    

  • Legen Sie den Backend-Dienst für den HTTP-Traffic an.
    • 



gcloud compute backend-services create nginx-service-internal-lb-backend \
    --load-balancing-scheme=internal \
    --protocol=tcp \
    --region=us-west4 \
    --health-checks=nginx-service-health-check \
    --health-checks-region=us-west4 \
    --project=$PROJECT_B
    

  • Hängen Sie die nginx-Service-Instance-Group an den Backend-Dienst an.
    • 



gcloud compute backend-services add-backend nginx-service-internal-lb-backend \
    --region=us-west4 \
    --instance-group=nginx-service-instance-group \
    --instance-group-zone=us-west4-a \
    --project=$PROJECT_B
    

  • Legen Sie eine Forwarding Rule für den Backend-Dienst an.
    • 



gcloud compute forwarding-rules create nginx-service-internal-fr \
    --region=us-west4 \
    --load-balancing-scheme=internal \
    --network=default \
    --subnet=default \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=nginx-service-internal-lb-backend \
    --backend-service-region=us-west4 \
    --project=$PROJECT_B
    

  • Richten Sie eine Firewall-Regel ein, die Health Checks des Load Balancers zulässt.
    • 



gcloud compute firewall-rules create allow-internal-lb-health-check \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=35.191.0.0/16,130.211.0.0/22
--project=$PROJECT_B
vpc in google cloud


google


Dienste im Service-Producer-Projekt veröffentlichen


Veröffentlichen Sie den Dienst in Projekt B – dem Service-Producer-Projekt –, damit Consumer aus anderen VPC-Netzwerken privat und sicher darauf zugreifen können.


    

  • Reservieren Sie ein Subnetz für Private Service Connect. Dieser Subnetzbereich darf sich nicht mit dem Standardnetzwerk überschneiden.
    • 



gcloud compute networks subnets create private-service-connect \
--network default \
--region us-west4 \
--range 10.0.1.0/24 \
--purpose=PRIVATE_SERVICE_CONNECT \
--project=$PROJECT_B
    

  • Geben Sie den nginx-Dienst für Projekt A frei – mit expliziter Projektgenehmigung.
    • 



gcloud compute service-attachments create nginx-service \
    --region=us-west4 \
    --producer-forwarding-rule=nginx-service-internal-fr  \
    --connection-preference=ACCEPT_MANUAL \
    --nat-subnets=private-service-connect \
    --consumer-accept-list=$PROJECT_A=10 \
    --project=$PROJECT_B
Sie können steuern, welche Consumer auf die veröffentlichten Dienste zugreifen dürfen – wahlweise per automatischer oder manueller Freigabe. Details dazu finden Sie unter Publish services by using Private Service Connect.


    

  • Richten Sie eine Firewall-Regel ein, damit Private Service Connect auf die Zielinstanzen zugreifen darf.
    • 



gcloud compute firewall-rules create allow-private-service-connect \
--direction=INGRESS \
--priority=1000 \
--network=default \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=10.0.1.0/24
--project=$PROJECT_B
shared


gcloud


Endpoint im Service-Consumer-Projekt konfigurieren


Ein Endpoint im Service-Consumer-Projekt verbindet sich über eine Private-Service-Connect-Forwarding-Rule mit Diensten im VPC-Netzwerk des Producers.


Beim Anlegen eines Endpoints wird dieser automatisch im Service Directory registriert – entweder unter einem von Ihnen gewählten Namespace oder unter dem Standard-Namespace goog-psc-default.


Damit der Endpoint aus mehreren Regionen erreichbar ist, aktivieren Sie Global Access. Global Access befindet sich derzeit in der Preview.


    

  • Reservieren Sie eine interne IP-Adresse für den Endpoint.
    • 



gcloud compute addresses create private-service-connect-endpoint \
    --region=us-west4 \
    --subnet=default \
    --project=$PROJECT_A
    

  • Legen Sie eine Forwarding Rule an, die den Endpoint mit dem Service Attachment in Projekt B verbindet.
    • 



PSC_SERVICE_ATTACHMENT=$(gcloud compute service-attachments describe nginx-service \
   --region=us-west4 \
   --project=$PROJECT_B \
   --format="value(selfLink.scope(projects))")


gcloud compute forwarding-rules create nginx-service \
  --region=us-west4 \
  --network=default \
  --address=private-service-connect-endpoint \
  --target-service-attachment="projects/$PSC_SERVICE_ATTACHMENT" \
  --project=$PROJECT_A
vpc network gcp


google


Konnektivität aus dem Consumer-Projekt testen


Die Private-Service-Connect-Komponenten sind nun in Projekt A und Projekt B eingerichtet. Verwenden Sie die Endpoint-IP in Projekt A, um auf den nginx-Dienst in Projekt B zuzugreifen.


Der Test bestätigt: Die Instanzen in den überlappenden Netzwerken kommunizieren über den Private Service Connect Endpoint privat miteinander.


google


Dieses Beispiel zeigt, wie Sie mit Private Service Connect Dienste in überlappenden Netzwerken sicher veröffentlichen und konsumieren.


Der Traffic bleibt durchgängig innerhalb von Google Cloud. Consumer und Producer erhalten so einen serviceorientierten Zugriff – mit granularer Kontrolle darüber, wer wie auf welche Dienste zugreift.


Mehr zu Private Service Connect erfahren Sie auf der Produktseite.

\n'yum\ install\ epel-release
google


    

  • Legen Sie eine Managed Instance Group in Projekt B an.
    • 



Nach erfolgreicher Erstellung startet die Managed Instance Group automatisch eine Instanz in der Zielzone.


Verbinden Sie sich per SSH mit der Instanz und prüfen Sie den Status des nginx-Dienstes.


nginx


gcp


gcp


    

  • Legen Sie eine Testinstanz für die Konnektivitätsprüfung in Projekt A an.
    • 



google cloud shared vpc


Zwischen den Netzwerken von Projekt A und Projekt B besteht keine interne Verbindung. Die Instanz in Projekt A kann daher nicht auf den Dienst in Projekt B zugreifen.


VPC Peering scheidet wegen der überlappenden Bereiche im Standardnetzwerk aus.


Internen Load Balancer einrichten


Damit Private Service Connect den Dienst über ein Service Attachment bereitstellen kann, ist ein interner Load Balancer erforderlich. Für dieses Setup richten wir in Projekt B einen internen TCP-Load-Balancer ein.


    

  • Legen Sie einen neuen regionalen HTTP-Health-Check an, der die HTTP-Konnektivität zu den VMs auf Port 80 prüft.
    • 



    

  • Legen Sie den Backend-Dienst für den HTTP-Traffic an.
    • 



    

  • Hängen Sie die nginx-Service-Instance-Group an den Backend-Dienst an.
    • 



    

  • Legen Sie eine Forwarding Rule für den Backend-Dienst an.
    • 



    

  • Richten Sie eine Firewall-Regel ein, die Health Checks des Load Balancers zulässt.
    • 



vpc in google cloud


google


Dienste im Service-Producer-Projekt veröffentlichen


Veröffentlichen Sie den Dienst in Projekt B – dem Service-Producer-Projekt –, damit Consumer aus anderen VPC-Netzwerken privat und sicher darauf zugreifen können.


    

  • Reservieren Sie ein Subnetz für Private Service Connect. Dieser Subnetzbereich darf sich nicht mit dem Standardnetzwerk überschneiden.
    • 



    

  • Geben Sie den nginx-Dienst für Projekt A frei – mit expliziter Projektgenehmigung.
    • 



Sie können steuern, welche Consumer auf die veröffentlichten Dienste zugreifen dürfen – wahlweise per automatischer oder manueller Freigabe. Details dazu finden Sie unter Publish services by using Private Service Connect.


    

  • Richten Sie eine Firewall-Regel ein, damit Private Service Connect auf die Zielinstanzen zugreifen darf.
    • 



shared


gcloud


Endpoint im Service-Consumer-Projekt konfigurieren


Ein Endpoint im Service-Consumer-Projekt verbindet sich über eine Private-Service-Connect-Forwarding-Rule mit Diensten im VPC-Netzwerk des Producers.


Beim Anlegen eines Endpoints wird dieser automatisch im Service Directory registriert – entweder unter einem von Ihnen gewählten Namespace oder unter dem Standard-Namespace goog-psc-default.


Damit der Endpoint aus mehreren Regionen erreichbar ist, aktivieren Sie Global Access. Global Access befindet sich derzeit in der Preview.


    

  • Reservieren Sie eine interne IP-Adresse für den Endpoint.
    • 



    

  • Legen Sie eine Forwarding Rule an, die den Endpoint mit dem Service Attachment in Projekt B verbindet.
    • 



vpc network gcp


google


Konnektivität aus dem Consumer-Projekt testen


Die Private-Service-Connect-Komponenten sind nun in Projekt A und Projekt B eingerichtet. Verwenden Sie die Endpoint-IP in Projekt A, um auf den nginx-Dienst in Projekt B zuzugreifen.


Der Test bestätigt: Die Instanzen in den überlappenden Netzwerken kommunizieren über den Private Service Connect Endpoint privat miteinander.


google


Dieses Beispiel zeigt, wie Sie mit Private Service Connect Dienste in überlappenden Netzwerken sicher veröffentlichen und konsumieren.


Der Traffic bleibt durchgängig innerhalb von Google Cloud. Consumer und Producer erhalten so einen serviceorientierten Zugriff – mit granularer Kontrolle darüber, wer wie auf welche Dienste zugreift.


Mehr zu Private Service Connect erfahren Sie auf der Produktseite.

\n'yum\ -y\ install\ nginx
google


    

  • Legen Sie eine Managed Instance Group in Projekt B an.
    • 



Nach erfolgreicher Erstellung startet die Managed Instance Group automatisch eine Instanz in der Zielzone.


Verbinden Sie sich per SSH mit der Instanz und prüfen Sie den Status des nginx-Dienstes.


nginx


gcp


gcp


    

  • Legen Sie eine Testinstanz für die Konnektivitätsprüfung in Projekt A an.
    • 



google cloud shared vpc


Zwischen den Netzwerken von Projekt A und Projekt B besteht keine interne Verbindung. Die Instanz in Projekt A kann daher nicht auf den Dienst in Projekt B zugreifen.


VPC Peering scheidet wegen der überlappenden Bereiche im Standardnetzwerk aus.


Internen Load Balancer einrichten


Damit Private Service Connect den Dienst über ein Service Attachment bereitstellen kann, ist ein interner Load Balancer erforderlich. Für dieses Setup richten wir in Projekt B einen internen TCP-Load-Balancer ein.


    

  • Legen Sie einen neuen regionalen HTTP-Health-Check an, der die HTTP-Konnektivität zu den VMs auf Port 80 prüft.
    • 



    

  • Legen Sie den Backend-Dienst für den HTTP-Traffic an.
    • 



    

  • Hängen Sie die nginx-Service-Instance-Group an den Backend-Dienst an.
    • 



    

  • Legen Sie eine Forwarding Rule für den Backend-Dienst an.
    • 



    

  • Richten Sie eine Firewall-Regel ein, die Health Checks des Load Balancers zulässt.
    • 



vpc in google cloud


google


Dienste im Service-Producer-Projekt veröffentlichen


Veröffentlichen Sie den Dienst in Projekt B – dem Service-Producer-Projekt –, damit Consumer aus anderen VPC-Netzwerken privat und sicher darauf zugreifen können.


    

  • Reservieren Sie ein Subnetz für Private Service Connect. Dieser Subnetzbereich darf sich nicht mit dem Standardnetzwerk überschneiden.
    • 



    

  • Geben Sie den nginx-Dienst für Projekt A frei – mit expliziter Projektgenehmigung.
    • 



Sie können steuern, welche Consumer auf die veröffentlichten Dienste zugreifen dürfen – wahlweise per automatischer oder manueller Freigabe. Details dazu finden Sie unter Publish services by using Private Service Connect.


    

  • Richten Sie eine Firewall-Regel ein, damit Private Service Connect auf die Zielinstanzen zugreifen darf.
    • 



shared


gcloud


Endpoint im Service-Consumer-Projekt konfigurieren


Ein Endpoint im Service-Consumer-Projekt verbindet sich über eine Private-Service-Connect-Forwarding-Rule mit Diensten im VPC-Netzwerk des Producers.


Beim Anlegen eines Endpoints wird dieser automatisch im Service Directory registriert – entweder unter einem von Ihnen gewählten Namespace oder unter dem Standard-Namespace goog-psc-default.


Damit der Endpoint aus mehreren Regionen erreichbar ist, aktivieren Sie Global Access. Global Access befindet sich derzeit in der Preview.


    

  • Reservieren Sie eine interne IP-Adresse für den Endpoint.
    • 



    

  • Legen Sie eine Forwarding Rule an, die den Endpoint mit dem Service Attachment in Projekt B verbindet.
    • 



vpc network gcp


google


Konnektivität aus dem Consumer-Projekt testen


Die Private-Service-Connect-Komponenten sind nun in Projekt A und Projekt B eingerichtet. Verwenden Sie die Endpoint-IP in Projekt A, um auf den nginx-Dienst in Projekt B zuzugreifen.


Der Test bestätigt: Die Instanzen in den überlappenden Netzwerken kommunizieren über den Private Service Connect Endpoint privat miteinander.


google


Dieses Beispiel zeigt, wie Sie mit Private Service Connect Dienste in überlappenden Netzwerken sicher veröffentlichen und konsumieren.


Der Traffic bleibt durchgängig innerhalb von Google Cloud. Consumer und Producer erhalten so einen serviceorientierten Zugriff – mit granularer Kontrolle darüber, wer wie auf welche Dienste zugreift.


Mehr zu Private Service Connect erfahren Sie auf der Produktseite.

\n'systemctl\ start\ nginx \
--maintenance-policy=MIGRATE \
--provisioning-model=STANDARD \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--create-disk=auto-delete=yes,boot=yes,device-name=nginx-service-instance-template,image=projects/centos-cloud/global/images/centos-7-v20230411,mode=rw,size=20,type=pd-balanced \
--no-shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring \
--reservation-affinity=any \
--project=$PROJECT_B

google

  • Legen Sie eine Managed Instance Group in Projekt B an.

Nach erfolgreicher Erstellung startet die Managed Instance Group automatisch eine Instanz in der Zielzone.

Verbinden Sie sich per SSH mit der Instanz und prüfen Sie den Status des nginx-Dienstes.

nginx

gcp

gcp

  • Legen Sie eine Testinstanz für die Konnektivitätsprüfung in Projekt A an.

google cloud shared vpc

Zwischen den Netzwerken von Projekt A und Projekt B besteht keine interne Verbindung. Die Instanz in Projekt A kann daher nicht auf den Dienst in Projekt B zugreifen.

VPC Peering scheidet wegen der überlappenden Bereiche im Standardnetzwerk aus.

Internen Load Balancer einrichten

Damit Private Service Connect den Dienst über ein Service Attachment bereitstellen kann, ist ein interner Load Balancer erforderlich. Für dieses Setup richten wir in Projekt B einen internen TCP-Load-Balancer ein.

  • Legen Sie einen neuen regionalen HTTP-Health-Check an, der die HTTP-Konnektivität zu den VMs auf Port 80 prüft.
  • Legen Sie den Backend-Dienst für den HTTP-Traffic an.
  • Hängen Sie die nginx-Service-Instance-Group an den Backend-Dienst an.
  • Legen Sie eine Forwarding Rule für den Backend-Dienst an.
  • Richten Sie eine Firewall-Regel ein, die Health Checks des Load Balancers zulässt.

vpc in google cloud

google

Dienste im Service-Producer-Projekt veröffentlichen

Veröffentlichen Sie den Dienst in Projekt B – dem Service-Producer-Projekt –, damit Consumer aus anderen VPC-Netzwerken privat und sicher darauf zugreifen können.

  • Reservieren Sie ein Subnetz für Private Service Connect. Dieser Subnetzbereich darf sich nicht mit dem Standardnetzwerk überschneiden.
  • Geben Sie den nginx-Dienst für Projekt A frei – mit expliziter Projektgenehmigung.

Sie können steuern, welche Consumer auf die veröffentlichten Dienste zugreifen dürfen – wahlweise per automatischer oder manueller Freigabe. Details dazu finden Sie unter Publish services by using Private Service Connect.

  • Richten Sie eine Firewall-Regel ein, damit Private Service Connect auf die Zielinstanzen zugreifen darf.

shared

gcloud

Endpoint im Service-Consumer-Projekt konfigurieren

Ein Endpoint im Service-Consumer-Projekt verbindet sich über eine Private-Service-Connect-Forwarding-Rule mit Diensten im VPC-Netzwerk des Producers.

Beim Anlegen eines Endpoints wird dieser automatisch im Service Directory registriert – entweder unter einem von Ihnen gewählten Namespace oder unter dem Standard-Namespace goog-psc-default.

Damit der Endpoint aus mehreren Regionen erreichbar ist, aktivieren Sie Global Access. Global Access befindet sich derzeit in der Preview.

  • Reservieren Sie eine interne IP-Adresse für den Endpoint.
  • Legen Sie eine Forwarding Rule an, die den Endpoint mit dem Service Attachment in Projekt B verbindet.

vpc network gcp

google

Konnektivität aus dem Consumer-Projekt testen

Die Private-Service-Connect-Komponenten sind nun in Projekt A und Projekt B eingerichtet. Verwenden Sie die Endpoint-IP in Projekt A, um auf den nginx-Dienst in Projekt B zuzugreifen.

Der Test bestätigt: Die Instanzen in den überlappenden Netzwerken kommunizieren über den Private Service Connect Endpoint privat miteinander.

google

Dieses Beispiel zeigt, wie Sie mit Private Service Connect Dienste in überlappenden Netzwerken sicher veröffentlichen und konsumieren.

Der Traffic bleibt durchgängig innerhalb von Google Cloud. Consumer und Producer erhalten so einen serviceorientierten Zugriff – mit granularer Kontrolle darüber, wer wie auf welche Dienste zugreift.

Mehr zu Private Service Connect erfahren Sie auf der Produktseite.