Private Service Connect für Google APIs

1. Einführung

Mit Private Service Connect können Sie private Endpunkte mit globalen internen IP-Adressen in Ihrem VPC-Netzwerk erstellen, um auf Google APIs zuzugreifen. Sie können diesen internen IP-Adressen DNS-Namen mit aussagekräftigen Namen wie storage-pscendpoint.p.googleapis.com und bigtable-adsteam.p.googleapis.com zuweisen. Anstatt API-Anfragen an Endpunkte für öffentliche Dienste wie storage.googleapis.com zu senden, können Sie die Anfragen an den Private Service Connect-Endpunkt senden, der privat und intern in Ihrem VPC-Netzwerk ist.

Diese Namen und IP-Adressen sind intern in Ihrem VPC-Netzwerk und allen lokalen Netzwerken vergeben, die über Cloud VPN-Tunnel oder Cloud Interconnect-Anhänge (VLANs) mit ihm verbunden sind.

Sie können steuern, welcher Traffic an welchen Endpunkt geleitet wird, und ob der Traffic innerhalb der Google Cloud bleiben soll.

Lerninhalte

  • Anwendungsfälle für Private Service Connect
  • Netzwerkanforderungen
  • Unterstützte APIs
  • Private Service Connect-Endpunkt erstellen
  • Cloud Storage-Bucket erstellen
  • Private Cloud DNS-Zonen erstellen und aktualisieren
  • NAT-Gateway für den Zugriff auf öffentliche Google APIs erstellen
  • BOTO-Konfigurationsdatei erstellen und aktualisieren
  • „gsutil list“ auf VM1 ausführen, die auf Ihren PSC-Dienstendpunkt aufgelöst wird
  • Führen Sie „gsutil list“ auf VM2 aus, das in der öffentlichen googleapis.com-Domain aufgelöst wird.
  • DNS-Auflösung mit „Tcpdump“ validieren

Voraussetzungen

  • Kenntnisse von DNS, Nano oder Vi-Editor

2. Anwendungsfälle für Private Service Connect

Sie können mehrere Private Service Connect-Endpunkte im selben VPC-Netzwerk erstellen. Die Bandbreite für einen bestimmten Endpunkt ist nicht begrenzt. Da Private Service Connect-Endpunkte globale interne IP-Adressen verwenden, können sie von jeder Ressource in Ihrem VPC-Netzwerk verwendet werden.

