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 „BTAG-adsteam.p.googleapis.com“ zuweisen. Anstatt API-Anfragen an öffentliche Dienstendpunkte 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 gelten intern für Ihr VPC-Netzwerk und alle lokalen Netzwerke, die über Cloud VPN-Tunnel oder Cloud Interconnect-Anhänge (VLANs) verbunden sind.

Sie können steuern, welcher Traffic zu welchem Endpunkt geleitet wird, und zeigen, dass der Traffic innerhalb von Google Cloud verbleibt.

Aufgaben in diesem Lab

  • Private Service Connect-Anwendungsfälle
  • Netzwerkanforderungen
  • Unterstützte APIs
  • Private Service Connect-Endpunkt erstellen
  • Cloud Storage-Bucket erstellen
  • Private Cloud DNS-Zonen erstellen und aktualisieren
  • NAT-GW für den Zugriff auf öffentliche googleapis erstellen
  • BOTO-Konfigurationsdatei erstellen und aktualisieren
  • gsutil-Liste auf VM1 aufgelöst für Ihren PSC-Dienstendpunkt
  • gsutil-Liste auf VM2 aufgelöst für öffentliches googleapis.com ausführen
  • DNS-Auflösung mit „tcpdump“ validieren

Voraussetzungen

  • Kenntnisse im DNS-, Nano- oder Vi-Editor

2. Private Service Connect-Anwendungsfälle

Sie können mehrere Private Service Connect-Endpunkte im selben VPC-Netzwerk erstellen. Für die Bandbreite an einem bestimmten Endpunkt gibt es kein Limit. 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 mithilfe von Cloud Router und Firewallregeln unterschiedliche Netzwerkpfade angeben.

  • Sie können Firewallregeln erstellen, um zu verhindern, dass einige VMs über einen Private Service Connect-Endpunkt auf Google APIs zugreifen, während andere VMs Zugriff haben.
  • Sie können eine Firewallregel auf einer VM-Instanz haben, die den gesamten Traffic zum Internet blockiert. Traffic, der an Private Service Connect-Endpunkte gesendet wird, erreicht Google weiterhin.
  • Wenn Sie lokale Hosts haben, die über einen Cloud VPN-Tunnel oder einen Cloud Interconnect-Anhang (VLAN) mit einer VPC verbunden sind, können Sie einige Anfragen über den Tunnel oder das VLAN senden, während andere Anfragen über das öffentliche Internet gesendet werden. 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. Erstellen Sie zum Erstellen dieser Konfiguration einen Private Service Connect-Endpunkt, bieten Sie die IP-Adressen des Private Service Connect-Endpunkts mit dem benutzerdefinierten Route Advertising von Cloud Router an und aktivieren Sie eine Cloud DNS-Richtlinie für die eingehende Weiterleitung. Die Anwendung kann einige Anfragen über den Cloud VPN-Tunnel oder den Cloud Interconnect-Anhang (VLAN) senden, indem sie den Namen des Private Service Connect-Endpunkts verwendet, und andere über das Internet mithilfe des DNS-Standardnamens.
  • Wenn Sie Ihr lokales Netzwerk über mehrere Cloud Interconnect-Anhänge (VLANs) mit Ihrem VPC-Netzwerk verbinden, können Sie einen Teil des lokalen Traffics über ein VLAN und den Rest über andere senden, wie in Abbildung 2 gezeigt. So können Sie anstelle des Netzwerks von Google Ihr eigenes Wide Area Network verwenden und die Datenbewegungen entsprechend den geografischen Anforderungen steuern. Erstellen Sie zum Erstellen dieser Konfiguration zwei Private Service Connect-Endpunkte. Erstellen Sie ein benutzerdefiniertes Routen-Advertising für den ersten Endpunkt in der BGP-Sitzung des Cloud Routers, der das erste VLAN verwaltet, und erstellen Sie ein anderes benutzerdefiniertes Routen-Advertising für den zweiten Endpunkt in der BGP-Sitzung des Cloud Routers, der das zweite VLAN verwaltet. Lokale Hosts, die für die Verwendung des Private Service Connect-Endpunktnamens 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 mithilfe von benutzerdefiniertem Routen-Advertising anbieten, werden Pakete, die von lokalen Systemen an die Endpunkte gesendet werden, mithilfe von ECMP durch die VLANs 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

