Частный сервис Connect 64

1. Введение

Private Service Connect революционизирует то, как организации используют услуги в экосистеме Google Cloud, обеспечивая полную поддержку адресации IPv6 наряду с IPv4. Оно сочетает в себе повышенную безопасность, упрощенное подключение, улучшенную производительность и централизованное управление, что делает его идеальным решением для предприятий, которым нужна надежная, надежная и эффективная модель потребления услуг, готовая к будущему сетевых технологий. Независимо от того, создаете ли вы гибридное облако, совместно используете сервисы в своей организации или получаете доступ к сторонним сервисам, PSC предлагает простой и безопасный путь для использования всего потенциала Google Cloud, одновременно используя преимущества IPv6.

Что вы узнаете

• Ключевые преимущества PSC 64
• Поддержка перевода Private Service Connect 64
• Обзор ULA с двойным стеком
• Требования к сети
• Создание службы-производителя Private Service Connect
• Создайте конечную точку Private Service Connect.
• Установите подключение к конечной точке Private Service Connect из виртуальной машины IPv4.
• Установите подключение к конечной точке Private Service Connect из виртуальной машины с двумя стеками.

Что вам понадобится

• Проект Google Cloud с разрешениями владельца

2. Что вы будете строить

Вы создадите сеть Producer для развертывания веб-сервера Apache в качестве опубликованной службы через Private Service Connect (PSC). После публикации вы выполните следующие действия для проверки доступа к службе Producer:

• Из потребительского VPC экземпляр IPv4 GCE нацельтесь на конечную точку IPv4 PSC, чтобы достичь службы производителя.
• Из потребительского VPC, экземпляра GCE с двумя стеками, нацельтесь на конечную точку IPv6 PSC, чтобы добраться до службы производителя.

Ключевые преимущества PSC 64

• Бесшовная интеграция: PSC легко интегрируется с сетями VPC, настроенными для IPv6, что позволяет вам использовать преимущества адресации IPv6 для ваших сервисных подключений.
• Поддержка двойного стека: PSC поддерживает конфигурации с двумя стеками, что позволяет одновременно использовать IPv4 и IPv6 в одном VPC, обеспечивая гибкость и надежность вашей сети в будущем.
• Упрощенный переход: PSC упрощает переход на IPv6, позволяя вам постепенно внедрять IPv6 наряду с существующей инфраструктурой IPv4.
• Поддержка производителя. Производитель не обязан использовать двойной стек, вместо этого у потребителя есть возможность развернуть конечную точку PSC IPv4 или IPv6.

3. Поддержка перевода Private Service Connect 64 и 66.

Соображения потребителей

IP-версией конечной точки может быть либо IPv4, либо IPv6, но не оба одновременно. Потребители могут использовать адрес IPv4, если подсеть адреса является одностековой . Потребители могут использовать адрес IPv4 или IPv6, если подсеть адреса является двухстековой. Потребители могут подключать конечные точки IPv4 и IPv6 к одному и тому же сервисному вложению, что может быть полезно для миграции сервисов на IPv6.

Соображения производителя

IP-версия правила переадресации производителя определяет IP-версию вложения службы и трафик, исходящий из вложения службы. IP-версией вложения службы может быть либо IPv4, либо IPv6, но не оба одновременно. Производители могут использовать адрес IPv4, если подсеть адреса является одностековой. Производители могут использовать адрес IPv4 или IPv6, если подсеть адреса является двухстековой.

IP-версия IP-адреса правила переадресации производителя должна быть совместима с типом стека подсети NAT вложения службы.

• Если правилом пересылки производителя является IPv4, подсеть NAT может быть одностековой или двухстековой.
• Если правилом пересылки производителя является IPv6, подсеть NAT должна быть двухстековой.

Для поддерживаемых конфигураций возможны следующие комбинации:

• Конечная точка IPv4 для подключения службы IPv4
• Конечная точка IPv6 для подключения службы IPv6
• Конечная точка IPv6 для подключения службы IPv4. В этой конфигурации Private Service Connect автоматически преобразует две версии IP.