Mit mehreren Endpunkten können Sie verschiedene Netzwerkpfade mithilfe von Cloud Router und Firewallregeln festlegen.

  • Sie können Firewallregeln erstellen, um zu verhindern, dass einige VMs über einen Private Service Connect-Endpunkt auf Google APIs zugreifen und anderen VMs Zugriff gewähren.
  • Sie können eine Firewallregel für eine VM-Instanz festlegen, die den gesamten Traffic im Internet untersagt. An Private Service Connect-Endpunkte gesendeter Traffic erreicht weiterhin Google.
  • Wenn lokale Hosts, die über einen Cloud VPN-Tunnel oder einen Cloud Interconnect-Anhang (VLAN) an eine VPC angeschlossen sind, können Sie einige Anfragen über den Tunnel oder VLAN senden, während Sie weitere Anfragen über das öffentliche Internet senden. Mit dieser Konfiguration können Sie den Tunnel oder VLAN für Dienste wie Google Books umgehen, die nicht vom privaten Google-Zugriff unterstützt werden. Für diese Konfiguration erstellen Sie einen Private Service Connect-Endpunkt, bewerben Sie die IP-Adressen des Private Service Connect-Endpunkts mithilfe von benutzerdefinierten Cloud Router Route Advertisements und aktivieren Sie eine Richtlinie für die eingehende Cloud DNS-Weiterleitung. Die Anwendung kann einige Anfragen über den Cloud VPN-Tunnel oder den Cloud Interconnect-Anhang (VLAN) senden. Dazu wird der Name des Private Service Connect-Endpunkts verwendet. Beim Senden weiterer Anfragen über das Internet wird der DNS-Name verwendet.
  • Wenn Sie Ihr lokales Netzwerk über mehrere Cloud Interconnect-Anhänge (VLANs) mit Ihrem VPC-Netzwerk verbinden, können Sie einigen Traffic von lokalen Speicherorten über ein VLAN und den Rest über andere senden, wie in Abbildung 2 gezeigt. Auf diese Weise können Sie Ihr eigenes Wide Area Netzwerk anstelle des Netzwerks von Google verwenden und so die Datenverschiebung im Hinblick auf die geografischen Anforderungen steuern. Für diese Konfiguration erstellen Sie zwei Private Service Connect-Endpunkte. Erstellen Sie ein benutzerdefiniertes Route Advertisement für den ersten Endpunkt in der BGP-Sitzung des Cloud Routers, der das erste VLAN verwaltet. Erstellen Sie dann ein anderes benutzerdefiniertes Route Advertisement für den zweiten Endpunkt in der BGP-Sitzung von Cloud Router, der das zweite VLAN verwaltet. Lokale Hosts, die für die Verwendung des Namens des Private Service Connect-Endpunkts konfiguriert sind, senden Traffic über den entsprechenden Cloud Interconnect-Anhang (VLAN).
  • Sie können auch mehrere Cloud Interconnect-Anhänge (VLANs) in einer Aktiv/Aktiv-Topologie verwenden. Wenn Sie für die BGP-Sitzungen auf den Cloud Routern, die die VLANs verwalten, dieselbe IP-Adresse des Private Service Connect-Endpunkts über benutzerdefinierte Route Advertisements bewerben, werden Pakete, die von lokalen Systemen an die Endpunkte gesendet werden, über die VLANs mit ECMP weitergeleitet.

5e142c2fbf6f010e.png

Abbildung 1. Durch die Konfiguration von Private Service Connect, Cloud Router und lokalen Hosts können Sie steuern, welcher Cloud Interconnect-Anhang (VLAN) zum Senden von Traffic an Google APIs verwendet wird.

3. Netzwerkanforderungen

Für die Verwendung von Private Service Connect müssen virtuelle Maschineninstanzen (VM) ohne externe IP-Adressen ihre eigene primäre Schnittstelle in einem Subnetz mit aktiviertem privaten Google-Zugriff haben.

Eine VM mit einer externen IP-Adresse kann über Private Service Connect-Endpunkte auf Google APIs und Google-Dienste zugreifen, unabhängig davon, ob der private Google-Zugriff für ihr Subnetz aktiviert ist. Die Verbindung zum Private Service Connect-Endpunkt verbleibt im Google-Netzwerk.

Private Service Connect-Endpunkte sind über Peering-VPC-Netzwerke nicht erreichbar.

Unterstützte APIs

Beim Erstellen eines Private Service Connect-Endpunkts wählen Sie aus, auf welche APIs Sie Zugriff haben: „all-apis“ oder „vpc-sc“.

Die API-Bundles bieten Zugriff auf dieselben APIs, die über die VIPs für den privaten Google-Zugriff verfügbar sind.

  • Das Bundle „all-apis“ bietet Zugriff auf dieselben APIs wie „private.googleapis.com“.
  • Das vpc-sc-Bundle bietet Zugriff auf dieselben APIs wie restricted.googleapis.com.

4. Codelab-Topologie und ‑Anwendungsfall

2ac275eb86f26338.png

Abbildung 1: Codelab-Topologie

Codelab-Anwendungsfall –

Unser Kunde benötigt für die Übertragung von Cloud Storage-Daten eine Mischung aus privatem (Interconnect) und öffentlichem Google APIs-Zugriff. Um die Anforderungen unserer Kunden zu erfüllen, stellen wir Private Service Connect mit einer eindeutigen /32-Adresse, BOTO-Konfiguration und DNS-Eintragsaktualisierungen bereit. VM1 verwendet PSC für den Zugriff auf Cloud Storage-Buckets, während VM2 öffentliche googleapis.com-IP-Bereiche über das NAT-Gateway verwendet.

