Mit Private Service Connect und Hybrid-NEG-TCP-Proxy über Hybridnetzwerke eine Verbindung zu lokalen Diensten herstellen

1. Einführung

Mit einem internen regionalen TCP-Proxy-Load-Balancer mit Hybridkonnektivität können Sie einen Dienst, der lokal oder in anderen Cloud-Umgebungen gehostet wird, für Clients in Ihrem VPC-Netzwerk verfügbar machen.

Wenn Sie den Hybriddienst in anderen VPC-Netzwerken verfügbar machen möchten, können Sie den Dienst mit Private Service Connect veröffentlichen. Wenn Sie einen Dienstanhang vor Ihrem internen regionalen TCP-Proxy-Load-Balancer platzieren, können Sie Clients in anderen VPC-Netzwerken den Zugriff auf die Hybriddienste ermöglichen, die lokal oder in anderen Cloud-Umgebungen ausgeführt werden.

Umfang

In diesem Codelab erstellen Sie einen internen TCP-Proxy-Load-Balancer mit Hybridkonnektivität zu einem lokalen Dienst mithilfe einer Netzwerk-Endpunktgruppe. Über die Consumer-VPC kann mit dem lokalen Dienst kommuniziert werden.

Lerninhalte

Internen TCP-Proxy-Load-Balancer mit Hybrid-NEG-Backend-Dienst erstellen
Private Service Connect-Producer (Dienstanhang) und -Consumer (Weiterleitungsregel) einrichten
Kommunikation zwischen Nutzer- und Erstellerdienst testen und validieren

Voraussetzungen

Eingerichtetes Hybrid Networking, z. B. HA VPN, Interconnect, SW-WAN
Google Cloud-Projekt

Hybridkonnektivität einrichten

Ihre Google Cloud-Umgebung, lokale Umgebung oder sonstige Cloud-Umgebung muss über Hybridkonnektivität verbunden sein. Dafür werden entweder Cloud Interconnect-VLAN-Anhänge oder Cloud VPN-Tunnel mit Cloud Router verwendet. Wir empfehlen die Verwendung einer Verbindung mit Hochverfügbarkeit.

Ein Cloud Router, der für das globale dynamische Routing aktiviert ist, erkennt den spezifischen Endpunkt über BGP und programmiert ihn in Ihrem Google Cloud-VPC-Netzwerk. Regionales dynamisches Routing wird nicht unterstützt. Statische Routen werden ebenfalls nicht unterstützt.

Das Google Cloud-VPC-Netzwerk, mit dem Sie entweder Cloud Interconnect oder Cloud VPN konfigurieren, ist dasselbe Netzwerk, das Sie auch zum Konfigurieren der Bereitstellung des Hybrid-Load-Balancing verwenden. Achten Sie darauf, dass die Subnetz-CIDR-Bereiche Ihres VPC-Netzwerks nicht mit Ihren Remote-CIDR-Bereichen in Konflikt stehen. Bei Überschneidung von IP-Adressen haben Subnetzrouten Vorrang vor Remote-Verbindungen.

Weitere Informationen finden Sie unter:

Benutzerdefiniertes Routen-Advertising

Für Subnetze unterhalb von sind benutzerdefinierte Advertisements vom Cloud Router zum lokalen Netzwerk erforderlich, damit die lokalen Firewallregeln aktualisiert werden.

Subnetz	Beschreibung
172.16.0.0/23	TCP-Proxy-Subnetz für die direkte Kommunikation mit dem lokalen Dienst
130.211.0.0/22, 35.191.0.0/16	Google Cloud Health Check

2. Hinweis

Projekt für das Codelab aktualisieren

In diesem Codelab werden $variables verwendet, um die Implementierung der gcloud-Konfiguration in Cloud Shell zu erleichtern.

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. Einrichtung für Ersteller

Ersteller-VPC erstellen

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

Producer-Subnetze erstellen

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

TCP-Proxy-Subnetze erstellen