Не поддерживается следующее:

Private Service Connect не поддерживает подключение конечной точки IPv4 с вложением службы IPv6. В этом случае создание конечной точки завершается неудачей со следующим сообщением об ошибке:

Правило переадресации Private Service Connect с адресом IPv4 не может быть нацелено на вложение службы IPv6.

4. Обзор ULA с двойным стеком

Google Cloud поддерживает создание частных подсетей ULA IPv6 и виртуальных машин. RFC 4193 определяет схему адресации IPv6 для локальной связи, идеальную для связи внутри VPC. Адреса ULA не поддерживают глобальную маршрутизацию, поэтому ваши виртуальные машины полностью изолированы от Интернета, обеспечивая поведение, аналогичное RFC-1918, при использовании IPv6. Google Cloud позволяет создавать префиксы ULA сети /48 VPC, чтобы все ваши подсети ULA IPv6 /64 были назначены из этого диапазона сети VPC.

Подобно глобальным уникальным внешним адресам IPv6, поддерживаемым Google Cloud, каждая подсеть с поддержкой ULA IPv6 получит подсеть /64 из диапазона ULA сети VPC /48, и каждой виртуальной машине будет назначен адрес /96 из этой подсети.

RFC4193 определяет адресное пространство IPv6 в диапазоне fc00::/7. Адреса ULA можно свободно выделять и использовать внутри частных сетей/сайтов. Google Cloud назначает все адреса ULA из диапазона fd20::/20. Эти адреса маршрутизируются только в пределах VPC и не маршрутизируются в глобальном Интернете IPv6.

Адреса ULA, назначенные Google Cloud, гарантированно будут уникальными во всех сетях VPC. Google Cloud гарантирует, что никаким двум сетям VPC не будет присвоен один и тот же префикс ULA. Это устраняет проблему перекрытия диапазонов в сетях VPC.

Вы можете либо разрешить Google Cloud автоматически назначать /48 вашей сети, либо выбрать конкретный префикс /48 IPv6. Если указанный вами префикс IPv6 уже назначен другому VPC или в вашей локальной сети, вы можете выбрать другой диапазон.

В лаборатории кода Google Cloud автоматически назначит /48, в результате чего будет получен глобально уникальный диапазон адресов ULA.

5. Требования к сети

Ниже приведена разбивка сетевых требований для сети потребителя и производителя:

Потребительская сеть (все компоненты развернуты в us-central1)

Компоненты	Описание
ВКК	Для работы в сети с двумя стеками требуется VPC в пользовательском режиме с включенным ULA.
Конечная точка PSC	Конечная точка IPv4 PSC, используемая для доступа к службе источника. Конечная точка PSC IPV6, используемая для доступа к службе производителя.
Подсеть(и)	IPv4 и двойной стек
ГЦЭ	IPv4 и двойной стек

Сеть производителя (все компоненты развернуты в us-central1)

Компоненты	Описание
ВКК	Пользовательский режим VPC, ULA не включен
Подсеть PSC NAT	IPv4. Пакеты из потребительской сети VPC преобразуются с использованием исходного NAT (SNAT), так что их исходные IP-адреса источника преобразуются в исходные IP-адреса из подсети NAT в сети VPC производителя.
Правило пересылки PSC	IPv4. Внутренний транзитный балансировщик сетевой нагрузки
Проверка здоровья	Правило входящего трафика, применимое к экземплярам с балансировкой нагрузки, которое разрешает трафик из систем проверки работоспособности Google Cloud (130.211.0.0/22 ​​и 35.191.0.0/16).
Серверная служба	Серверная служба действует как мост между балансировщиком нагрузки и серверными ресурсами. В этом руководстве серверная служба связана с группой неуправляемых экземпляров.
Группа неуправляемых экземпляров	Поддерживает виртуальные машины, требующие индивидуальной настройки или настройки. Не поддерживает автоматическое масштабирование.