Alle Aspekte des Labs werden in der Google Cloud Platform bereitgestellt. Derselbe Anwendungsfall gilt jedoch auch für die Hybrid Cloud-Bereitstellung, bei der eine Trennung des Traffics erforderlich ist.

5. Einrichtung und Anforderungen

Umgebung zum selbstbestimmten Lernen einrichten

  1. Melden Sie sich in der Cloud Console an und erstellen Sie ein neues Projekt oder verwenden Sie ein vorhandenes Projekt. Wenn Sie noch kein Gmail- oder Google Workspace-Konto haben, müssen Sie eines erstellen.

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

Notieren Sie sich die Projekt-ID, also den projektübergreifend nur einmal vorkommenden Namen eines Google Cloud-Projekts. Der oben angegebene Name ist bereits vergeben und kann leider nicht mehr verwendet werden. Sie wird später in diesem Codelab als PROJECT_ID bezeichnet.

  1. Als Nächstes müssen Sie die Abrechnung in der Cloud Console aktivieren, um Google Cloud-Ressourcen verwenden zu können.

Die Durchführung dieses Codelabs sollte keine oder nur geringe Kosten verursachen. Folgen Sie bitte der Anleitung im Abschnitt „Bereinigen“, in der Sie erfahren, wie Sie Ressourcen herunterfahren können, damit nach Abschluss dieser Anleitung keine Gebühren anfallen. Neue Nutzer von Google Cloud kommen für das Programm für kostenlose Testversionen mit einem Guthaben von 300$ infrage.

Cloud Shell starten

Während Sie Google Cloud von Ihrem Laptop aus per Fernzugriff nutzen können, wird in diesem Codelab Google Cloud Shell verwendet, eine Befehlszeilenumgebung, die in der Cloud ausgeführt wird.

Klicken Sie in der GCP Console oben rechts in der Symbolleiste auf das Cloud Shell-Symbol:

bce75f34b2c53987.png

Die Bereitstellung und Verbindung mit der Umgebung sollte nur wenige Augenblicke dauern. Anschließend sehen Sie in etwa Folgendes:

f6ef2b5f13479f3a.png

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft in Google Cloud, was die Netzwerkleistung und Authentifizierung erheblich verbessert. Für dieses Lab benötigen Sie lediglich einen Browser.

6. Hinweis

APIs aktivieren

Prüfen Sie in Cloud Shell, ob Ihre Projekt-ID eingerichtet ist.

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

Alle erforderlichen Dienste aktivieren

gcloud services enable compute.googleapis.com
gcloud services enable servicedirectory.googleapis.com
gcloud services enable dns.googleapis.com

7. VPC-Netzwerk erstellen

VPC-Netzwerk

Über Cloud Shell

gcloud compute networks create psc-lab --subnet-mode custom

Subnetz erstellen

Über Cloud Shell

gcloud compute networks subnets create psclab-subnet \
--network psc-lab --range 10.0.0.0/24 --region us-central1 --enable-private-ip-google-access

Firewallregeln erstellen

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.

Über Cloud Shell

gcloud compute firewall-rules create psclab-ssh \
    --network psc-lab --allow tcp:22 --source-ranges=35.235.240.0/20

Cloud NAT-Instanz erstellen

Cloud Router erstellen

Über Cloud Shell

gcloud compute routers create crnat \
    --network psc-lab \
    --asn 65000 \
    --region us-central1

Cloud NAT erstellen

Über Cloud Shell

gcloud compute routers nats create cloudnat \
    --router=crnat \
    --auto-allocate-nat-external-ips \
    --nat-all-subnet-ip-ranges \
    --enable-logging \
    --region us-central1

8. Private Service Connect-Endpunkt erstellen

Wenn Sie die IP-Adresse des Private Service Connect-Endpunkts <pscendpointip> konfigurieren, müssen Sie eine eindeutige IP-Adresse angeben, die nicht in Ihrer VPC definiert ist.

Über Cloud Shell