Die Proxyzuweisung erfolgt auf VPC-Ebene, nicht auf der Load-Balancer-Ebene. Sie müssen in jeder Region eines virtuellen Netzwerks (VPC), in dem Sie Envoy-basierte Load-Balancer verwenden, ein Nur-Proxy-Subnetz erstellen. Wenn Sie mehrere Load-Balancer in derselben Region und im selben VPC-Netzwerk bereitstellen, nutzen sie dasselbe Nur-Proxy-Subnetz für das Load-Balancing.

Ein Client stellt eine Verbindung zur IP-Adresse und zum Port der Weiterleitungsregel des Load-Balancers her.
Jeder Proxy überwacht die IP-Adresse und den Port, die in der Weiterleitungsregel des entsprechenden Load-Balancers angegeben sind. Einer der Proxys empfängt und beendet die Netzwerkverbindung des Clients.
Der Proxy stellt eine Verbindung zur entsprechenden Back-End-VM oder zum entsprechenden Back-End-Endpunkt einer Netzwerk-Endpunktgruppe her. Dies richtet sich nach der URL-Zuordnung und den Back-End-Diensten des Load-Balancers.

Nur-Proxy-Subnetze müssen unabhängig davon erstellt werden, ob Ihr Netzwerk im automatischen oder im benutzerdefinierten Modus arbeitet. Ein Nur-Proxy-Subnetz muss mindestens 64 IP-Adressen bereitstellen. Das entspricht einer Präfixlänge von maximal /26. Als Subnetzgröße wird /23 (512 Nur-Proxy-Adressen) empfohlen.

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

Private Service Connect-NAT-Subnetze erstellen

Erstellen Sie ein oder mehrere dedizierte Subnetze für die Verwendung von Private Service Connect. Wenn Sie die Google Cloud Console zum Veröffentlichen eines Dienstes verwenden, können Sie die Subnetze während dieses Verfahrens erstellen. Erstellen Sie das Subnetz in derselben Region wie den Load-Balancer des Dienstes. Sie können ein reguläres Subnetz nicht in ein Private Service Connect-Subnetz umwandeln.

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

Firewallregeln für den Producer erstellen

Konfigurieren Sie Firewallregeln, um Traffic zwischen den Private Service Connect-Endpunkten und dem Dienstanhang zuzulassen. Im Codelab wurde eine Firewallregel für eingehenden Traffic erstellt, die dem NAT-Subnetz 100.100.10.0/24 den Zugriff auf den Private Service Connect-Dienstanhang (interner Load-Balancer) ermöglicht.

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

Erstellen Sie in Cloud Shell die Regel „fw-allow-health-check“, damit die Google Cloud-Systemdiagnosen den lokalen Dienst (Back-End-Dienst) auf dem TCP-Port 80 erreichen können.

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

Erstellen Sie eine Firewallregel für eingehenden Traffic, die es lokalen Diensten ermöglicht, über Port 80 mit dem Proxy-Subnetz zu kommunizieren.

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

Hybridkonnektivitäts-NEG einrichten

Verwenden Sie beim Erstellen der NEG eine ZONE,die die geografische Entfernung zwischen Google Cloud und Ihrer lokalen oder sonstigen Cloud-Umgebung minimiert. Wenn Sie beispielsweise einen Dienst in einer lokalen Umgebung in Frankfurt hosten, können Sie beim Erstellen der NEG die Google Cloud-Zone „europe-west3-a“ angeben.

Wenn Sie Cloud Interconnect verwenden, sollte sich die ZONE zum Erstellen der NEG in derselben Region befinden, in der der Cloud Interconnect-Anhang konfiguriert wurde.

Informationen zu den verfügbaren Regionen und Zonen finden Sie in der Compute Engine-Dokumentation: Verfügbare Regionen und Zonen.

Erstellen Sie in Cloud Shell mit dem Befehl gcloud compute network-endpoint-groups create eine Hybridkonnektivitäts-NEG.

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

Fügen Sie in Cloud Shell den lokalen IP:Port-Endpunkt zur Hybrid-NEG hinzu.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

Load-Balancer konfigurieren

In den folgenden Schritten konfigurieren Sie den Load Balancer (Weiterleitungsregel) und verknüpfen ihn mit der Netzwerk-Endpunktgruppe.