6. Топология Codelab

7. Настройка и требования

Самостоятельная настройка среды

1. Войдите в Google Cloud Console и создайте новый проект или повторно используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .

• Имя проекта — это отображаемое имя для участников этого проекта. Это строка символов, не используемая API Google. Вы всегда можете обновить его.
• Идентификатор проекта уникален для всех проектов Google Cloud и является неизменяемым (невозможно изменить после его установки). Cloud Console автоматически генерирует уникальную строку; обычно тебя не волнует, что это такое. В большинстве лабораторий кода вам потребуется указать идентификатор проекта (обычно идентифицируемый как PROJECT_ID ). Если вам не нравится сгенерированный идентификатор, вы можете создать другой случайный идентификатор. Альтернативно, вы можете попробовать свой собственный и посмотреть, доступен ли он. Его нельзя изменить после этого шага и он сохраняется на протяжении всего проекта.
• К вашему сведению, есть третье значение — номер проекта , которое используют некоторые API. Подробнее обо всех трех этих значениях читайте в документации .

Внимание: Идентификатор проекта является глобально уникальным и не может быть использован кем-либо еще после того, как вы его выбрали. Вы единственный пользователь с этим идентификатором. Даже если проект будет удален, идентификатор нельзя будет использовать снова.

Примечание. Если вы используете учетную запись Gmail, вы можете оставить для местоположения по умолчанию значение «Нет организации» . Если вы используете учетную запись Google Workspace, выберите местоположение, подходящее для вашей организации.

2. Затем вам необходимо включить выставление счетов в Cloud Console, чтобы использовать облачные ресурсы/API. Прохождение этой кодовой лаборатории не будет стоить много, если вообще что-то стоить. Чтобы отключить ресурсы и избежать выставления счетов за пределами этого руководства, вы можете удалить созданные вами ресурсы или удалить проект. Новые пользователи Google Cloud имеют право на участие в программе бесплатной пробной версии стоимостью 300 долларов США .

Запустить Cloud Shell

Хотя Google Cloud можно управлять удаленно с вашего ноутбука, в этой лаборатории вы будете использовать Google Cloud Shell , среду командной строки, работающую в облаке.

В Google Cloud Console щелкните значок Cloud Shell на верхней правой панели инструментов:

Подготовка и подключение к среде займет всего несколько минут. Когда все будет готово, вы должны увидеть что-то вроде этого:

Эта виртуальная машина оснащена всеми необходимыми инструментами разработки. Он предлагает постоянный домашний каталог объемом 5 ГБ и работает в Google Cloud, что значительно повышает производительность сети и аутентификацию. Всю работу в этой лаборатории кода можно выполнять в браузере. Вам не нужно ничего устанавливать.

8. Прежде чем начать

Включить API

В Cloud Shell убедитесь, что идентификатор вашего проекта настроен:

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

Включите все необходимые службы:

gcloud services enable compute.googleapis.com

9. Создайте сеть VPC для производителей.

Сеть VPC

Внутри Cloud Shell выполните следующие действия:

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

Создание подсетей

Подсеть PSC будет связана с приложением службы PSC для целей трансляции сетевых адресов. Для производственных вариантов использования размер этой подсети должен быть соответствующим, чтобы поддерживать объем входящего трафика от всех подключенных конечных точек PSC. Дополнительную информацию см. в документации по определению размеров подсети PSC NAT.

Внутри Cloud Shell создайте подсеть PSC NAT:

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

В Cloud Shell создайте подсеть правила переадресации производителя:

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

Внутри Cloud Shell создайте подсеть виртуальной машины производителя:

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

Создайте общедоступный шлюз NAT.

Виртуальной машине производителя требуется доступ в Интернет для загрузки Apache, однако экземпляр GCE не имеет внешнего IP-адреса; следовательно, Cloud NAT обеспечит выход в Интернет для загрузки пакетов.

Внутри Cloud Shell создайте Cloud Router:

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