gcloud compute addresses create psc-ip \
    --global \
    --purpose=PRIVATE_SERVICE_CONNECT \
    --addresses=192.168.255.250 \
    --network=psc-lab

„pscendpointip“ für die Dauer des Labs speichern

pscendpointip=$(gcloud compute addresses list --filter=name:psc-ip --format="value(address)")

echo $pscendpointip

Erstellen Sie eine Weiterleitungsregel, um den Endpunkt mit Google APIs und Google-Diensten zu verbinden.

Über Cloud Shell

gcloud compute forwarding-rules create pscendpoint \
    --global \
    --network=psc-lab \
    --address=psc-ip \
    --target-google-apis-bundle=all-apis

Konfigurierte Private Service Connect-Endpunkte auflisten

Über Cloud Shell

gcloud compute forwarding-rules list  \
--filter target="(all-apis OR vpc-sc)" --global

Konfigurierte Private Service Connect-Endpunkte beschreiben

Über Cloud Shell

gcloud compute forwarding-rules describe \
    pscendpoint --global

9. Bucket erstellen

Erstellen Sie einen Cloud Storage-Bucket und ersetzen Sie BUCKET_NAME durch einen global eindeutigen Namen Ihrer Wahl.

Über Cloud Shell

gsutil mb  -l us-central1 -b on gs://BUCKET_NAME

Speichern Sie „BUCKET_NAME“ für die Dauer des Labs.

BUCKET_NAME=YOUR BUCKET NAME
echo $BUCKET_NAME

10. DNS-Konfiguration

Wenn Sie einen Private Service Connect-Endpunkt erstellen, generiert Service Directory einen DNS-Eintrag für die APIs und Dienste, die mit diesem Endpunkt verfügbar gemacht werden.

Die DNS-Einträge verweisen auf die IP-Adresse Ihres Private Service Connect-Endpunkts und haben das folgende Format: SERVICE-ENDPOINT.p.googleapis.com.

Sie können diese DNS-Namen in Ihren API-Anfragen verwenden, um die Anfrage an Ihren Private Service Connect-Endpunkt weiterzuleiten. Sie können diese DNS-Namen auch im Host-Header Ihrer Anfrage verwenden.

Wenn Sie einen Private Service Connect-Endpunkt mit einem Client oder einer Anwendung verwenden möchten, die auf Google APIs und Dienste zugreift, aktualisieren Sie Ihren Client oder Ihre Anwendung für die Verwendung der DNS-Namen von p.googleapis.com.

Weitere Informationen finden Sie in der Dokumentation zu Ihrem Client oder Ihrer Clientbibliothek. Beispiel:

  • Python: Sie können api_endpoint in der Klasse „Clientoptionen“ im Paket „google-api-core“ konfigurieren.
  • Go: Sie können „WithEndpoint“ im Client-Optionspaket im API-Paket konfigurieren.
  • gcloud: You can configure api_endpoint_overrides using this command. gcloud config set api_endpoint_overrides/SERVICE ENDPOINT_URL

Beispiel: gcloud config set api_endpoint_overrides/storage https://storage-xyz.p.googleapis.com/storage/v1/

Wenn Sie Ihren Client oder Ihre Anwendung nicht für die Verwendung eines anderen Endpunkts konfigurieren können, erstellen Sie DNS-Einträge, die den Standard-DNS-Namen entsprechen. Ein Beispiel ist storage.googleapis.com. Weitere Informationen finden Sie unter DNS-Einträge mit Standard-DNS-Namen erstellen.

DNS-Eintrag validieren

Prüfen Sie in der Cloud Console den generierten DNS-Eintrag unter „Netzwerkdienste“ → „Cloud DNS“. Notieren Sie sich den generierten DNS-Namen „p.googleapis.com“.

11. Virtuelle Maschinen erstellen

Erstellen Sie die VM (psc-instance-1), die zum Validieren von Private Service Connect verwendet wird.

