Private Service Connect 64

1. Introducción

Private Service Connect revoluciona la forma en que las organizaciones consumen servicios dentro del ecosistema de Google Cloud, ya que proporciona compatibilidad total con el direccionamiento IPv6 junto con IPv4. Combina seguridad mejorada, conectividad simplificada, rendimiento optimizado y administración centralizada, lo que la convierte en una solución ideal para las empresas que buscan un modelo de consumo de servicios sólido, confiable y eficiente que esté preparado para el futuro de las redes. Ya sea que estés creando una nube híbrida, compartiendo servicios en toda tu organización o accediendo a servicios de terceros, el PSC ofrece una ruta segura y sin interrupciones para aprovechar todo el potencial de Google Cloud y, al mismo tiempo, disfrutar de los beneficios de IPv6.

Qué aprenderás

  • Beneficios clave de la PSC 64
  • Traducción compatible con Private Service Connect 64
  • Descripción general de la ULA de pila doble
  • Requisitos de red
  • Crea un servicio de productor de Private Service Connect
  • Crear un extremo de Private Service Connect
  • Establece conectividad con el extremo de Private Service Connect desde una VM IPv4
  • Establece conectividad con el extremo de Private Service Connect desde una VM de doble pila

Requisitos

  • Proyecto de Google Cloud con permisos de propietario

2. Qué compilarás

Establecerás una red de productor para implementar un servidor web de Apache como un servicio publicado a través de Private Service Connect (PSC). Una vez que se publique, realizarás las siguientes acciones para validar el acceso al servicio de Producer:

  • Desde la instancia de GCE con IPv4 de la VPC del consumidor, apunta al extremo de PSC con IPv4 para llegar al servicio del productor.
  • Desde la VPC del consumidor, la instancia de GCE de pila doble, apunta al extremo de PSC de IPv6 para llegar al servicio del productor.

Beneficios clave de la PSC 64

  • Integración perfecta: PSC se integra sin problemas con las redes de VPC configuradas para IPv6, lo que te permite aprovechar los beneficios del direccionamiento IPv6 para tus conexiones de servicio.
  • Compatibilidad con doble pila: PSC admite configuraciones de doble pila, lo que permite el uso simultáneo de IPv4 e IPv6 dentro de la misma VPC, lo que proporciona flexibilidad y prepara tu red para el futuro.
  • Transición simplificada: PSC simplifica la transición a IPv6, ya que te permite adoptar IPv6 de forma gradual junto con tu infraestructura IPv4 existente.
  • Compatibilidad con el productor: No es necesario que el productor adopte la pila doble, sino que el consumidor tiene la opción de implementar un extremo de PSC de IPv4 o IPv6.

3. Traducción compatible con Private Service Connect 64 y 66

Consideraciones para el consumidor

La versión de IP del extremo puede ser IPv4 o IPv6, pero no ambas. Los consumidores pueden usar una dirección IPv4 si la subred de la dirección es de pila única. Los consumidores pueden usar una dirección IPv4 o IPv6 si la subred de la dirección es de pila doble. Los consumidores pueden conectar tanto extremos IPv4 como IPv6 al mismo adjunto de servicio, lo que puede ser útil para migrar servicios a IPv6.

Consideraciones del productor

La versión de IP de la regla de reenvío del productor determina la versión de IP del adjunto de servicio y el tráfico que sale del adjunto de servicio. La versión de IP del adjunto de servicio puede ser IPv4 o IPv6, pero no ambas. Los productores pueden usar una dirección IPv4 si la subred de la dirección es de pila única. Los productores pueden usar una dirección IPv4 o IPv6 si la subred de la dirección es de pila doble.

La versión de IP de la dirección IP de la regla de reenvío del productor debe ser compatible con el tipo de pila de la subred NAT del adjunto de servicio.

  • Si la regla de reenvío del productor es IPv4, la subred NAT puede ser de pila única o doble.
  • Si la regla de reenvío del productor es IPv6, la subred NAT debe ser de pila doble.