Erstellen Sie in Cloud Shell die regionale Systemdiagnose, die an den lokalen Dienst übergeben wird.

gcloud compute health-checks create tcp on-prem-service-hc \
    --region=us-central1 \
    --use-serving-port

Erstellen Sie in Cloud Shell den Backend-Dienst für das lokale Backend.

gcloud compute backend-services create on-premise-service-backend \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --protocol=TCP \
   --region=us-central1 \
   --health-checks=on-prem-service-hc \
   --health-checks-region=us-central1

Fügen Sie dem Backend-Dienst in Cloud Shell das hybride NEG-Backend hinzu. Geben Sie für MAX_CONNECTIONS die maximale Anzahl gleichzeitiger Verbindungen ein, die das Backend verarbeiten soll.

gcloud compute backend-services add-backend on-premise-service-backend \
   --network-endpoint-group=on-prem-service-neg \
   --network-endpoint-group-zone=us-central1-a \
   --region=us-central1 \
   --balancing-mode=CONNECTION \
   --max-connections=100

Zielproxy in Cloud Shell erstellen

gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
   --backend-service=on-premise-service-backend \
   --region=us-central1

Weiterleitungsregel (ILB) in Cloud Shell erstellen

Erstellen Sie die Weiterleitungsregel mit dem Befehl gcloud compute forwarding-rules create.

Ersetzen Sie FWD_RULE_PORT durch eine einzelne Portnummer zwischen 1 und 65535. Die Weiterleitungsregel leitet nur Pakete mit einem übereinstimmenden Zielport weiter.

gcloud compute forwarding-rules create tcp-ilb-psc \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --network=producer-vpc \
   --subnet=subnet-201 \
   --ports=80 \
   --region=us-central1 \
   --target-tcp-proxy=on-premise-svc-tcpproxy \
   --target-tcp-proxy-region=us-central1

IP-Adresse des internen Load-Balancers abrufen

gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:

Example output:
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
IPAddress: 10.10.1.2

4. Load Balancer überprüfen

Rufen Sie in der Cloud Console Netzwerkdienste → Load Balancing → Load Balancer auf. Hinweis: Das NEG 1 ist grün, was auf eine erfolgreiche Systemdiagnose für den lokalen Dienst hinweist.

Wenn Sie ‘on-premise-service-backend' auswählen, wird die Front-End-IP-Adresse angezeigt.

5. Erkannte Routen aus dem lokalen Netzwerk ansehen

Rufen Sie VPC-Netzwerk → Routen auf. Das gelernte lokale Dienstsubnetz 192.168.1.0/27

6. Verbindung zum lokalen Dienst prüfen

Wir erstellen eine VM in der VPC des Diensterstellers, um die Verbindung zum lokalen Dienst zu testen. Danach wird die Dienstanhängekonfiguration vorgenommen.

Erstellen Sie in Cloud Shell die Testinstanz in der Producer-VPC.

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

Damit IAP eine Verbindung zu Ihren VM-Instanzen herstellen kann, erstellen Sie eine Firewallregel, die:

Gilt für alle VM-Instanzen, die über IAP zugänglich sein sollen.
Lässt eingehenden Traffic aus dem IP-Bereich 35.235.240.0/20 zu. Dieser Bereich enthält alle IP-Adressen, die IAP für die TCP-Weiterleitung verwendet.

Erstellen Sie in Cloud Shell die Testinstanz in der Producer-VPC.

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Melden Sie sich in Cloud Shell mit IAP bei test-box-us-central1 an, um die Verbindung zum lokalen Dienst zu prüfen. Führen Sie dazu einen curl-Befehl für die Load-Balancer-IP-Adresse aus. Bei einer Zeitüberschreitung versuchen Sie es noch einmal.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

Führen Sie einen curl-Befehl aus, um die Verbindung zum lokalen Dienst zu prüfen. Beenden Sie die VM, nachdem Sie die Validierung abgeschlossen haben, und kehren Sie zur Cloud Shell-Eingabeaufforderung zurück. Ersetzen Sie die IP-Adresse des internen Load-Balancers durch die Ausgabe, die Sie in den Schritten 3 und 4 ermittelt haben.