Внутри Cloud Shell создайте шлюз Cloud NAT, обеспечивающий выход в Интернет:

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

Создайте политику сетевого брандмауэра и правила брандмауэра.

Внутри Cloud Shell выполните следующие действия:

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

Чтобы разрешить IAP подключаться к вашим экземплярам виртуальных машин, создайте правило брандмауэра, которое:

• Применяется ко всем экземплярам виртуальных машин, доступ к которым вы хотите сделать с помощью IAP.
• Разрешает входящий трафик из диапазона IP 35.235.240.0/20. Этот диапазон содержит все IP-адреса, которые IAP использует для пересылки TCP.

Внутри Cloud Shell выполните следующие действия:

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

Следующее правило брандмауэра разрешает трафик из диапазона проверки работоспособности ко всем экземплярам в сети. В производственной среде это правило брандмауэра должно быть ограничено только экземплярами, связанными с конкретной службой производителя.

Внутри Cloud Shell выполните следующие действия:

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

Следующее правило брандмауэра разрешает передачу трафика из диапазона подсети PSC NAT во все экземпляры сети. В производственной среде это правило брандмауэра должно быть ограничено только экземплярами, связанными с конкретной службой производителя.

Внутри Cloud Shell выполните следующие действия:

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

Создайте виртуальную машину-производитель

Внутри Cloud Shell создайте веб-сервер Apache 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"

В Cloud Shell создайте неуправляемую группу экземпляров, состоящую из экземпляра Producer-VM и проверки работоспособности:

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. Создать службу продюсера

Создание компонентов балансировщика нагрузки

Внутри Cloud Shell выполните следующие действия:

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

В следующем синтаксисе создайте правило переадресации (балансировщик нагрузки внутренней сети) с предопределенным IP-адресом 172.16.2.3, связанным с внутренней службой, Producer-Backend-SVC.

В Cloud Shell выполните следующие действия:

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

Создать служебное приложение

Внутри Cloud Shell создайте вложение службы:

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

Затем получите и запишите вложение службы, указанное в URI selfLink, начиная с проектов, для настройки конечной точки PSC в потребительской среде.

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

Внутри Cloud Shell выполните следующие действия:

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

Пример ожидаемого результата

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

В Cloud Console перейдите к:

Сетевые службы → Подключение частных служб → Опубликованные службы

11. Создайте потребительскую сеть VPC.

Сеть VPC

Внутри Cloud Shell создайте потребительский VPC с включенным IPv6 ULA:

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

Google выделяет глобально уникальную подсеть /48 для Consumer VPC. Чтобы просмотреть распределение, выполните следующие действия:

В Cloud Console перейдите к:

Сети VPC

Создать подсеть

Внутри Cloud Shell создайте подсеть IPv4 GCE:

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

Внутри Cloud Shell создайте подсеть конечной точки IPv4 PSC:

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

Внутри Cloud Shell создайте подсеть GCE с двумя стеками:

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

Внутри Cloud Shell создайте двухстековую подсеть конечной точки PSC:

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

Создайте политику сетевого брандмауэра и правила брандмауэра.

Внутри Cloud Shell выполните следующие действия:

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

Для потребительской сети необходим только SSH от доступа IAP.

12. Создайте виртуальную машину, конечную точку PSC и проверьте подключение IPv4.

Создать тестовую виртуальную машину

Внутри Cloud Shell создайте экземпляр IPv4 GCE в подсети IPv4:

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

Создать статический IP-адрес конечной точки PSC

Внутри Cloud Shell создайте статический IP-адрес для конечной точки PSC.

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

Создайте конечную точку IPv4 PSC.

В Cloud Shell создайте конечную точку PSC, обновив URI SERVICE ATTACHMENT URI, используя URI, полученный при создании вложения службы.

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

Проверка конечной точки PSC

Давайте подтвердим, что производитель принял конечную точку PSC. В Cloud Console перейдите к:

Сетевые службы → Подключение частных служб → Подключенные конечные точки