Zur Verwendung von Private Service Connect muss die primäre Schnittstelle von VM-Instanzen ohne externe IP-Adresse in einem Subnetz mit aktiviertem privatem Google-Zugriff aktiviert sein.

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 bleibt im Google-Netzwerk.

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

Unterstützte APIs

Wenn Sie einen Private Service Connect-Endpunkt erstellen, wählen Sie aus, auf welches API-Bundle Sie Zugriff benötigen: all-apis oder vpc-sc.

Die API-Bundles ermöglichen Zugriff auf die gleichen 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 Bundle „vpc-sc“ bietet Zugriff auf die gleichen 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 Datenübertragung in Cloud Storage eine Mischung aus privatem (Interconnect) und öffentlichem googleapis-Zugriff. Um die Anforderungen unserer Kunden zu erfüllen, stellen wir Private Service Connect mit einer eindeutigen /32-Adresse, BOTO-Konfiguration und Aktualisierungen von DNS-Einträgen bereit. Die virtuelle Maschine 1 verwendet PSC für den Zugriff auf den Cloud Storage-Bucket. Im Gegensatz dazu verwendet VM2 öffentliche IP-Bereiche von googleapis.com über das NAT-GW.

Alle Aspekte des Labs werden innerhalb der Google Cloud Platform bereitgestellt. Es ist jedoch derselbe Anwendungsfall für eine Hybrid-Cloud-Bereitstellung mit Traffictrennung anwendbar.

5. Einrichtung und Anforderungen

Umgebung für das selbstbestimmte 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 in diesem Codelab später als PROJECT_ID bezeichnet.

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

Dieses Codelab sollte ohne großen Aufwand betrieben werden. Folgen Sie der Anleitung im Abschnitt „Bereinigen“, . Hier erfahren Sie, wie Sie Ressourcen herunterfahren, damit Ihnen über dieses Tutorial hinaus keine Kosten entstehen. Neue Google Cloud-Nutzer haben Anspruch auf eine kostenlose Testversion von 300$.

Cloud Shell starten

Sie können Google Cloud zwar von Ihrem Laptop aus aus der Ferne bedienen, in diesem Codelab verwenden Sie jedoch Google Cloud Shell, 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 dauert nur einen Moment. Wenn er abgeschlossen ist, sollten Sie in etwa Folgendes sehen:

f6ef2b5f13479f3a.png

Diese virtuelle Maschine verfügt über sämtliche Entwicklertools, die Sie benötigen. Es bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud, wodurch die Netzwerkleistung und Authentifizierung erheblich verbessert werden. Sie können alle Aufgaben in diesem Lab ganz einfach in einem Browser erledigen.

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

Aus Cloud Shell

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

Subnetz erstellen

Aus 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, müssen Sie eine Firewallregel erstellen, die:

  • Gilt für alle VM-Instanzen, die mit 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.

Aus 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

Aus Cloud Shell

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

Cloud NAT erstellen

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

Aus Cloud Shell

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

„pscendpointip“ speichern für die Dauer des Labs

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.

Aus 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

Aus Cloud Shell

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

Konfigurierte Private Service Connect-Endpunkte beschreiben

Aus 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, den Sie bevorzugen.

Aus Cloud Shell

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

Geschäft "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 über diesen Endpunkt verfügbar gemacht werden.