deepakmichael@test-box-us-central1:~$ curl -v 10.10.1.2
* Expire in 0 ms for 6 (transfer 0x55b9a6b2f0f0)
*   Trying 10.10.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a6b2f0f0)
* Connected to 10.10.1.2 (10.10.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:42:38 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:42:38 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

7. Private Service Connect-Dienstanhang erstellen

In den folgenden Schritten erstellen wir den Dienstanhang. Nach der Verknüpfung mit einem Consumer-Endpunkt ist der Zugriff auf den lokalen Dienst ohne VPC-Peering möglich.

Dienstanhang erstellen

Erstellen Sie in Cloud Shell die Service Attachment.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

Optional: Wenn Sie eine freigegebene VPC verwenden, erstellen Sie den Dienstanhang im Dienstprojekt.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

TCP-Dienstanhang validieren

gcloud compute service-attachments describe service-1 --region us-central1

8. Optional: Rufen Sie „Network Services“ → „Private Service Connect“ auf, um den neu eingerichteten Dienstanhang aufzurufen.

Wenn Sie Service-1 auswählen, werden weitere Details angezeigt, einschließlich des URI des Dienstanhangs, der vom Nutzer zum Herstellen einer Private Service Connect-Verbindung verwendet wird. Notieren Sie sich den URI, da er in einem späteren Schritt verwendet wird.

Details zum Service Attachment:projects/<projectname>/regions/us-central1/serviceAttachments/service-1

9. Einrichtung durch Nutzer

Consumer-VPC erstellen

Führen Sie in Cloud Shell die folgenden Schritte aus:

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

Nutzer-Subnetze erstellen

Erstellen Sie das GCE-Subnetz in Cloud Shell.

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

Erstellen Sie in Cloud Shell das Nutzerendpunkt-Subnetz.

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

Nutzerendpunkt (Weiterleitungsregel) erstellen

Erstellen Sie in Cloud Shell die statische IP-Adresse, die als Nutzerendpunkt verwendet wird.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

Erstellen Sie den Nutzerendpunkt mit dem zuvor generierten URI des Dienstanhangs.

Nutzerendpunkt in Cloud Shell erstellen

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

10. Private Service Connect für Nutzer validieren – Nutzer-VPC

Prüfen Sie im VPC-Netzwerk des Nutzers, ob die Private Service Connect-Verbindung erfolgreich hergestellt wurde. Rufen Sie dazu Network Services → Private Service Connect → Connected Endpoints auf. Notieren Sie sich die hergestellte Verbindung „psc-consumer-1“ und die entsprechende IP-Adresse, die wir zuvor erstellt haben.

Wenn Sie „psc-consumer-1“ auswählen, werden zusätzliche Details angezeigt, einschließlich des URI des Dienstanhangs.

11. Private Service Connect-Nutzer – Ersteller-VPC validieren

Prüfen Sie im VPC des Diensterstellers, ob die private Dienstverbindung erfolgreich hergestellt wurde. Rufen Sie dazu Network Services → Private Service Connect → Published Service auf. Die Verbindung für den veröffentlichten Dienst 1 verweist jetzt auf eine Weiterleitungsregel (Verbindungs-Endpunkt).

12. Private DNS-Zone und A-Eintrag erstellen

Erstellen Sie die private DNS-Zone, die dem PSC-Verbindungs-Endpunkt zugeordnet ist, um nahtlosen Zugriff auf den Producer von jedem Host innerhalb der VPC zu ermöglichen.

Über Cloud Shell

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

13. Nutzerzugriff auf den Dienst des Erstellers über eine VM validieren

Im VPC-Netzwerk des Nutzers erstellen wir eine VM, um die Verbindung zum lokalen Dienst zu testen, indem wir auf den Nutzerendpunkt service1.codelabs.net zugreifen.

Erstellen Sie in Cloud Shell die Testinstanz in der Consumer-VPC.

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

Damit IAP eine Verbindung zu Ihren VM-Instanzen herstellen kann, erstellen Sie eine Firewallregel, die:

Gilt für alle VM-Instanzen, die über IAP zugänglich sein sollen.
Lässt eingehenden Traffic aus dem IP-Bereich 35.235.240.0/20 zu. Dieser Bereich enthält alle IP-Adressen, die IAP für die TCP-Weiterleitung verwendet.

Erstellen Sie in Cloud Shell die Testinstanz in der Consumer-VPC.

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Melden Sie sich mit IAP in Cloud Shell in der consumer-vm an, um die Verbindung zum lokalen Dienst zu prüfen, indem Sie einen curl-Befehl für den DNS-FQDN service1.codelab.net ausführen. Wiederholen Sie den Vorgang, wenn es zu einem Zeitüberschreitungsfehler kommt.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

Führen Sie in Cloud Shell einen curl-Befehl aus.

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

Unten sehen Sie ein Beispiel für eine Erfassung vom lokalen Dienst. Beachten Sie, dass die Quell-IP-Adresse 172.16.0.2 aus dem TCP-Proxy-Subnetzbereich 172.16.0.0/23 stammt.

14. Bereinigung durch Produzenten

Produzentenkomponenten löschen

Löschen Sie in Cloud Shell die Producer-Komponenten.

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete tcp-ilb-psc --region=us-central1 --quiet

gcloud compute target-tcp-proxies delete on-premise-svc-tcpproxy --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete on-prem-service-hc --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

15. Bereinigung durch Nutzer

Consumer-Komponenten löschen

Löschen Sie in Cloud Shell die Nutzerkomponenten.

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet

16. Glückwunsch

Herzlichen Glückwunsch! Sie haben Private Service Connect mit TCP-Proxy erfolgreich konfiguriert und validiert.

Sie haben die Erstellerinfrastruktur erstellt und einen Dienstanhang in der Ersteller-VPC hinzugefügt, der auf einen lokalen Dienst verweist. Sie haben gelernt, wie Sie einen Nutzerendpunkt in der Nutzer-VPC erstellen, der die Verbindung zum lokalen Dienst ermöglicht.

Nächste Schritte

Hier finden Sie einige Codelabs:

Mit Private Service Connect und Hybrid-NEG-TCP-Proxy über Hybridnetzwerke eine Verbindung zu lokalen Diensten herstellen

1. Einführung

Umfang

Lerninhalte

Voraussetzungen

Hybridkonnektivität einrichten

Benutzerdefiniertes Routen-Advertising

2. Hinweis

Projekt für das Codelab aktualisieren

3. Einrichtung für Ersteller

Ersteller-VPC erstellen

Producer-Subnetze erstellen

TCP-Proxy-Subnetze erstellen

Private Service Connect-NAT-Subnetze erstellen

Firewallregeln für den Producer erstellen

Hybridkonnektivitäts-NEG einrichten

Load-Balancer konfigurieren

4. Load Balancer überprüfen

5. Erkannte Routen aus dem lokalen Netzwerk ansehen

6. Verbindung zum lokalen Dienst prüfen

7. Private Service Connect-Dienstanhang erstellen

Dienstanhang erstellen

8. Optional: Rufen Sie „Network Services“ → „Private Service Connect“ auf, um den neu eingerichteten Dienstanhang aufzurufen.

9. Einrichtung durch Nutzer

Consumer-VPC erstellen

Nutzer-Subnetze erstellen

Nutzerendpunkt (Weiterleitungsregel) erstellen

10. Private Service Connect für Nutzer validieren – Nutzer-VPC

11. Private Service Connect-Nutzer – Ersteller-VPC validieren

12. Private DNS-Zone und A-Eintrag erstellen

13. Nutzerzugriff auf den Dienst des Erstellers über eine VM validieren

Unten sehen Sie ein Beispiel für eine Erfassung vom lokalen Dienst. Beachten Sie, dass die Quell-IP-Adresse 172.16.0.2 aus dem TCP-Proxy-Subnetzbereich 172.16.0.0/23 stammt.

14. Bereinigung durch Produzenten

Produzentenkomponenten löschen

15. Bereinigung durch Nutzer

Consumer-Komponenten löschen

16. Glückwunsch

Nächste Schritte

Weitere Informationen und Videos

Referenzdokumente