Подключайтесь к локальным службам через гибридную сеть с помощью Private Service Connect и гибридного TCP-прокси NEG.

1. Введение

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

Если вы хотите сделать гибридную службу доступной в других сетях VPC, вы можете использовать Private Service Connect для публикации службы . Разместив вложение службы перед внутренним региональным балансировщиком нагрузки TCP-прокси, вы можете позволить клиентам в других сетях VPC получать доступ к гибридным службам, работающим в локальных или других облачных средах.

Что ты построишь

В этой лабораторной работе вы собираетесь создать внутренний балансировщик нагрузки TCP-прокси с гибридным подключением к локальной службе с использованием группы конечных точек сети. Из потребителя VPC сможет взаимодействовать с локальным сервисом.

Примечание. Codelab предлагает этапы настройки и проверки на основе иллюстрированной топологии. При необходимости измените процедуру в соответствии с требованиями вашей организации. Разрешения IAM не входят в область действия лаборатории кода.

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

• Как создать TCP-прокси-ILB с гибридной внутренней службой NEG
• Как установить производителя Private Service Connect (приложение службы) и потребителя (правило пересылки)
• Как протестировать и проверить связь между сервисами между потребителем и производителем

Примечание. В этой кодовой лаборатории основное внимание уделяется реализации ILB TCP-прокси с помощью PSC. Конфигурация гибридной сети не документирована, хотя предоставляется подтверждающая документация и снимки экрана.

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

• Установленная гибридная сеть, например HA VPN, Interconnect, SW-WAN.
• Облачный проект Google

Установите гибридное соединение

Ваше облако Google Cloud и локальные или другие облачные среды должны быть соединены посредством гибридного подключения с использованием либо подключений Cloud Interconnect VLAN, либо туннелей Cloud VPN с Cloud Router. Мы рекомендуем использовать соединение высокой доступности.

Облачный маршрутизатор с поддержкой глобальной динамической маршрутизации узнает о конкретной конечной точке через BGP и программирует ее в вашей сети Google Cloud VPC. Региональная динамическая маршрутизация не поддерживается. Статические маршруты также не поддерживаются.

Сеть Google Cloud VPC, которую вы используете для настройки Cloud Interconnect или Cloud VPN, — это та же сеть, которую вы используете для настройки гибридного развертывания балансировки нагрузки. Убедитесь, что диапазоны CIDR подсети вашей сети VPC не конфликтуют с вашими удаленными диапазонами CIDR. Когда IP-адреса перекрываются, маршруты подсети имеют приоритет над удаленным подключением.

Инструкции см.:

• Документация по облачному VPN
• Документация Cloud Interconnect

Рекламные объявления настраиваемых маршрутов

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

Подсеть	Описание
172.16.0.0/23	Подсеть TCP-прокси, используемая для прямого взаимодействия с локальной службой.
130.211.0.0/22, 35.191.0.0/16	Проверка работоспособности облака Google

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

Обновите проект для поддержки лаборатории кода.

В этом Codelab используются переменные $variables для облегчения реализации конфигурации gcloud в Cloud Shell.

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

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. Настройка продюсера

Создайте VPC-производитель

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

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

Создайте подсети производителя

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

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

Создайте подсети TCP-прокси.

Распределение прокси осуществляется на уровне VPC, а не на уровне балансировщика нагрузки. Вы должны создать одну подсеть только для прокси-сервера в каждом регионе виртуальной сети (VPC), в которой вы используете балансировщики нагрузки на основе Envoy. Если вы развертываете несколько балансировщиков нагрузки в одном регионе и одной сети VPC, они используют одну и ту же подсеть только для прокси-сервера для балансировки нагрузки.

1. Клиент устанавливает соединение с IP-адресом и портом правила переадресации балансировщика нагрузки.
2. Каждый прокси-сервер прослушивает IP-адрес и порт, указанные в правиле переадресации соответствующего балансировщика нагрузки. Один из прокси получает и разрывает сетевое соединение клиента.
3. Прокси-сервер устанавливает соединение с соответствующей серверной виртуальной машиной или конечной точкой в ​​NEG, как это определено картой URL-адресов балансировщика нагрузки и серверными службами.

Вы должны создавать подсети только для прокси-серверов независимо от того, работает ли ваша сеть в автоматическом режиме или настраиваемая. Подсеть только для прокси-сервера должна предоставлять 64 или более IP-адресов. Это соответствует длине префикса /26 или короче. Рекомендуемый размер подсети — /23 (512 адресов только для прокси).