Über Cloud Shell

  gcloud compute instances create psc-instance-1 \
    --subnet psclab-subnet \
    --zone us-central1-a \
    --image=centos-7-v20210122 \
    --image-project=centos-cloud \
    --no-address \
    --metadata=startup-script=yum\ install\ tcpdump\ -y$'\n'yum\ install\ bind-utils\ -y$'\n'yum\ install\ nano\ -y 

Bei der VM-Instanz (psc-instance-1) anmelden

SSH-Verbindung zur VM über Cloud Shell herstellen

gcloud compute ssh --zone "us-central1-a" "psc-instance-1" --project "$projectname"

Erstellen Sie zusätzliche Cloud Shell-Terminals, indem Sie dreimal auf das Pluszeichen + (siehe Screenshot unten) klicken.

69ea94e1527912bb.png

Virtuelle Maschine (psc-instance-2) erstellen, die zum Validieren öffentlicher Google-APIs verwendet wird

Über Tab 2

  gcloud compute instances create psc-instance-2 \
    --subnet psclab-subnet \
    --zone us-central1-a \
    --image=centos-7-v20210122 \
    --image-project=centos-cloud \
    --no-address \
    --metadata=startup-script=yum\ install\ tcpdump\ -y$'\n'yum\ install\ bind-utils\ -y$'\n'yum\ install\ nano\ -y 

Über Tab 2 eine SSH-Verbindung zur VM über Cloud Shell herstellen

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


gcloud compute ssh --zone "us-central1-a" "psc-instance-2" --project "$projectname"

Stellen Sie auf Tab 3 über Cloud Shell eine SSH-Verbindung zu „psc-instance-1“ her.

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


gcloud compute ssh --zone "us-central1-a" "psc-instance-1" --project "$projectname"

Stellen Sie über Cloud Shell eine SSH-Verbindung zu „psc-instance-2“ her.

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


gcloud compute ssh --zone "us-central1-a" "psc-instance-2" --project "$projectname"

12. Vorhandenes Gsutil-Verhalten überprüfen

Starten Sie auf Tab 4 (psc-instance-2) tcpdump und überwachen Sie den DNS-Traffic.

sudo tcpdump -vv -i eth0 port 53

DNS-Lookup für den Storage-Bucket auf Tab 2 (psc-instance-2) prüfen

BUCKET_NAME=YOUR BUCKET NAME
echo $BUCKET_NAME
gsutil -D ls gs://$BUCKET_NAME

gsutil-Debug-Ausgabe prüfen: HOST storage.googleapis.com wird für die DNS-Auflösung verwendet

<snip>
send: 'GET /storage/v1/b/$BUCKET_NAME/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000 HTTP/1.1\r\nHost: storage.googleapis.com\r\ncontent-length: 0\r\nauthorization: Bearer ya29.c.KpkB7wfaMjfc_WXEKCeNF4Md0fEHnfDU7tqBf3cd0u43yEmYXqj8fX_X5wWdNdDVH6k1EkjeAeIJDzKGvyjPOkf1Io2kVeUqYX69sDv53huW1NslffjAHKchbZ0CP3Cg83TS3Pa55jLcuE0TLbYycVrgSbD3H90LaapUGbWD3kj4IsJLf9J8R98Bqobu8HZwwqk92hlZ4zVzRqOM\r\naccept-encoding: gzip, deflate\r\naccept: application/json\r\nuser-agent: apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
<snip>

Prüfen Sie auf Tab 4 (psc-instance-2), ob beim Zugriff auf den Speicher-Bucket die öffentlichen DNS-A-Einträge von GoogleAPI.com verwendet werden.

metadata.google.internal.domain > psc-instance-2.c.yourprojectname.internal.33973: [udp sum ok] 36442 q: A? storage.googleapis.com. 11/0/0 storage.googleapis.com. A 108.177.111.128, storage.googleapis.com. A 142.250.128.128, storage.googleapis.com. A 74.125.70.128, storage.googleapis.com. A 74.125.201.128, storage.googleapis.com. A 64.233.183.128, storage.googleapis.com. A 173.194.198.128, storage.googleapis.com. A 172.217.219.128, storage.googleapis.com. A 142.250.136.128, storage.googleapis.com. A 209.85.234.128, storage.googleapis.com. A 172.217.212.128, storage.googleapis.com. A 172.217.214.128