Las siguientes combinaciones son posibles para las configuraciones compatibles:

  • Extremo de IPv4 al adjunto de servicio IPv4
  • Extremo de IPv6 al adjunto de servicio IPv6
  • Extremo IPv6 a adjunto de servicio IPv4: En esta configuración, Private Service Connect traduce automáticamente entre las dos versiones de IP.

No se admite lo siguiente:

Private Service Connect no admite la conexión de un extremo IPv4 con un adjunto de servicio IPv6. En este caso, la creación del extremo falla con el siguiente mensaje de error:

Una regla de reenvío de Private Service Connect con una dirección IPv4 no puede segmentar un adjunto de servicio IPv6.

4. Descripción general de la ULA de pila doble

Google Cloud admite la creación de subredes y VMs privadas de IPv6 de ULA. El RFC 4193 define un esquema de direccionamiento IPv6 para la comunicación local, ideal para la comunicación dentro de la VPC. Las direcciones ULA no se pueden enrutar de forma global, por lo que tus VMs están completamente aisladas de Internet y proporcionan un comportamiento similar a RFC-1918 con IPv6. Google Cloud permite la creación de prefijos de ULA de red de VPC /48 para que todas tus subredes de ULA de IPv6 /64 se asignen desde ese rango de red de VPC.

De manera similar a las direcciones IPv6 externas únicas a nivel global que admite Google Cloud, cada subred habilitada para IPv6 de ULA recibirá una subred /64 del rango de ULA de la red de VPC /48, y a cada VM se le asignará una dirección /96 de esa subred.

En RFC4193, se define el espacio de direcciones IPv6 en el rango de fc00::/7. Las direcciones ULA se pueden asignar y usar libremente dentro de redes o sitios privados. Google Cloud asigna todas las direcciones ULA del rango fd20::/20. Estas direcciones solo se pueden enrutar dentro del alcance de las VPC y no se pueden enrutar en la Internet global de IPv6.

Se garantiza que las direcciones de ULA asignadas por Google Cloud son únicas en todas las redes de VPC. Google Cloud garantiza que no se asigne el mismo prefijo ULA a dos redes de VPC. Esto elimina el problema de los rangos superpuestos en las redes de VPC.

Puedes permitir que Google Cloud asigne automáticamente el prefijo /48 a tu red o elegir un prefijo IPv6 /48 específico. Si el prefijo IPv6 que especificaste ya está asignado a otra VPC o a tu red local, puedes elegir otro rango.

5. Requisitos de red

A continuación, se desglosan los requisitos de red para la red del consumidor y la red del productor:

Red del consumidor (todos los componentes implementados en us-central1)

Componentes

Descripción

VPC

Las redes de doble pila requieren una VPC en modo personalizado con ULA habilitada

Extremo de PSC

  • Extremo de PSC de IPv4 que se usa para acceder al servicio de productor
  • Extremo de PSC de IPv6 que se usa para acceder al servicio del productor

Subredes

IPv4 y pila doble

GCE

IPv4 y pila doble

Red del productor(todos los componentes implementados en us-central1)

Componentes

Descripción

VPC

VPC en modo personalizado, ULA no habilitada

Subred de NAT de PSC

IPv4 Los paquetes de la red de VPC del consumidor se traducen con NAT de origen (SNAT) para que sus direcciones IP de origen originales se conviertan en direcciones IP de origen de la subred NAT en la red de VPC del productor.

Regla de reenvío de PSC

IPv4 Balanceador de cargas de red de transferencia interno

Verificación de estado

Es una regla de entrada, aplicable a las instancias en las que se realiza el balanceo de cargas, que permite el tráfico de los sistemas de verificación de estado de Google Cloud (130.211.0.0/22 y 35.191.0.0/16).

Servicio de backend

Un servicio de backend actúa como puente entre tu balanceador de cargas y tus recursos de backend. En el instructivo, el servicio de backend está asociado al grupo de instancias no administrado.

Grupo de instancias no administrado

Admite VMs que requieren configuración o ajustes individuales. No admite el ajuste de escala automático.

6. Topología del codelab

b52931afd997d61.png

7. Configuración y requisitos

Configuración del entorno de autoaprendizaje

  1. Accede a Google Cloud Console y crea un proyecto nuevo o reutiliza uno existente. Si aún no tienes una cuenta de Gmail o de Google Workspace, debes crear una.