Die DNS-Einträge verweisen auf die IP-Adresse Ihres Private Service Connect-Endpunkts und haben folgendes 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 Google-Dienste zugreift, müssen Sie Ihren Client oder Ihre Anwendung so aktualisieren, dass er die p.googleapis.com-DNS-Namen verwendet.

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

  • Python: Sie können api_endpoint in der Klasse der Clientoptionen im Paket "google-api-core" konfigurieren.
  • Go: Sie können WithEndpoint im Client options Package im API-Paket konfigurieren.
  • gcloud: Sie können api_endpoint_overrides mit diesem Befehl konfigurieren. 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 DNS-Standardnamen entsprechen. Beispiel: storage.googleapis.com. Weitere Informationen finden Sie unter DNS-Einträge mithilfe von DNS-Standardnamen 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

Virtuelle Maschine (psc-instance-1) zum Validieren von Private Service Connect erstellen

Aus 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"

Klicken Sie dreimal auf „+“ (Screenshot unten), um weitere Cloud Shell-Terminals zu erstellen.

69ea94e1527912bb.png

Virtuelle Maschine (psc-instance-2) zum Validieren öffentlicher Googleapis erstellen

Von 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 

Von Tab 2 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"

Von Tab 3 SSH-Verbindung zu psc-instance-1 ü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-1" --project "$projectname"

Von Tab 4: Shell-SSH-Verbindung zu psc-instance-2 über Cloud Shell

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 prü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 des Storage-Buckets auf Tab 2 prüfen (psc-instance-2)

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

Prüfen Sie den gsutil-Debugger. 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 Storage-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

In einem vorherigen Schritt haben Sie eine private DNS-Zone und einen Eintrag erstellt, der der IP-Adresse des PSC-Endpunkts zugeordnet ist. Im folgenden Schritt steuern Sie das Verhalten von gsutil, indem Sie die VM-Datei BOTO auf psc-instance-1 aktualisieren.

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

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

Ausgabe (Ihre Projekt-ID wird abweichen)

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

[GoogleCompute]
service_account = default

Aktualisieren Sie die BOTO-Konfiguration mit dem Nano- oder VI-Editor. Kopieren Sie alle Einträge und fügen Sie sie ein.

Beispiel: sudo nano /etc/boto.cfg

oder

Beispiel: sudo vi /etc/boto.cfg

Auf dem Terminal-Tab 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. Die Reihenfolge der [Anmeldedaten] ist für den DNS-Lookup 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 Verhalten der gsutil-Suche überprüfen

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

sudo tcpdump -vv -i eth0 port 53

gsutil-Lookup für Storage-Bucket auf Tab 1 prüfen (psc-instance-1)

BUCKET_NAME=YOUR BUCKET NAME
echo $BUCKET_NAME

gsutil -D ls gs://$BUCKET_NAME

Debug-Logs bestätigen, dass der Storage-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 des PSC-Endpunkts der DNS-A-Eintrag ist, der beim Zugriff auf Ihren Storage-Bucket verwendet wurde.

@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

Löschen Sie die Lab-Komponenten in einem einzelnen Cloud Shell-Terminal.

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 das richtige Projekt angezeigt wird. Wählen Sie dann „Netzwerkdienste“ → „Cloud DNS“ aus.

16. Glückwunsch!

Herzlichen Glückwunsch zum Abschluss des Codelabs.

Behandelte Themen

  • Private Service Connect-Anwendungsfälle
  • Netzwerkanforderungen
  • Unterstützte APIs
  • Private Service Connect-Endpunkt erstellt
  • Cloud Storage-Bucket erstellt
  • BOTO-Konfigurationsdatei aktualisiert
  • NAT-GW erstellt
  • Führen Sie die gsutil-Liste auf VM1 aus, die für Ihren PSC-Dienstendpunkt aufgelöst wird.
  • gsutil-Liste auf VM2 ausführen, die für das öffentliche googleapis.com aufgelöst wird
  • DNS-Auflösung mit „tcpdump“ validieren