13. Gsutil-Verhalten ändern

Im vorherigen Schritt haben Sie eine private DNS-Zone und einen A-Eintrag erstellt, der der IP-Adresse des PSC-Endpunkts zugeordnet ist. Im nächsten Schritt steuern wir das Verhalten von gsutil, indem wir die BOTO-Datei der VM „psc-instance-1“ aktualisieren.

Standard-BOTO-Konfiguration im VM-Instanzterminal auf Tab 1 (psc-instance-1) ansehen

[psc-instance ~]$ more  /etc/boto.cfg

Ausgabe (Ihre project_id wird sich unterscheiden)

[GSUtil]
default_project_id  = [your project number]
default_api_version = 2

[GoogleCompute]
service_account = default

Aktualisieren Sie die BOTO-Konfiguration mit Nano oder VI Editor. Achten Sie darauf, alle Einträge zu kopieren und einzufügen.

Beispiel: sudo nano /etc/boto.cfg

oder

Beispiel: sudo vi /etc/boto.cfg

Auf dem Terminaltab 1 der VM-Instanz(psc-instance-1)

[Credentials]
gs_host = storage-pscendpoint.p.googleapis.com
gs_host_header = storage.googleapis.com
gs_json_host = storage-pscendpoint.p.googleapis.com
gs_json_host_header = www.googleapis.com

Konfiguration validieren, Reihenfolge von [Credentials] ist für die DNS-Suche entscheidend

more /etc/boto.cfg
[Credentials]
gs_host = storage-pscendpoint.p.googleapis.com
gs_host_header = storage.googleapis.com
gs_json_host = storage-pscendpoint.p.googleapis.com
gs_json_host_header = www.googleapis.com

[GSUtil]
default_project_id  = [your project number
default_api_version = 2

[GoogleCompute]
service_account = default

14. Aktualisiertes gsutil-Suchverhalten prüfen

Starten Sie auf Tab 3 (psc-instance-1) tcpdump und überwachen Sie den DNS-Traffic.

sudo tcpdump -vv -i eth0 port 53

Storage-Bucket-gsutil-Lookup über Tab 1 (psc-instance-1) prüfen

BUCKET_NAME=YOUR BUCKET NAME
echo $BUCKET_NAME

gsutil -D ls gs://$BUCKET_NAME

Debug-Logs bestätigen, dass der Speicher-Bucket über den Private Service Connect-Endpunkt „pscendpoint“ erreichbar ist.

Ausgabe:

<snip>
INFO 0131 22:14:18.795986 base_api.py] Making http GET to https://storage-pscendpoint.p.googleapis.com/storage/v1/b/$BUCKET_NAME/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000
INFO 0131 22:14:18.796415 base_api.py] Headers: {u'Host': 'www.googleapis.com',
 'accept': 'application/json',
 'accept-encoding': 'gzip, deflate',
 'content-length': '0',
 'user-agent': 'apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0'}
INFO 0131 22:14:18.796502 base_api.py] Body: (none)
connect: (storage-pscendpoint.p.googleapis.com, 443)
send: 'GET /storage/v1/b/psc-bucket/o?delimiter=%2F&projection=noAcl&versions=False&fields=prefixes%2CnextPageToken%2Citems%2Fname&alt=json&maxResults=1000 HTTP/1.1\r\ncontent-length: 0\r\naccept-encoding: gzip, deflate\r\naccept: application/json\r\nuser-agent: apitools Python/2.7.5 gsutil/4.57 (linux2) analytics/disabled interactive/True command/ls google-cloud-sdk/324.0.0\r\nhost: www.googleapis.com\r\nauthorization: Bearer ya29.c.KpkB7wd3XWiYeRyTuth5_HPlNV-hPwc2Nn7RSIeMpzrpa_j4EsMPl2m_mDGKAcGHvYIgiC5bT2UVQirAPpSbbpToa6G6lkaBbH5SZwHwgNXYfisp5Ww1UjXe4rTa69a_Wp0WesafcwPNnYzDo3xf5VGh3iGhySA04kTXuyT--MgOU8U-XLII2LJQxUWlV8KEdrvyCuqRb-jsDdk_\r\n\r\n'
reply: 'HTTP/1.1 200 OK\r\n'
<snip>