fbef9caa1602edd0.png

a99b7ace416376c4.png

5e3ff691252acf41.png

  • El Nombre del proyecto es el nombre visible de los participantes de este proyecto. Es una cadena de caracteres que no se utiliza en las APIs de Google. Puedes actualizarla cuando quieras.
  • El ID del proyecto es único en todos los proyectos de Google Cloud y es inmutable (no se puede cambiar después de configurarlo). La consola de Cloud genera automáticamente una cadena única. Por lo general, no importa cuál sea. En la mayoría de los codelabs, deberás hacer referencia al ID de tu proyecto (suele identificarse como PROJECT_ID). Si no te gusta el ID que se generó, podrías generar otro aleatorio. También puedes probar uno propio y ver si está disponible. No se puede cambiar después de este paso y se usa el mismo durante todo el proyecto.
  • Recuerda que hay un tercer valor, un número de proyecto, que usan algunas APIs. Obtén más información sobre estos tres valores en la documentación.
  1. A continuación, deberás habilitar la facturación en la consola de Cloud para usar las APIs o los recursos de Cloud. Ejecutar este codelab no costará mucho, tal vez nada. Para cerrar recursos y evitar que se generen cobros más allá de este instructivo, puedes borrar los recursos que creaste o borrar el proyecto. Los usuarios nuevos de Google Cloud son aptos para participar en el programa Prueba gratuita de $300.

Inicia Cloud Shell

Si bien Google Cloud y Spanner se pueden operar de manera remota desde tu laptop, en este codelab usarás Google Cloud Shell, un entorno de línea de comandos que se ejecuta en la nube.

En Google Cloud Console, haz clic en el ícono de Cloud Shell en la barra de herramientas en la parte superior derecha:

55efc1aaa7a4d3ad.png

El aprovisionamiento y la conexión al entorno deberían tomar solo unos minutos. Cuando termine el proceso, debería ver algo como lo siguiente:

7ffe5cbb04455448.png

Esta máquina virtual está cargada con todas las herramientas de desarrollo que necesitarás. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud, lo que permite mejorar considerablemente el rendimiento de la red y la autenticación. Todo tu trabajo en este codelab se puede hacer en un navegador. No es necesario que instales nada.

8. Antes de comenzar

Habilita las APIs

En Cloud Shell, asegúrate de que tu ID del proyecto esté configurado:

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
project=[YOUR-PROJECT-ID]
region=us-central1
echo $project
echo $region

Habilita todos los servicios necesarios con el siguiente comando:

gcloud services enable compute.googleapis.com

9. Crea la red de VPC del productor

Red de VPC

Dentro de Cloud Shell, haz lo siguiente:

gcloud compute networks create producer-vpc --subnet-mode custom

Crear subredes

La subred de PSC se asociará con el adjunto de servicio de PSC para la traducción de direcciones de red. Para los casos de uso de producción, esta subred debe tener el tamaño adecuado para admitir la cantidad de tráfico entrante de todos los extremos de PSC adjuntos. Consulta la documentación sobre el tamaño de la subred de NAT de PSC para obtener más información.

Dentro de Cloud Shell, crea la subred de NAT de PSC:

gcloud compute networks subnets create producer-psc-nat-subnet --network producer-vpc --range 172.16.10.0/28 --region $region --purpose=PRIVATE_SERVICE_CONNECT

Dentro de Cloud Shell, crea la subred de la regla de reenvío del productor:

gcloud compute networks subnets create producer-psc-fr-subnet --network producer-vpc --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

Dentro de Cloud Shell, crea la subred de la VM del productor:

gcloud compute networks subnets create producer-psc-vm-subnet --network producer-vpc --range 172.16.30.0/28 --region $region --enable-private-ip-google-access

Crea la puerta de enlace de NAT pública

La VM del productor requiere acceso a Internet para descargar Apache. Sin embargo, la instancia de GCE no tiene una IP externa. Por lo tanto, Cloud NAT proporcionará salida a Internet para la descarga de paquetes.

Dentro de Cloud Shell, crea el Cloud Router:

gcloud compute routers create producer-cloud-router --network producer-vpc --region us-central1

Dentro de Cloud Shell, crea la puerta de enlace de Cloud NAT que habilita la salida a Internet:

gcloud compute routers nats create producer-nat-gw --router=producer-cloud-router --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1

Crea una política de firewall de red y reglas de firewall

Dentro de Cloud Shell, haz lo siguiente:

gcloud compute network-firewall-policies create producer-vpc-policy --global

gcloud compute network-firewall-policies associations create --firewall-policy producer-vpc-policy --network producer-vpc --name producer-vpc --global-firewall-policy

Para permitir que IAP se conecte a tus instancias de VM, crea una regla de firewall que cumpla con lo siguiente:

  • Se aplica a todas las instancias de VM a las que deseas acceder mediante IAP.
  • Permite el tráfico de entrada desde el rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.

Dentro de Cloud Shell, haz lo siguiente:

gcloud compute network-firewall-policies rules create 1000 --action ALLOW --firewall-policy producer-vpc-policy --description "SSH with IAP" --direction INGRESS --src-ip-ranges 35.235.240.0/20 --layer4-configs tcp:22  --global-firewall-policy

La siguiente regla de firewall permite el tráfico del rango de sondeo de verificación de estado a todas las instancias de la red. En un entorno de producción, esta regla de firewall debe limitarse solo a las instancias asociadas con el servicio del productor específico.

Dentro de Cloud Shell, haz lo siguiente:

gcloud compute network-firewall-policies rules create 2000 --action ALLOW --firewall-policy producer-vpc-policy --description "allow traffic from health check probe range" --direction INGRESS --src-ip-ranges 130.211.0.0/22,35.191.0.0/16 --layer4-configs tcp:80 --global-firewall-policy

La siguiente regla de firewall permite el tráfico del rango de subred de NAT de PSC a todas las instancias de la red. En un entorno de producción, esta regla de firewall debe limitarse solo a las instancias asociadas con el servicio del productor específico.

Dentro de Cloud Shell, haz lo siguiente:

gcloud compute network-firewall-policies rules create 2001 --action ALLOW --firewall-policy producer-vpc-policy --description "allow traffic from PSC NAT subnet" --direction INGRESS --src-ip-ranges 172.16.10.0/28 --global-firewall-policy --layer4-configs=tcp

Crea la VM del productor

Dentro de Cloud Shell, crea el servidor web de Apache de producer-vm:

gcloud compute instances create producer-vm \
    --project=$project \
    --machine-type=e2-micro \
    --image-family debian-12 \
    --no-address \
    --image-project debian-cloud \
    --zone us-central1-a \
    --subnet=producer-psc-vm-subnet \
    --metadata startup-script="#! /bin/bash
      sudo apt-get update
      sudo apt-get install apache2 -y
      sudo service apache2 restart
      echo 'Welcome to Producer-VM !!' | tee /var/www/html/index.html
      EOF"

Dentro de Cloud Shell, crea el grupo de instancias no administrado que consta de la instancia producer-vm y la verificación de estado:

gcloud compute instance-groups unmanaged create producer-instance-group --zone=us-central1-a

gcloud compute instance-groups unmanaged add-instances producer-instance-group  --zone=us-central1-a --instances=producer-vm

gcloud compute health-checks create http hc-http-80 --port=80

10. Crea el servicio de productor

Crea componentes del balanceador de cargas

Dentro de Cloud Shell, haz lo siguiente:

gcloud compute backend-services create producer-backend-svc --load-balancing-scheme=internal --protocol=tcp --region=us-central1 --health-checks=hc-http-80

gcloud compute backend-services add-backend producer-backend-svc --region=us-central1 --instance-group=producer-instance-group --instance-group-zone=us-central1-a

En la siguiente sintaxis, crea una regla de reenvío (balanceador de cargas de red interno) con una dirección IP predefinida 172.16.2.3 asociada al servicio de backend, producer-backend-svc.

En Cloud Shell, haz lo siguiente:

gcloud compute forwarding-rules create producer-fr --region=us-central1 --load-balancing-scheme=internal --network=producer-vpc --subnet=producer-psc-fr-subnet --address=172.16.20.3 --ip-protocol=TCP --ports=all --backend-service=producer-backend-svc --backend-service-region=us-central1

Crea un adjunto de servicio

Dentro de Cloud Shell, crea la vinculación de servicio:

gcloud compute service-attachments create ipv4-producer-svc-attachment --region=$region --producer-forwarding-rule=producer-fr --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=producer-psc-nat-subnet

A continuación, obtén y anota el adjunto de servicio que se indica en el URI de selfLink que comienza con projects para configurar el extremo de PSC en el entorno del consumidor.

selfLink: projects/<your-project-id>/regions/us-central1/serviceAttachments/ipv4-producer-svc-attachment

Dentro de Cloud Shell, haz lo siguiente:

gcloud compute service-attachments describe ipv4-producer-svc-attachment --region=$region

Ejemplo de resultado esperado

user@cloudshell:~ (projectid)$ gcloud compute service-attachments describe ipv4-producer-svc-attachment --region=$region
connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2024-08-26T07:08:01.625-07:00'
description: ''
enableProxyProtocol: false
fingerprint: USOMy1eQKyM=
id: '1401660514263708334'
kind: compute#serviceAttachment
name: ipv4-producer-svc-attachment
natSubnets:
- https://www.googleapis.com/compute/v1/projects/projectid/regions/us-central1/subnetworks/producer-psc-nat-subnet
pscServiceAttachmentId:
  high: '85245007652455400'
  low: '1401660514263708334'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/projectid/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/projectid/regions/us-central1/serviceAttachments/ipv4-producer-svc-attachment
targetService: https://www.googleapis.com/compute/v1/projects/projectid/regions/us-central1/forwardingRules/producer-fr

En la consola de Cloud, navega a:

Servicios de red → Private Service Connect → Servicios publicados

9166d64204ec31c3.png

1b5feeca51b6533e.png

11. Crea la red de VPC del consumidor

Red de VPC

Dentro de Cloud Shell, crea la VPC del consumidor con la ULA de IPv6 habilitada:

gcloud compute networks create consumer-vpc \
    --subnet-mode=custom \
    --enable-ula-internal-ipv6

Google asigna una subred /48 globalmente única a la VPC de consumidor. Para ver la asignación, haz lo siguiente:

En la consola de Cloud, navega a:

Redes de VPC

c847bd7c20e3677d.png

Crear subred

Dentro de Cloud Shell, crea la subred de GCE IPv4:

gcloud compute networks subnets create consumer-v4-subnet --network consumer-vpc --range=192.168.10.0/28 --region $region --enable-private-ip-google-access

Dentro de Cloud Shell, crea la subred del extremo de PSC IPv4:

gcloud compute networks subnets create psc-ipv4-endpoint-subnet --network consumer-vpc --range=192.168.11.0/28 --region $region --enable-private-ip-google-access

Dentro de Cloud Shell, crea la subred de GCE de pila doble:

gcloud compute networks subnets create consumer-dual-stack-subnet --network consumer-vpc --range=192.168.20.0/28 --stack-type=IPV4_IPV6 --ipv6-access-type=INTERNAL --region $region --enable-private-ip-google-access

Dentro de Cloud Shell, crea la subred del extremo de PSC de pila doble:

gcloud compute networks subnets create psc-dual-stack-endpoint-subnet --network consumer-vpc --range=192.168.21.0/28 --stack-type=IPV4_IPV6 --ipv6-access-type=INTERNAL --region $region --enable-private-ip-google-access

Crea una política de firewall de red y reglas de firewall

Dentro de Cloud Shell, haz lo siguiente:

gcloud compute network-firewall-policies create consumer-vpc-policy --global

gcloud compute network-firewall-policies associations create --firewall-policy consumer-vpc-policy --network consumer-vpc --name consumer-vpc --global-firewall-policy

gcloud compute network-firewall-policies rules create 1000 --action ALLOW --firewall-policy consumer-vpc-policy --description "SSH with IAP" --direction INGRESS --src-ip-ranges 35.235.240.0/20 --layer4-configs tcp:22  --global-firewall-policy

