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

1. Введение

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

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

Что вы построите

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

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

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

• Как создать балансировщик нагрузки TCP-прокси (ILB) с использованием службы Hybrid NEG в качестве бэкэнда.
• Как установить связь между производителем (приложением к услуге) и потребителем (правилом пересылки) частного сервисного соединения
• Как тестировать и проверять качество коммуникации между потребителем и производителем в сфере услуг

Примечание: Данная практическая работа посвящена реализации балансировки нагрузки TCP-прокси с использованием PSC. Настройка гибридной сети не документирована, хотя предоставлены сопроводительная документация и скриншоты.

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

• Устоявшиеся гибридные сети, например, HA VPN, Interconnect, SW-WAN.
• Проект Google Cloud

Создать гибридную связь

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

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

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

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

• Документация по облачному VPN
• Документация по взаимосвязи облачных сервисов

Реклама маршрутов по заказу

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

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

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

Обновите проект, чтобы он поддерживал практическое занятие.

В этом практическом занятии используется переменная `$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-адрес и порт в гибридную среду 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 forwarding-rules create .

Замените 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 перейдите в раздел «Сетевые службы» → «Балансировка нагрузки» → «Балансировщики нагрузки». Обратите внимание, что значение 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, чтобы проверить подключение к локальной службе, выполнив команду curl к IP-адресу балансировщика нагрузки. Повторите попытку, если произойдет таймаут.

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

Выполните команду curl для проверки подключения к локальной службе. После проверки выйдите из виртуальной машины и вернитесь в командную строку 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. (Необязательно): Перейдите в раздел «Сетевые службы» → «Подключение к частной службе», чтобы просмотреть недавно созданное подключение к службе.

Выбор Service-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 Private Service Connect) - VPC потребителя

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

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

11. Проверка подключения частного сервиса потребителя к платному сервису производителя (VPC).

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

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

Создайте частную DNS-зону, сопоставленную с конечной точкой подключения PSC, обеспечивающую беспрепятственный доступ к Producer с любого хоста в пределах 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 создайте тестовый экземпляр в VPC потребителя.

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 создайте тестовый экземпляр в VPC потребителя.

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

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

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

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

Внутри Cloud Shell выполнить команду curl

$ 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. Поздравляем!

Поздравляем, вы успешно настроили и проверили соединение частной службы с TCP-прокси.

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

Что дальше?

Посмотрите некоторые из этих практических занятий по программированию...

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

Дополнительная литература и видеоматериалы

• Обзор Private Service Connect
• Что такое Private Service Connect?

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

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