Prüfen Sie auf Tab 3 (psc-instance-1), ob die IP-Adresse Ihres PSC-Endpunkts der DNS-A-Eintrag ist, der beim Zugriff auf Ihren Speicher-Bucket verwendet wird.

@psc-instance-1 ~]$ sudo tcpdump -vv -i eth0 port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
05:02:33.936256 IP (tos 0x0, ttl 64, id 55416, offset 0, flags [DF], proto UDP (17), length 82)
    psc-instance-1.c.yourprojectname.internal.42296 > metadata.google.internal.domain: [bad udp cksum 0x5e4e -> 0xcceb!] 34796+ A? storage-pscendpoint.p.googleapis.com. (54)
05:02:33.936269 IP (tos 0x0, ttl 64, id 55417, offset 0, flags [DF], proto UDP (17), length 82)
    psc-instance-1.c.yourprojectname.internal.42296 > metadata.google.internal.domain: [bad udp cksum 0x5e4e -> 0x3ebd!] 5632+ AAAA? storage-pscendpoint.p.googleapis.com. (54)
05:02:33.944018 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 98)
    metadata.google.internal.domain > psc-instance-1.c.yourprojectname.42296: [udp sum ok] 34796 q: A? storage-pscendpoint.p.googleapis.com. 1/0/0 storage-pscendpoint.p.googleapis.com. A 10.10.110.10 (70)
05:02:33.946005 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 175)

Prüfen, ob die IP-Adresse des Private Service Connect-Endpunkts jetzt für die DNS-Auflösung verwendet wird

Von Tab1

nslookup storage-pscendpoint.p.googleapis.com

Ausgabe

@psc-instance ~]$ nslookup storage-pscendpoint.p.googleapis.com
Server:         169.254.169.254
Address:        169.254.169.254#53

Non-authoritative answer:
Name:   storage-pscendpoint.p.googleapis.com
Address: <pscip>

15. Bereinigungsschritte

VM-Instanz beenden (alle Tabs)

exit

Lab-Komponenten über ein einzelnes Cloud Shell-Terminal löschen

gcloud compute routers nats delete cloudnat --router=crnat --region=us-central1 --quiet

gcloud compute routers delete crnat --region=us-central1 --quiet

gcloud compute forwarding-rules delete pscendpoint --global --quiet

gcloud compute addresses delete psc-ip --global --quiet

gsutil rm -r gs://$BUCKET_NAME

gcloud compute instances delete psc-instance-1 --zone=us-central1-a --quiet

gcloud compute instances delete psc-instance-2 --zone=us-central1-a --quiet

gcloud compute firewall-rules delete psclab-ssh --quiet

gcloud compute networks subnets delete psclab-subnet --region us-central1 --quiet

gcloud compute networks delete psc-lab --quiet

Prüfen Sie in der Console, ob Sie das richtige Projekt sehen, und wählen Sie dann „Netzwerkdienste“ → „Cloud DNS“ aus.

16. Glückwunsch!

Herzlichen Glückwunsch zum Abschluss des Codelabs.

Behandelte Themen

  • Anwendungsfälle für Private Service Connect
  • Netzwerkanforderungen
  • Unterstützte APIs
  • Sie haben einen Private Service Connect-Endpunkt erstellt.
  • Cloud Storage-Bucket erstellt
  • BOTO-Konfigurationsdatei aktualisiert
  • NAT-GW erstellt
  • Führen Sie „gsutil list“ auf VM1 aus, das auf Ihren PSC-Dienstendpunkt verweist.
  • Führen Sie „gsutil list“ auf VM2 aus, das in der öffentlichen googleapis.com-Domain aufgelöst wird.
  • DNS-Auflösung mit „Tcpdump“ validieren