Solo se necesita acceso SSH desde IAP para la red del consumidor.

12. Crea una VM y un extremo de PSC, y prueba la conectividad IPv4

Crea la VM de prueba.

Dentro de Cloud Shell, crea la instancia de GCE IPv4 en la subred IPv4:

gcloud compute instances create consumer-vm-ipv4 --zone=us-central1-a --subnet=consumer-v4-subnet --no-address

Crea una IP estática del extremo de PSC

Dentro de Cloud Shell, crea una dirección IP estática para el extremo de PSC.

gcloud compute addresses create psc-ipv4-endpoint-ip --region=$region --subnet=psc-ipv4-endpoint-subnet --addresses 192.168.11.13

Crea el extremo de PSC IPv4

Dentro de Cloud Shell, actualiza el URI del adjunto de servicio con el URI que capturaste cuando creaste el adjunto de servicio para crear el extremo de PSC.

gcloud compute forwarding-rules create psc-ipv4-endpoint --region=$region --network=consumer-vpc --address=psc-ipv4-endpoint-ip --target-service-attachment=[SERVICE ATTACHMENT URI]

Valida el extremo de PSC

Confirmemos que el productor aceptó el extremo de PSC. En la consola de Cloud, navega a:

Servicios de red → Private Service Connect → Extremos conectados

ac858b2db226e58a.png

Probar la conectividad

Dentro de Cloud Shell, establece una conexión SSH con la instancia de GCE, consumer-vm-ipv4.

gcloud compute ssh --zone us-central1-a "consumer-vm-ipv4" --tunnel-through-iap --project $project

Ahora que accediste a la instancia de GCE, realiza una solicitud curl al extremo de PSC, psc-ipv4-endpoint 192.168.11.13.

Dentro de la instancia de GCE consumer-vm-ipv4, realiza un curl:

curl 192.168.11.13

Resultado esperado:

user@consumer-vm-ipv4:~$ curl 192.168.11.13
Welcome to Producer-VM !!

Dentro de la instancia de GCE consumer-vm-ipv4, cierra la sesión de la instancia con un comando exit, que te devolverá a Cloud Shell.

exit

Resultado esperado:

user@consumer-vm-ipv4:~$ exit
logout
Connection to compute.6833450446005281720 closed.

13. Crea una VM y un extremo de PSC, y prueba la conectividad de doble pila

Crea la VM de prueba de doble pila

Dentro de Cloud Shell, crea la instancia de GCE de pila doble en la subred de pila doble:

gcloud compute instances create consumer-vm-ipv4-ipv6 --zone=us-central1-a --subnet=consumer-dual-stack-subnet --no-address --stack-type=IPV4_IPV6

Crea una dirección IPv6 estática del extremo de PSC

En Cloud Shell, crea una dirección IPv6 estática para el extremo de PSC:

gcloud compute addresses create psc-ipv6-endpoint-ip --region=$region --subnet=psc-dual-stack-endpoint-subnet --ip-version=IPV6

Obtén la dirección IPv6 estática del extremo de PSC

Dentro de Cloud Shell, obtén la dirección IPv6 del PSC que usarás para acceder al servicio del productor:

gcloud compute addresses describe psc-ipv6-endpoint-ip --region=us-central1 | grep -i address:

Resultado de ejemplo:

user@cloudshell$ gcloud compute addresses describe psc-ipv6-endpoint-ip --region=us-central1 | grep -i address:
address: 'fd20:2eb:7252:2::'

Crea el extremo de PSC de IPv6

Dentro de Cloud Shell, actualiza el URI del adjunto de servicio con el URI que capturaste cuando creaste el adjunto de servicio para crear el extremo de PSC.

gcloud compute forwarding-rules create psc-ipv6-endpoint --region=$region --network=consumer-vpc --address=psc-ipv6-endpoint-ip --target-service-attachment=[SERVICE ATTACHMENT URI]

Valida el extremo de PSC

Confirmemos que el productor aceptó el extremo de PSC. En la consola de Cloud, navega a:

Servicios de red → Private Service Connect → Extremos conectados

957b74e89f3ad837.png

