1. Введение
Группа сетевых конечных точек Private Service Connect (PSC) поддерживает объединение внутреннего балансировщика нагрузки HTTPS с внешним балансировщиком нагрузки HTTPS. Это обеспечивает распределенные проверки работоспособности и передачу трафика плоскости данных в локальную сеть с использованием заданных пользователем диапазонов. Кроме того, в этой топологии поддерживается подключение нескольких VPC к локальной сети через несколько региональных межсоединений.
В этом практическом занятии мы продемонстрируем, как настроить сквозную конфигурацию на основе представленной ниже топологии. Слева направо, клиенты в локальной сети используют виртуальную машину для имитации HTTP-сервисов, гибридное подключение (HA-VPN или InterConnect) и гибридную сеть NEG для предоставления доступа через внутренний балансировщик нагрузки HTTPS. PSC использует внутренний балансировщик нагрузки HTTPS в качестве подключений к сервисам. PSC NEG использует эти подключения в качестве бэкэнд-сервиса, предоставляемого через внешний балансировщик нагрузки HTTPS. Пользователи Интернета могут использовать глобальную сеть Google для ускорения доступа к локальным HTTP-сервисам.

Рисунок 1. Private Service Connect использует группу сетевых конечных точек и подключения служб для соединения внешнего балансировщика нагрузки HTTPS с внутренним балансировщиком нагрузки HTTPS и расширения бэкэнда на локальную инфраструктуру.
Что вы узнаете
- Внутренний балансировщик нагрузки HTTPS с гибридной NEG и распределенной проверкой работоспособности.
- Подключение сервиса PSC с внутренним балансировщиком нагрузки HTTPS
- Настройка группы конечных точек сети PSC
- Обеспечьте доступ к PSC NEG через внешний балансировщик нагрузки HTTPS.
Что вам понадобится
- Знание гибридных технологий подключения, таких как HA-VPN.
- Знание принципов балансировки нагрузки внутреннего/внешнего HTTPS.
- Знание системы Private Service Connect
2. Прежде чем начать
Примечание: В Codelab представлены шаги по настройке и проверке на основе представленной топологии; при необходимости измените процедуру в соответствии с требованиями вашей организации. Права доступа IAM не входят в область действия Codelab.
В Codelab для моделирования всего процесса будет использоваться один проект. Поддерживается также использование нескольких проектов.
Отдельный проект - Обновление проекта для поддержки сети производителей и потребителей.
Внутри Cloud Shell убедитесь, что идентификатор вашего проекта указан правильно.
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] prodproject=YOUR-PROJECT-NAME echo $prodproject
3. Создание локальных ресурсов
В следующем разделе мы настроим локальную VPC и виртуальные машины для имитации работы локальных сервисов клиента.
Сеть VPC
Из Cloud Shell
gcloud compute networks create vpc-demo-onprem --project=$prodproject --subnet-mode=custom
Создать подсеть
Из Cloud Shell
gcloud compute networks subnets create vpc-demo-onprem-asia-southeast1 --project=$prodproject --range=10.0.0.0/24 --network=vpc-demo-onprem --region=asia-southeast1
Создайте правила брандмауэра.
Внутренний балансировщик нагрузки HTTPS поддерживает распределенную проверку работоспособности, правила брандмауэра должны разрешать только диапазон IP-адресов подсети прокси. Для добавления проектов в список разрешенных используйте документацию .
В Cloud Shell создайте правило брандмауэра, разрешающее проверку работоспособности бэкэнда и передачу данных из подсетей прокси-сервера.
gcloud compute firewall-rules create vpc-demo-health-checks --allow tcp:80,tcp:443 --network vpc-demo-onprem --source-ranges 10.0.3.0/24 --enable-logging
В Cloud Shell создайте правило брандмауэра, разрешающее IAP подключаться к вашим экземплярам виртуальных машин.
gcloud compute firewall-rules create psclab-iap-prod --network vpc-demo-onprem --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging
4. Создание локальных экземпляров виртуальных машин.
Эта виртуальная машина имитирует локальные сервисы и должна быть доступна через внутренний балансировщик нагрузки HTTPS с использованием гибридной архитектуры NEG.
В оболочке Cloud Shell создайте экземпляр www01
gcloud compute instances create www01 \
--zone=asia-southeast1-b \
--image-family=debian-11 \
--image-project=debian-cloud \
--network-interface=network-tier=PREMIUM,nic-type=GVNIC,stack-type=IPV4_ONLY,subnet=vpc-demo-onprem-asia-southeast1 \
--shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring \
--metadata=startup-script='#! /bin/bash
sudo apt-get update
sudo apt-get install nginx -y
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
filter="{print \$NF}"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone \
| awk -F/ "${filter}")"
echo "Page on $vm_hostname in $vm_zone" | \
tee /var/www/html/index.nginx-debian.html
sudo systemctl restart nginx'
В следующем разделе мы будем использовать Let's Encrypt для генерации сертификатов и их установки на Nginx. Для следующего шага загрузите файлы открытого и закрытого ключей. Для генерации сертификата необходимо временно открыть TCP-порт 80 для доступа из интернета.
Убедитесь, что у этой виртуальной машины есть общедоступное доменное имя. Например, в Cloud DNS добавьте запись A [www01.yinghli.demo.altostrat.com](http://www01.yinghli.demo.altostrat.com) и укажите на публичный IP-адрес виртуальной машины.
gcloud dns --project=$prodproject record-sets create www01.yinghli.demo.altostrat.com. --zone="yinghli-demo" --type="A" --ttl="300" --rrdatas="34.87.77.186"
В консоли виртуальной машины www01 следуйте инструкциям по установке сертификатов на Nginx и создайте копии файлов fullchain.pem и private.pem для последующих шагов.
sudo apt install snapd sudo snap install core; sudo snap refresh core sudo snap install --classic certbot sudo ln -s /snap/bin/certbot /usr/bin/certbot sudo certbot --nginx
5. Создайте сеть VPC для производителей.
Примечание: Настройка гибридной сети НЕ включена в данную конфигурацию.
Сеть VPC
Из Cloud Shell
gcloud compute networks create vpc-demo-producer --project=$prodproject --subnet-mode=custom
Создать подсеть
Из Cloud Shell
gcloud compute networks subnets create vpc-demo-asia-southeast1 --project=$prodproject --range=10.0.2.0/24 --network=vpc-demo-producer --region=asia-southeast1
Создать прокси-подсеть
Из Cloud Shell
gcloud compute networks subnets create proxy-subnet-asia-southeast1 \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=asia-southeast1 \ --network=vpc-demo-producer \ --range=10.0.3.0/24
Гибридная связь
Для реализации высокоскоростного VPN-подключения между локальной сетью и VPC производителя следуйте документации Cloud VPN . Сохраните конфигурацию по умолчанию на облачном маршрутизаторе, нам не нужно добавлять 130.211.0.0/22, 35.191.0.0/16 в объявления BGP.
6. Создание гибридных производителей NEG
Создайте гибридную группу конечных точек сети и добавьте IP-адрес и порт локальной виртуальной машины в группу конечных точек сети.
Из Cloud Shell
gcloud compute network-endpoint-groups create on-prem-service-neg \
--network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
--zone=asia-southeast1-b \
--network=vpc-demo-producer
gcloud compute network-endpoint-groups update on-prem-service-neg \
--zone=asia-southeast1-b \
--add-endpoint="ip=10.0.0.2,port=443"
7. Создайте внутренний балансировщик нагрузки HTTPS для производителей.
В настоящее время внешний балансировщик нагрузки HTTPS поддерживает протокол HTTPS только для PSC NEG ( документация ). При публикации сервисов необходимо использовать внутренний балансировщик нагрузки HTTPS и включить правила переадресации для глобального доступа.
Создайте региональную проверку работоспособности в Cloud Shell.
gcloud compute health-checks create https on-prem-service-hc \
--region=asia-southeast1 \
--use-serving-port
В Cloud Shell создайте серверную службу и добавьте Hybrid NEG.
gcloud compute backend-services create on-premise-service-backend \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTPS \ --region=asia-southeast1 \ --health-checks=on-prem-service-hc \ --health-checks-region=asia-southeast1 gcloud compute backend-services add-backend on-premise-service-backend \ --network-endpoint-group=on-prem-service-neg \ --network-endpoint-group-zone=asia-southeast1-b \ --region=asia-southeast1 \ --balancing-mode=RATE \ --max-rate-per-endpoint=100
Создайте карту URL-адресов в Cloud Shell.
gcloud compute url-maps create on-premise-url \
--default-service on-premise-service-backend \
--region=asia-southeast1
В Cloud Shell создаются региональные SSL-сертификаты. Два файла сертификатов загружаются с виртуальной машины.
gcloud compute ssl-certificates create www01 \
--certificate=fullchain.pem \
--private-key=private.pem \
--region=asia-southeast1
В Cloud Shell создайте https-target-proxy
gcloud compute target-https-proxies create on-premise-httpsproxy \
--ssl-certificates=www01 \
--url-map=on-premise-url \
--url-map-region=asia-southeast1 \
--region=asia-southeast1
В Cloud Shell зарезервируйте внутренний статический IP-адрес и создайте правило переадресации.
gcloud compute addresses create ilbaddress \
--region=asia-southeast1 \
--subnet=vpc-demo-asia-southeast1 \
--addresses=10.0.2.100
gcloud compute forwarding-rules create https-ilb-psc \
--load-balancing-scheme=INTERNAL_MANAGED \
--network=vpc-demo-producer \
--subnet=vpc-demo-asia-southeast1 \
--address=ilbaddress \
--ports=443 \
--region=asia-southeast1 \
--target-https-proxy=on-premise-httpsproxy \
--target-https-proxy-region=asia-southeast1
--allow-global-access
8. Создайте экземпляр виртуальной машины производителя.
Создайте виртуальную машину-производителя для проверки.
Из Cloud Shell
gcloud compute instances create test01 \
--zone=asia-southeast1-b \
--image-family=debian-11 \
--image-project=debian-cloud \
--network-interface=network-tier=PREMIUM,nic-type=GVNIC,stack-type=IPV4_ONLY,subnet=vpc-demo-asia-southeast1 \
--shielded-secure-boot \
--shielded-vtpm \
--shielded-integrity-monitoring
Чтобы разрешить IAP подключаться к вашим виртуальным машинам, создайте правило брандмауэра, которое:
Из Cloud Shell
gcloud compute firewall-rules create psclab-iap-prod --network vpc-demo-producer --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging
С консоли виртуальной машины производителя перейдите по адресу [ www01.yinghli.demo.altostrat.com ](https://www01.yinghli.demo.altostrat.com) и определите внутренний IP-адрес балансировщика нагрузки HTTPS. Код HTTP 200 подтвердил, что конфигурация прошла успешно.
curl -v --resolve www01.yinghli.demo.altostrat.com:443:10.0.2.100 https://www01.yinghli.demo.altostrat.com * Added www01.yinghli.demo.altostrat.com:443:10.0.2.100 to DNS cache * Hostname www01.yinghli.demo.altostrat.com was found in DNS cache * Trying 10.0.2.100:443... * Connected to www01.yinghli.demo.altostrat.com (10.0.2.100) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=www01.yinghli.demo.altostrat.com * start date: Jun 4 10:36:43 2023 GMT * expire date: Sep 2 10:36:42 2023 GMT * subjectAltName: host "www01.yinghli.demo.altostrat.com" matched cert's "www01.yinghli.demo.altostrat.com" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x55865ef982e0) > GET / HTTP/2 > Host: www01.yinghli.demo.altostrat.com > user-agent: curl/7.74.0 > accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * Connection state changed (MAX_CONCURRENT_STREAMS == 100)! < HTTP/2 200 < server: nginx/1.18.0 < date: Mon, 05 Jun 2023 02:29:38 GMT < content-type: text/html < content-length: 35 < last-modified: Sun, 04 Jun 2023 09:02:16 GMT < etag: "647c5318-23" < accept-ranges: bytes < via: 1.1 google < Page on www01 in asia-southeast1-b * Connection #0 to host www01.yinghli.demo.altostrat.com left intact
Примечание: Вы не можете получить прямой доступ к службам HTTPS виртуальной машины 10.0.0.2, поскольку локальный брандмауэр разрешает доступ только к подсети прокси 10.0.3.0/24.
9. Создайте подсеть NAT для PSC.
Из Cloud Shell
gcloud compute networks subnets create psc-nat-subnet \ --network=vpc-demo-producer \ --region=asia-southeast1 \ --range=10.0.5.0/24 \ --purpose=private-service-connect
10. Создайте HTTPS-подключение к сервису.
Создайте в Cloud Shell HTTPS-подключение к сервису.
gcloud compute service-attachments create ilbserviceattach \ --region=asia-southeast1 \ --producer-forwarding-rule=https-ilb-psc \ --connection-preference=ACCEPT_AUTOMATIC \ --nat-subnets=psc-nat-subnet
Проверьте подключение HTTPS-сервиса.
gcloud compute service-attachments describe ilbserviceattach --region asia-southeast1
Название вложения службы записи:
projects/<project>/regions/asia-southeast1/serviceAttachments/ilbserviceattach
11. Создайте сеть VPC для потребителей.
В следующем разделе потребительская VPC настраивается в том же проекте, но поддерживаются и разные проекты. Связь между потребительской и производственной сетями осуществляется посредством подключения сервиса, определенного в производственной сети.
Сеть VPC
Из Cloud Shell
gcloud compute networks create vpc-demo-consumer --project=$prodproject --subnet-mode=custom
Создать подсеть
Из Cloud Shell
gcloud compute networks subnets create consumer-subnet --project=$prodproject --range=10.0.6.0/24 --network=vpc-demo-consumer --region=asia-southeast1
12. Создайте группу сетевых конечных точек PSC.
Создать PSC NEG
Скопируйте имя вложения предыдущей службы HTTPS и вставьте его в параметры --psc-target-service
Из Cloud Shell
gcloud beta compute network-endpoint-groups create consumerpscneg \ --project=$prodproject \ --region=asia-southeast1 \ --network-endpoint-type=PRIVATE_SERVICE_CONNECT \ --psc-target-service=projects/<project>/regions/asia-southeast1/serviceAttachments/ilbserviceattach \ --network=vpc-demo-consumer \ --subnet=consumer-subnet
После успешной настройки PSC NEG, в пользовательском интерфейсе, в разделе Private Service Connect -> Published Services -> обратите внимание, что опубликованное соединение ilbserviceattach теперь указывает на 1 правило пересылки.

13. Создайте внешний балансировщик нагрузки HTTPS для потребителя.
Создайте внешний балансировщик нагрузки HTTPS и используйте PSC NEG в качестве бэкэнд-сервисов ( документация ).
Из Cloud Shell
gcloud compute addresses create httpspsclb \
--ip-version=IPV4 --global
gcloud compute backend-services create consumer-bs \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTPS \
--global
gcloud compute backend-services add-backend consumer-bs \
--network-endpoint-group=consumerpscneg \
--network-endpoint-group-region=asia-southeast1 \
--global
gcloud compute url-maps create consumer-url \
--default-service=consumer-backend-service \
--global
gcloud compute ssl-certificates create wwwglobal \
--certificate=fullchain.pem \
--private-key=private.pem \
--global
gcloud compute target-https-proxies create consumer-url-target-proxy \
--url-map=consumer-url \
--ssl-certificates=wwwglobal
gcloud compute forwarding-rules create consumer-url-forwarding-rule \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network-tier=PREMIUM \
--address=httpspsclb \
--target-https-proxy=consumer-url-target-proxy \
--ports=443 \
--global
Обновите DNS-запись для www01.yinghli.demo.altostrat.com и укажите публичный IP-адрес внешнего балансировщика нагрузки HTTPS.
gcloud dns --project=$prodproject record-sets update www01.yinghli.demo.altostrat.com. --type="A" --zone="yinghli-demo" --rrdatas="34.102.178.214" --ttl="300"
14. Валидация
С вашего ноутбука зайдите на сайт https://www01.yinghli.demo.altostrat.com , используя команду curl.
curl -v https://www01.yinghli.demo.altostrat.com * Trying 34.102.178.214:443... * Connected to www01.yinghli.demo.altostrat.com (34.102.178.214) port 443 (#0) * ALPN: offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN: server accepted h2 * Server certificate: * subject: CN=www01.yinghli.demo.altostrat.com * start date: Jun 4 10:36:43 2023 GMT * expire date: Sep 2 10:36:42 2023 GMT * subjectAltName: host "www01.yinghli.demo.altostrat.com" matched cert's "www01.yinghli.demo.altostrat.com" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * using HTTP/2 * h2h3 [:method: GET] * h2h3 [:path: /] * h2h3 [:scheme: https] * h2h3 [:authority: www01.yinghli.demo.altostrat.com] * h2h3 [user-agent: curl/8.0.0] * h2h3 [accept: */*] * Using Stream ID: 1 (easy handle 0x149019a00) > GET / HTTP/2 > Host: www01.yinghli.demo.altostrat.com > user-agent: curl/8.0.0 > accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing < HTTP/2 200 < server: nginx/1.18.0 < date: Mon, 05 Jun 2023 02:48:43 GMT < content-type: text/html < content-length: 35 < last-modified: Sun, 04 Jun 2023 09:02:16 GMT < etag: "647c5318-23" < accept-ranges: bytes < via: 1.1 google, 1.1 google < alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 < Page on www01 in asia-southeast1-b * Connection #0 to host www01.yinghli.demo.altostrat.com left intact
15. Этапы очистки
этапы очистки сети производителей
Примечание: На этапах очистки отображаются только конфигурации, относящиеся к балансировщику нагрузки и PSC; конфигурации VPC и гибридного подключения не включены.
Из единой облачной оболочки в терминале удалите компоненты лаборатории.
gcloud compute forwarding-rules delete consumer-url-forwarding-rule --global gcloud compute target-https-proxies delete consumer-url-target-proxy gcloud compute ssl-certificates delete wwwglobal --global gcloud compute url-maps delete consumer-url gcloud compute backend-services delete consumer-bs --global gcloud compute addresses delete httpspsclb --global gcloud beta compute network-endpoint-groups delete consumerpscneg --region=asia-southeast1 gcloud compute service-attachments delete ilbserviceattach --region=asia-southeast1 gcloud compute networks subnets delete psc-nat-subnet --region=asia-southeast1 gcloud compute forwarding-rules delete https-ilb-psc --region=asia-southeast1 gcloud compute addresses delete ilbaddress --region=asia-southeast1 gcloud compute target-https-proxies delete on-premise-httpsproxy --region=asia-southeast1 gcloud compute ssl-certificates delete www01 --region=asia-southeast1 gcloud compute url-maps delete on-premise-url --region=asia-southeast1 gcloud compute backend-services delete on-premise-service-backend --region=asia-southeast1 gcloud compute health-checks delete on-prem-service-hc --region=asia-southeast1 gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=asia-southeast1-b gcloud compute networks subnets delete proxy-subnet-asia-southeast1 --region=asia-southeast1
16. Поздравляем!
Поздравляем с завершением практического занятия!
Что мы рассмотрели
- Внутренний балансировщик нагрузки HTTPS с гибридной NEG и распределенной проверкой работоспособности.
- Подключение сервиса PSC с внутренним балансировщиком нагрузки HTTPS
- Настройка группы конечных точек сети PSC
- Обеспечьте доступ к PSC NEG через внешний балансировщик нагрузки HTTPS.