Примечание. Для прокси-подсети требуется локальное объявление BGP клиента, поэтому его можно маршрутизировать в вашу локальную сеть, а доступ к услуге возможен через предоставленную подсеть прокси-сервера.

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

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

Создайте подсети NAT Private Service Connect.

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

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

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

Создайте правила брандмауэра производителя

Настройте правила брандмауэра , чтобы разрешить трафик между конечными точками Private Service Connect и вложением службы. В лаборатории кода создано правило входящего брандмауэра, разрешающее подсети NAT 100.100.10.0/24 доступ к приложению службы Private Service Connect (внутреннему балансировщику нагрузки).

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

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

Внутри Cloud Shell Создайте правило fw-allow-health-check, чтобы разрешить проверкам работоспособности Google Cloud достигать локальной службы (внутренней службы) через TCP-порт 80.

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

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

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

Настройка гибридного подключения NEG

При создании NEG используйте ЗОНУ, которая минимизирует географическое расстояние между Google Cloud и вашей локальной или другой облачной средой. Например, если вы размещаете службу в локальной среде во Франкфурте, Германия, вы можете указать зону Google Cloud Europe-west3-a при создании NEG.

Более того, если вы используете Cloud Interconnect, ЗОНА, используемая для создания NEG, должна находиться в том же регионе, где было настроено подключение Cloud Interconnect.

Доступные регионы и зоны см. в документации Compute Engine: Доступные регионы и зоны .

Внутри Cloud Shell создайте NEG гибридного подключения с помощью команды gcloud Compute network-endpoint-groups create.

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

Внутри Cloud Shell добавьте локальную конечную точку IP:Port в гибридный NEG.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

Настройте балансировщик нагрузки

На следующих шагах вы настроите балансировщик нагрузки (правило переадресации) и свяжете его с группой конечных точек сети.

Внутри Cloud Shell создайте региональную проверку работоспособности, передаваемую в локальную службу.

gcloud compute health-checks create tcp on-prem-service-hc \
    --region=us-central1 \
    --use-serving-port

Внутри Cloud Shell создайте серверную службу для локальной серверной части.

gcloud compute backend-services create on-premise-service-backend \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --protocol=TCP \
   --region=us-central1 \
   --health-checks=on-prem-service-hc \
   --health-checks-region=us-central1

Внутри Cloud Shell добавьте гибридную серверную часть NEG к серверной службе. В поле MAX_CONNECTIONS введите максимальное количество одновременных подключений, которые должна обрабатывать серверная часть.

gcloud compute backend-services add-backend on-premise-service-backend \
   --network-endpoint-group=on-prem-service-neg \
   --network-endpoint-group-zone=us-central1-a \
   --region=us-central1 \
   --balancing-mode=CONNECTION \
   --max-connections=100

Внутри Cloud Shell создайте целевой прокси.

gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
   --backend-service=on-premise-service-backend \
   --region=us-central1

В Cloud Shell создайте правило переадресации (ILB).

Создайте правило переадресации с помощью команды создания правил пересылки gcloud Compute .

Замените FWD_RULE_PORT одним номером порта от 1 до 65535. Правило пересылки пересылает только пакеты с соответствующим портом назначения.

gcloud compute forwarding-rules create tcp-ilb-psc \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --network=producer-vpc \
   --subnet=subnet-201 \
   --ports=80 \
   --region=us-central1 \
   --target-tcp-proxy=on-premise-svc-tcpproxy \
   --target-tcp-proxy-region=us-central1

Получите IP-адрес внутреннего балансировщика нагрузки.

gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:

Example output:
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
IPAddress: 10.10.1.2

4. Проверка балансировщика нагрузки

В Cloud Console перейдите в «Сетевые службы» → «Балансировка нагрузки» → «Балансировщики нагрузки». Обратите внимание, что 1 NEG имеет зеленый цвет, что указывает на успешную проверку работоспособности локальной службы.

Выбор «on-premise-service-backend» дает внешний IP-адрес.

5. Просмотр изученных маршрутов локально.

Перейдите в Сеть VPC → Маршруты . Обратите внимание: изученная подсеть локального сервиса 192.168.1.0/27.

6. Проверка подключения к локальной службе.

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

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

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

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

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

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

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Войдите в test-box-us-central1 с помощью IAP в Cloud Shell, чтобы проверить подключение к локальной службе, выполнив завивку по IP-адресу балансировки нагрузки. Повторите попытку, если истекло время ожидания.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