Probar la conectividad

Dentro de Cloud Shell, accede a la instancia de GCE de pila doble, consumer-vm-ipv4-ipv6, a través de SSH y realiza una solicitud curl al extremo de consumidores de IPv6 de PSC, psc-ipv6-endpoint, para validar el acceso al servicio del productor.

gcloud compute ssh --zone us-central1-a "consumer-vm-ipv4-ipv6" --tunnel-through-iap --project $project

Ahora que accediste a la instancia de GCE de pila doble, realiza una solicitud curl al extremo de PSC, psc-dual-stack-endpoint, con las direcciones IPv6 identificadas en el paso anterior.

Dentro de la instancia de GCE consumer-vm-ipv4-ipv6, realiza una solicitud curl al extremo de PSC IPv6 identificado en el paso Obtén la dirección IPv6 estática del extremo de PSC.

curl -6 http://[insert-your-ipv6-psc-endpoint]

Resultado esperado:

user@consumer-vm-ipv4-ipv6$ curl -6 http://[fd20:2eb:7252:2::]
Welcome to Producer-VM !!

Dentro de la instancia de GCE consumer-vm-ipv4-ipv6, cierra la sesión de la instancia con un comando exit, que te devolverá a Cloud Shell.

exit

Resultado esperado:

user@consumer-vm-ipv4-ipv6:~$ exit
logout
Connection to compute.6162185519072639197 closed.

14. Pasos para la limpieza

Borra los componentes del lab desde una sola terminal de Cloud Shell

gcloud compute service-attachments delete ipv4-producer-svc-attachment --region=us-central1 -q

gcloud compute forwarding-rules delete psc-ipv6-endpoint psc-ipv4-endpoint --region=us-central1 -q

gcloud compute instances delete consumer-vm-ipv4 consumer-vm-ipv4-ipv6 --zone=us-central1-a -q

gcloud compute network-firewall-policies rules delete 1000 --firewall-policy=consumer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=consumer-vpc-policy  --name=consumer-vpc --global-firewall-policy -q

gcloud compute network-firewall-policies delete consumer-vpc-policy --global -q

gcloud compute addresses delete psc-ipv4-endpoint-ip psc-ipv6-endpoint-ip --region=us-central1 -q

gcloud compute networks subnets delete consumer-v4-subnet psc-ipv4-endpoint-subnet consumer-dual-stack-subnet psc-dual-stack-endpoint-subnet --region=us-central1 -q

gcloud compute networks delete consumer-vpc -q

gcloud compute forwarding-rules delete producer-fr --region=us-central1 -q

gcloud compute backend-services delete producer-backend-svc --region=us-central1 -q

gcloud compute health-checks delete hc-http-80 -q

gcloud compute network-firewall-policies rules delete 2001 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 2000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies rules delete 1000 --firewall-policy producer-vpc-policy --global-firewall-policy -q

gcloud compute network-firewall-policies associations delete --firewall-policy=producer-vpc-policy  --name=producer-vpc --global-firewall-policy -q

gcloud compute network-firewall-policies delete producer-vpc-policy --global -q

gcloud compute instance-groups unmanaged delete producer-instance-group --zone=us-central1-a -q

gcloud compute instances delete producer-vm --zone=us-central1-a -q

gcloud compute routers nats delete producer-nat-gw --router=producer-cloud-router --router-region=us-central1 -q

gcloud compute routers delete producer-cloud-router --region=us-central1 -q

gcloud compute networks subnets delete producer-psc-fr-subnet  producer-psc-vm-subnet producer-psc-nat-subnet --region=us-central1 -q

gcloud compute networks delete producer-vpc -q

15. Felicitaciones

Felicitaciones, configuraste y validaste correctamente Private Service Connect 64.

Creaste la infraestructura del productor y aprendiste a crear un extremo del consumidor IPv4 e IPv6 en la red de VPC del consumidor que permitía la conectividad con el servicio del productor.

Cosmopup cree que los codelabs son increíbles.

c911c127bffdee57.jpeg

¿Qué sigue?

Consulta algunos codelabs sobre los siguientes temas:

Lecturas y videos adicionales

Documentos de referencia