Тестирование подключения

Внутри Cloud Shell подключитесь по SSH к экземпляру GCE, Consumer-VM-ipv4.

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

Теперь, когда вы вошли в экземпляр GCE, выполните скручивание до конечной точки psc, psc-ipv4-endpoint 192.168.11.13.

Внутри экземпляра GCE Consumer-vm-ipv4 выполните скручивание:

curl 192.168.11.13

Ожидаемый результат:

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

Внутри экземпляра GCE Consumer-vm-ipv4 выполните выход из экземпляра, выполнив выход, вернув вас обратно в Cloud Shell.

exit

Ожидаемый результат:

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

13. Создайте виртуальную машину, конечную точку PSC и протестируйте возможность подключения с двумя стеками.

Создать тестовую двухстековую виртуальную машину

Внутри Cloud Shell создайте экземпляр GCE с двумя стеками в подсети с двумя стеками:

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

Создайте статический IPv6-адрес конечной точки PSC.

Внутри Cloud Shell создайте статический IPv6-адрес для конечной точки PSC:

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

Получите статический IPv6-адрес конечной точки PSC.

Внутри Cloud Shell получите IPv6-адрес PSC, который вы будете использовать для доступа к службе Producer:

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

Примечание. Значение IPv6 будет отличаться, поскольку адреса ULA IPv6 глобально уникальны.

Пример вывода:

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

Создайте конечную точку IPv6 PSC.

В Cloud Shell создайте конечную точку PSC, обновив URI SERVICE ATTACHMENT URI, используя URI, полученный при создании вложения службы.

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

Проверка конечной точки PSC

Давайте подтвердим, что производитель принял конечную точку PSC. В Cloud Console перейдите к:

Сетевые службы → Подключение частных служб → Подключенные конечные точки

Тестирование подключения

Внутри Cloud Shell подключитесь по ssh к экземпляру GCE с двумя стеками, Consumer-vm-ipv4-ipv6, и выполните скручивание к конечной точке потребителей PSC IPv6, psc-ipv6-endpoint, чтобы проверить доступ к службе Producer.

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

Теперь, когда вы вошли в экземпляр GCE с двумя стеками, выполните скручивание до конечной точки psc, psc-dual-stack-endpoint, используя адреса IPv6, определенные на предыдущем шаге.

Внутри экземпляра GCE Consumer-vm-ipv4-ipv6 выполните скручивание до конечной точки IPv6 PSC, указанной на шаге Получение статического IPv6 конечной точки PSC.

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

Ожидаемый результат:

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

Внутри экземпляра Consumer-vm-ipv4-ipv6 GCE выполните выход из экземпляра, выполнив выход, вернув вас обратно в Cloud Shell.

exit

Ожидаемый результат:

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

14. Этапы очистки

Удаление компонентов лаборатории из одного терминала 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. Поздравления

Поздравляем, вы успешно настроили и проверили Private Service Connect 64.

Вы создали инфраструктуру производителя и узнали, как создать потребительскую конечную точку IPv4 и IPv6 в потребительской сети VPC, которая позволяла бы подключаться к службе источника.

Cosmopup считает, что кодлабы — это здорово!!

Что дальше?

Посмотрите некоторые из этих кодовых лабораторий...

• Использование Private Service Connect для публикации и использования сервисов с помощью GKE
• Использование Private Service Connect для публикации и использования сервисов
• Подключайтесь к локальным службам через гибридную сеть с помощью Private Service Connect и внутреннего балансировщика нагрузки TCP-прокси.
• Доступ ко всем опубликованным лабораториям кода Private Service Connect.

Дальнейшее чтение и видео

• Обзор частного сервиса Connect

• Поддерживаемые типы балансировщиков нагрузки

Справочная документация

• перевод IP-версии
• Поддержка IPv6
• Обзор внутреннего транзитного балансировщика сетевой нагрузки
• Обзор проверок работоспособности
• Как опубликовать службу с помощью Private Service Connect