Private Service Connect für Google APIs

1. Einführung

Mit Private Service Connect können Sie private Endpunkte mithilfe von globalen internen IP-Adressen in Ihrem VPC-Netzwerk erstellen. 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 jeglichen Traffic zum Internet unterbindet. 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-Netzwerk 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-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 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 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 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 G Suite-Konto haben, müssen Sie ein Konto erstellen.

MrEseyJH4tg9PuS3GzJa72onCqawwQiRm04c0YjnpR6WD3IciP1ICDh5e5RoxrG3tc5y44_Ynn9GB0Igjo3sTE0BlsAnCxJdhXn7egP3tX4rkzkub7ZCjOKc70kJvl07REnmPb3TGg

HgKQ1sLCGDGbz0e3RCc-FNa3fQliCtq67H-Oj9jzzYn_upkmNN1lOMQrQm8Jdvo6EEYAvSwDEjpH37bIG9ouBJcmS_xFYV1IHJoyAhsasS1SfYtZkO-RBwWPXRrr3Zt4r31ETcjJeQ

KHAY2ncSMFGZ2vGxcMEcNoIy_cuWGCaWAsrH0KsOVwkV5e93Ypfcq3sQ_HPIrV-NSocegQN2PnRUku_CVi1MM89O6qHIU6E32ZypJPxojkbRTJXET5JvtskIXgzFMk18-4NnNjzCJA

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 möglichst wenig kosten. 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 können an einem kostenlosen Testzeitraum mit 300$Guthaben teilnehmen.

Cloud Shell starten

Sie können Google Cloud zwar von Ihrem Laptop 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:

yEqEFRN4OGfeGJEfJplSt5sGY95BluU78i3Lk0Opo9caOYfrWUPBi_RglIfo9x078tH5Z_Obgq1wOhrEPV8k5OvMgI5e3aam1a7teXuimwTy-evcupc34_UEMmfAFkV-hnXwl559rg

Die Bereitstellung und Verbindung mit der Umgebung dauert nur einen Moment. Wenn er abgeschlossen ist, sollten Sie in etwa Folgendes sehen:

BxRCLVCDNXX4OxwHppzaY9ghvuFTsgsozreyEHvRK9GPfsh3sW-kdwev6_gZdkX5FWPvb7M_Vp4FoyjFWwZxBMK6CLXiPwJgFbhz8Tgec-tyQR7GEdNjGMBca052yM8ga0UqzdHAmw

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

Von Cloud Shell

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

Ausgabe

Created
NAME     SUBNET_MODE  BGP_ROUTING_MODE  IPV4_RANGE  GATEWAY_IPV4
psc-lab  CUSTOM       REGIONAL

Subnetz erstellen

Von 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

Ausgabe

Created
NAME             REGION       NETWORK  RANGE
psclab-subnet  us-central1  psc-lab  10.0.0.0/24

Firewallregeln erstellen

Von Cloud Shell

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

Ausgabe

NAME        NETWORK  DIRECTION  PRIORITY  ALLOW   DENY  DISABLED
psclab-ssh  psc-lab  INGRESS    1000      tcp:22        False

Cloud NAT-Instanz erstellen

Cloud Router erstellen

Von Cloud Shell

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

Cloud NAT erstellen

Von 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.

Von Cloud Shell

gcloud beta compute addresses create psc-ip \
    --global \
    --purpose=PRIVATE_SERVICE_CONNECT \
    --addresses=<pscendpointip> \
    --network=psc-lab

„pscendpointip“ speichern für die Dauer des Labs

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

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.

Von Cloud Shell

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

Konfigurierte Private Service Connect-Endpunkte auflisten

Von Cloud Shell

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

Konfigurierte Private Service Connect-Endpunkte beschreiben

Von 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.

Von 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

Angenommen, Sie haben eine Anwendung, die Google Cloud Storage verwendet. Ohne Private Service Connect können Ihre Anwendungen eine Verbindung zu „storage.googleapis.com“ herstellen, die standardmäßig zu einer öffentlichen Adresse aufgelöst wird. Mit Private Service Connect können Sie Namen wie „storage-psclab.p.googleapis.com“ erstellen und verwenden. Der Name und die Adressen sind in Ihrem VPC-Netzwerk und allen angehängten lokalen Netzwerken privat.

Private Service Connect für DNS folgt der Namenskonvention SERVICE-ENDPOINT.p.googleapis.com. Im obigen Beispiel ist „storage“ ist der SERVICE und „psclab“ ist der ENDPOINT. Die Zeichen "-" müssen enthalten sein. zwischen SERVICE und ENDPOINT liegt.

Wenn Sie über den Private Service Connect-Endpunkt auf Cloud Storage zugreifen möchten, erstellen Sie einen DNS-(A)-Eintrag „storage-psclab.p.googleapis.com“, der auf die IP-Adresse des Private Service Connect-Endpunkts verweist.

Private DNS-Zone erstellen

gcloud dns --project=$projectname managed-zones create psc-dns-zone --description="" --dns-name="p.googleapis.com." --visibility="private" --networks="psc-lab"

DNS-A-Eintrag erstellen

gcloud dns --project=$projectname record-sets transaction start --zone=psc-dns-zone

gcloud dns --project=$projectname record-sets transaction add $pscendpointip --name=storage-pscendpoint.p.googleapis.com. --ttl=300 --type=A --zone=psc-dns-zone

gcloud dns --project=$projectname record-sets transaction execute --zone=psc-dns-zone

11. Virtuelle Maschinen erstellen

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

Von 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  = 234086459238
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  = 234086459238
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 beta compute forwarding-rules delete pscendpoint --global --quiet

gcloud beta 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.

d0ed4bd585006e45.png

Identifizieren und Klicken Sie auf „psc-dns-zone“.

903532e68a262111.png

Wählen Sie den Datensatz „storage-pscendpoint.p.googleapis.com“ aus Klicken Sie dann auf „Delete Record Sets“ (Einträge löschen).

e89394b43ddb5ce2.png

Klicken Sie auf „Zone löschen“, um die Lab-Bereinigung abzuschließen

b2a612d7b3a80030.png

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
  • Private Cloud DNS-Zonen 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