Выполните завивку, проверяющую подключение к локальной службе. После подтверждения выйдите из виртуальной машины и вернитесь к приглашению Cloud Shell. Замените IP-адрес внутреннего балансировщика нагрузки на основе результатов, определенных на шагах 3 и 4.

deepakmichael@test-box-us-central1:~$ curl -v 10.10.1.2
* Expire in 0 ms for 6 (transfer 0x55b9a6b2f0f0)
*   Trying 10.10.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a6b2f0f0)
* Connected to 10.10.1.2 (10.10.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:42:38 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:42:38 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

7. Создайте вложение службы Private Service Connect.

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

Создайте вложение службы

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

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

Необязательно: при использовании общего VPC создайте вложение службы в проекте службы.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

Проверьте вложение службы TCP

gcloud compute service-attachments describe service-1 --region us-central1

8. Необязательно: перейдите в «Сетевые службы» → «Подключение частной службы», чтобы просмотреть вновь созданное вложение службы.

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

Сведения о вложении службы: projects/<projectname>/regions/us-central1/serviceAttachments/service-1.

9. Настройка потребителя

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

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

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

Создайте потребительские подсети

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

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

Внутри Cloud Shell создайте подсеть потребительской конечной точки.

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

Создайте конечную точку потребителя (правило пересылки)

Внутри Cloud Shell создайте статический IP-адрес, который будет использоваться в качестве конечной точки потребителя.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

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

Внутри Cloud Shell создайте потребительскую конечную точку.

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

10. Проверка подключения к частному сервису потребителя — Consumer VPC

В потребительском VPC проверьте успешное подключение частной службы, перейдя в раздел «Сетевые службы» → «Подключение частной службы» → «Подключенные конечные точки» . Обратите внимание на установленное соединение psc-consumer-1 и соответствующий IP-адрес, который мы создали ранее.

При выборе psc-consumer-1 предоставляются дополнительные сведения, включая URI вложения службы.

11. Проверка подключения потребительского частного сервиса — поставщика VPC

В VPC-источнике проверьте успешное подключение частной службы, перейдя в раздел «Сетевые службы» → «Подключение частной службы» → «Опубликованная служба». Обратите внимание, что опубликованное соединение службы-1 теперь указывает 1 правило переадресации (конечная точка соединения).

12. Создайте частную зону DNS и запись

Создайте частную зону DNS, сопоставленную с конечной точкой подключения PSC, обеспечивающую беспрепятственный доступ к источнику с любого хоста в VPC.

Примечание. Доступ к конечной точке потребителя через пиринг VPC не поддерживается.

Из Cloud Shell

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

13. Проверка доступа потребителя к службе производителей с помощью виртуальной машины.

В потребительском VPC мы создадим виртуальную машину для проверки подключения к локальной службе, обратившись к конечной точке потребителя service1.codelabs.net.

Внутри Cloud Shell создайте тестовый экземпляр в потребительском виртуальном компьютере.

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

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

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

Внутри Cloud Shell создайте тестовый экземпляр в потребительском виртуальном компьютере.

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Войдите в потребительскую виртуальную машину с помощью IAP в Cloud Shell, чтобы проверить подключение к локальной службе, выполнив завивку полного доменного имени DNS service1.codelab.net. Повторите попытку, если истекло время ожидания.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

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

Внутри Cloud Shell выполните скручивание

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

Ниже приведен пример захвата данных из локальной службы. Обратите внимание, что исходный IP-адрес 172.16.0.2 находится в диапазоне подсети TCP-прокси 172.16.0.0/23.

14. Уборка продюсера

Удалить компоненты производителя

Внутри Cloud Shell удалите компоненты производителя.

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete tcp-ilb-psc --region=us-central1 --quiet

gcloud compute target-tcp-proxies delete on-premise-svc-tcpproxy --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete on-prem-service-hc --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

15. Уборка потребителей

Удалить потребительские компоненты

Внутри Cloud Shell удалите потребительские компоненты.

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet 

16. Поздравления

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

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

Что дальше?

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

• Использование Private Service для публикации и использования сервисов с помощью GKE
• Использование Private Service Connect для публикации и использования сервисов

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

• Обзор частного сервиса Connect
• Что такое подключение к частному сервису?

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

• Внутренний TCP-прокси
• Обзор проверок работоспособности
• Как опубликовать услугу