Эта страница переведена с помощью Cloud Translation API.

Основы облачных межсетевых экранов нового поколения для балансировщиков нагрузки

1. Введение

В этом практическом занятии рассматриваются основы работы с межсетевыми экранами нового поколения (NGFW) в облаке для внутренних балансировщиков нагрузки приложений (ALB) и прокси-сетевых балансировщиков нагрузки (NLB) с использованием региональных политик сетевого межсетевого экрана .

Cloud NGFW — это полностью распределенная служба межсетевого экрана с расширенными возможностями защиты от угроз и микросегментации для защиты рабочих нагрузок Google Cloud. Включение Cloud NGFW на уровне балансировщика нагрузки применяет согласованные правила политики межсетевого экрана ко всему TCP- трафику, поступающему на внутренние балансировщики нагрузки на основе прокси-серверов. Это упрощает обеспечение безопасности организации, предлагая более широкое применение политик для всех служб.

В данном практическом занятии рассматриваются следующие продукты и функции облачных межсетевых экранов нового поколения (NGFW) и облачных балансировщиков нагрузки:

Основы облачного NGFW
Региональные политики сетевого брандмауэра
Региональный внутренний балансировщик нагрузки приложений
Группа управляемых экземпляров бэкэнда (MIG) и группа сетевых конечных точек Private Service Connect (PSC) (NEG)

ПРИМЕЧАНИЕ: Для получения информации о последних поддерживаемых функциях и ограничениях правил политики брандмауэра для целевых объектов балансировщика нагрузки обратитесь к документации Cloud NFGW.

Чему вы научитесь

Включение базовых правил политики межсетевого экрана Cloud NGFW, нацеленных на балансировщики нагрузки.
Защита внутреннего сервиса балансировки нагрузки потребителя с помощью экземпляров виртуальных машин и бэкэндов PSC.
Проверка доступа клиентов и сверка журналов брандмауэра.

Что вам нужно

Проект Google Cloud
Знание сетевых концепций Google Cloud и умение пользоваться интерфейсом командной строки Google Cloud.
Права доступа IAM: roles/compute.instanceAdmin.v1 , roles/compute.networkAdmin , roles/compute.securityAdmin и roles/storage.admin

2. Понятия

Уровни функциональности брандмауэра

Облачный межсетевой экран нового поколения (NGFW) имеет три уровня функциональности : Essentials, Standard и Enterprise. Каждый последующий уровень предлагает дополнительные возможности фильтрации и анализа сетевого трафика.

Краткое описание возможностей фильтрации Cloud NGFW Essentials :

Уровень	Возможности	Сетевые уровни	Пример параметров правила
Основные сведения	Фильтрация IP-адресов и диапазонов	IP	`--src-ip-ranges=1.1.1.0/24,2.2.2.2/32`
Основные сведения	Адресные группы	IP	`--src-address-groups=special-ranges`
Основные сведения	Фильтрация по протоколам и портам	TCP	`--layer4-configs=tcp`
Основные сведения	Защищенные метки	Метаданные	`--src-secure-tags=tagValues/987654321098`
Основные сведения	Фильтрация по типу сети	IP-адрес / метаданные	`--src-network-type=INTRA_VPC`

Правила переадресации балансировщика нагрузки явно определяют целевой TCP-порт. Параметр --layer4-configs= правила брандмауэра может указывать только tcp . Значение порта подразумевается самим правилом переадресации.

Группы адресов и типы сетей могут быть полезны для повышения эффективности правил политики брандмауэра. Типы сетей VPC_NETWORKS и INTRA_VPC поддерживаются правилами политики брандмауэра для балансировщиков нагрузки.

ПРИМЕЧАНИЕ: Правила политики брандмауэра для балансировщиков нагрузки поддерживают только --direction=INGRESS . Эти правила предназначены для управления доступом к сервисам, предоставляемым балансировщиком нагрузки.

Фильтрация плоскости данных

Функционал Cloud NFGW Essentials охватывает основные правила межсетевого экрана с отслеживанием состояния на уровне 3 (IP-адрес) и уровне 4 (TCP-порт). Все эти функции правил политики межсетевого экрана эффективно выполняются в плоскости данных балансировщика нагрузки без необходимости полного анализа пакетов.

Правила политики Cloud NGFW Essentials , ориентированные на экземпляры виртуальных машин, применяются в распределенной сетевой инфраструктуре VPC как часть основной программно-определяемой сети Google Cloud ( Andromeda ). Правила фильтрации пакетов и политики межсетевого экрана применяются на уровне гипервизора каждого отдельного экземпляра виртуальной машины, прежде чем пакет достигнет сетевого интерфейса экземпляра виртуальной машины.

Правила политики Cloud NGFW Essentials , ориентированные на балансировщики нагрузки, применяются с использованием базовых технологий балансировщиков нагрузки Google Cloud , а именно инфраструктуры прокси-сервера Envoy. Используя ту же модель ресурсов Cloud NFGW и структуру правил, фильтрация пакетов с сохранением состояния осуществляется непосредственно в плоскости данных балансировщика нагрузки на основе прокси-сервера.

Целевые значения балансировщика нагрузки

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

Правила политики брандмауэра можно применять к одному балансировщику нагрузки, указав --target-type=INTERNAL_MANAGED_LB вместе с конкретной ссылкой на правило пересылки балансировщика нагрузки --target-forwarding-rules= FR_NAME . Чтобы применить правила пересылки ко всем балансировщикам нагрузки в сетевом регионе VPC (где регион ограничен политикой), конкретную ссылку следует опустить, и необходим только флаг --target-type=INTERNAL_MANAGED_LB .

Если параметр --target-type не задан в конфигурации правила, то правило по умолчанию автоматически применяется ко всем экземплярам виртуальных машин , а не к балансировщикам нагрузки.

ПРИМЕЧАНИЕ: Поведение правила политики брандмауэра по умолчанию для балансировщиков нагрузки — action=allow . Это обычное поведение для внутренних балансировщиков нагрузки без подключенных политик брандмауэра. Однако это также относится к балансировщикам нагрузки с подключенными политиками брандмауэра, когда пакеты не соответствуют ни одному из определенных правил. Чтобы изменить это поведение по умолчанию, настройте явное правило «запретить все» с более низким приоритетом (более высоким номером приоритета) в качестве правила для обработки всех пакетов.

Сеть Codelab

В этом практическом занятии используется один проект с одной сетью VPC и следующими ресурсами:

Две региональные подсети
Одна региональная политика межсетевого экрана сети
Три региональных внутренних балансировщика нагрузки приложений
- Сервис www HTTP с бэкэндом группы экземпляров виртуальных машин
- api HTTP-сервис с бэкэндом для групп экземпляров виртуальных машин
- Сервис gcs HTTPS с бэкэндом PSC NEG для доступа к API Google
Два экземпляра виртуальных машин для тестирования различных политик разрешения и запрета.

рисунок1

Рис. 1. Сеть Codelab

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

рисунок 2

Рис. 1. Облачный NFGW для ресурсов балансировщика нагрузки.

Фильтры Cloud NGFW Essentials программируются в плоскость данных балансировщика нагрузки и реализуются на определенном уровне целевого прокси-сервиса — аналогично интерфейсу экземпляра виртуальной машины — с использованием тех же распределенных и согласованных механизмов межсетевого экрана для обеспечения соблюдения политик.

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

Получите доступ к своему проекту

В этом практическом занятии используется один проект Google Cloud. Шаги настройки выполняются с помощью команд командной строки gcloud cli и команд оболочки Linux.

Для начала откройте командную строку вашего проекта Google Cloud:

Cloud Shell доступен по адресу shell.cloud.google.com или
Локальный терминал с установленным интерфейсом командной строки gcloud

Укажите идентификатор вашего проекта.

gcloud config set project YOUR_PROJECT_ID_HERE

Включить API-сервисы

gcloud services enable \
  cloudresourcemanager.googleapis.com \
  compute.googleapis.com \
  dns.googleapis.com \
  networksecurity.googleapis.com \
  certificatemanager.googleapis.com

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

# set your region preference
export REGION_1="us-west1"

# set your zone preference
export ZONE_1="us-west1-c"

# fetch project info and verify vars set
export PROJECT_ID=$(gcloud config list --format="value(core.project)")
export PROJECT_NO=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")
echo ${REGION_1}
echo ${ZONE_1}
echo ${PROJECT_ID}
echo ${PROJECT_NO}

4. Основа сети

В этом разделе вы развернете сетевую основу, включающую в себя:

Глобальная сеть VPC и региональные подсети
Региональная политика сетевого брандмауэра для защиты сети VPC.
Облачный маршрутизатор и облачный NAT для серверов, позволяющие загружать программные пакеты.
Резервирование IP-адресов и DNS-записи для входящего трафика балансировщика нагрузки

Создание сетевых ресурсов

# create vpc network
gcloud compute networks create vnet-foo --subnet-mode=custom

# create subnet for clients
gcloud compute networks subnets create subnet-foo-1 \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=10.0.0.0/24 \
  --enable-private-ip-google-access

# create subnet for backend servers
gcloud compute networks subnets create subnet-foo-2 \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=172.16.0.0/24 \
  --enable-private-ip-google-access

# create proxy subnet
gcloud compute networks subnets create subnet-foo-3 \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --network=vnet-foo \
  --region=${REGION_1} \
  --range=172.16.128.0/23

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

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

Создать группу адресов

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

# create address group
gcloud network-security address-groups create uhc-probes \
  --description="health check probes" \
  --type=IPv4 \
  --capacity=42 \
  --location=${REGION_1}

# add ip ranges to address group
gcloud network-security address-groups add-items uhc-probes \
  --items=35.191.0.0/16,130.211.0.0/22 \
  --location=${REGION_1}

Создать политику брандмауэра

# create fw policy
gcloud compute network-firewall-policies create fw-policy-foo-${REGION_1} \
  --description="foo fw ${REGION_1}" \
  --region=${REGION_1}

# create fw policy rule to allow in iap
gcloud compute network-firewall-policies rules create 1001 \
  --description="allow iap for ssh" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:22 \
  --src-ip-ranges=35.235.240.0/20

# create fw policy rule to allow in health checks
gcloud compute network-firewall-policies rules create 1002 \
  --description="allow health checks to backends" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes

# create fw policy rule to allow in lb proxies
gcloud compute network-firewall-policies rules create 1003 \
  --description="allow lb proxy" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp:80,tcp:443,tcp:8080 \
  --src-ip-ranges=172.16.128.0/23

# associate fw policy to vnet
gcloud compute network-firewall-policies associations create \
  --name=fw-policy-association-foo-${REGION_1} \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --network=vnet-foo \
  --firewall-policy-region=${REGION_1}

Настройка сетевых служб

Создание облачного маршрутизатора и NAT-шлюза

# create router for nat
gcloud compute routers create cr-nat-foo \
  --network=vnet-foo \
  --asn=16550 \
  --region=${REGION_1}

# create nat gateway
gcloud compute routers nats create natgw-foo \
  --router=cr-nat-foo \
  --region=${REGION_1} \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges

Зарезервировать IP-адреса

# reserve vip for lb www service
gcloud compute addresses create vip-foo-www \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.101

# reserve vip for lb api service
gcloud compute addresses create vip-foo-api \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.102

# reserve vip for lb gcs service
gcloud compute addresses create vip-foo-gcs \
  --region=${REGION_1} \
  --subnet=subnet-foo-1 \
  --addresses=10.0.0.103

Создание DNS-записей

# create dns zone
gcloud dns managed-zones create zone-foo \
  --description="private zone for foo" \
  --dns-name=foo.com \
  --networks=vnet-foo \
  --visibility=private

# create dns record for www service
gcloud dns record-sets create www.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.101"

# create dns record for api service
gcloud dns record-sets create api.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.102"

# create dns record for gcs service
gcloud dns record-sets create gcs.foo.com \
  --zone=zone-foo \
  --type=A \
  --ttl=300 \
  --rrdatas="10.0.0.103"

На этом завершается этап настройки сети... далее переходим к настройке балансировщиков нагрузки.

5. Услуги балансировки нагрузки

В этом разделе вы развернете компоненты балансировки нагрузки (бэкэнд-сервисы, карты URL-адресов, целевые прокси и правила переадресации) для трех сервисов:

Сервис www ( ilb-foo-www ) на порту 80
api сервис ( ilb-foo-api ) на порту 8080
Сервис gcs ( ilb-foo-gcs ) на порту 443 с TLS-сертификатом.

Вместе с вспомогательными ресурсами серверной части:

Экземпляры виртуальных машин, на которых запущены HTTP-серверы, входят в управляемую группу экземпляров.
Группа сетевых конечных точек Private Service Connect (PSC) (NEG) для подключения к API Google
Корзина Google Cloud Storage (GCS)

Настройка ресурсов бэкэнда

Создайте группу серверов экземпляров виртуальных машин.

Балансировщик нагрузки www будет использовать серверы бэкэнда группы экземпляров виртуальных машин, на которых запущен веб-сервер Apache, прослушивающий порт 80 .

Балансировщик нагрузки api будет использовать ту же группу экземпляров виртуальных машин, прослушивающих порт 8080 .

# create vm startup config with http server
cat > vm-server-startup.sh << 'OEOF'
#! /bin/bash
set -e
apt-get update
apt-get install apache2 -y
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/name)"
vm_zone="$(curl -H "Metadata-Flavor:Google" \
http://169.254.169.254/computeMetadata/v1/instance/zone | cut -d/ -f4)"
echo "www served from: $vm_hostname in zone $vm_zone on port 80" | \
tee /var/www/html/index.html
echo "Listen 8080" | tee -a /etc/apache2/ports.conf
mkdir -p /var/www/api
echo "api served from: $vm_hostname in zone $vm_zone on port 8080" | \
tee /var/www/api/index.html
tee /etc/apache2/sites-available/api.conf << EOF
<VirtualHost *:8080>
    DocumentRoot /var/www/api
</VirtualHost>
EOF
a2ensite api.conf
systemctl restart apache2
OEOF

# create managed instance group template
gcloud compute instance-templates create mig-template-foo \
  --machine-type=e2-micro \
  --network=vnet-foo \
  --region=${REGION_1} \
  --subnet=subnet-foo-2 \
  --no-address \
  --shielded-secure-boot \
  --metadata-from-file=startup-script=vm-server-startup.sh

# create regional managed instance group
gcloud compute instance-groups managed create mig-foo \
  --region=${REGION_1} \
  --size=2 \
  --template=mig-template-foo \
  --base-instance-name=service-foo

# create named ports for instance group
gcloud compute instance-groups managed set-named-ports mig-foo \
  --named-ports=www-port:80,api-port:8080 \
  --region=${REGION_1}

Создать хранилище

Балансировщик нагрузки gcs будет использовать бэкэнд PSC NEG для подключения через интерфейс Google API к хранилищу Cloud Storage.

# create random bucket name
export BUCKET=$(openssl rand -hex 12)
echo ${BUCKET}

ПРИМЕЧАНИЕ: После закрытия сеанса командной оболочки переменные среды теряются. Запишите имя корзины, если оно понадобится для завершения работы в будущем сеансе.

# create bucket
gcloud storage buckets create gs://${BUCKET} --location=${REGION_1}

# give compute sa object admin role on bucket
gcloud storage buckets add-iam-policy-binding gs://${BUCKET} \
  --member=serviceAccount:${PROJECT_NO}-compute@developer.gserviceaccount.com \
  --role=roles/storage.objectAdmin

Создать сертификат

Балансировщик нагрузки gcs будет завершать HTTPS-запросы клиентов с помощью самоподписанного сертификата, развернутого на целевом HTTPS-прокси.

# create cert
openssl req -x509 -newkey rsa:2048 \
  -nodes \
  -days 365 \
  -keyout foo-gcs-key.pem \
  -out foo-gcs-cert.pem \
  -subj "/CN=Foo, Inc." \
  -addext "subjectAltName=DNS:gcs.foo.com"

# upload to certificate manager
gcloud certificate-manager certificates create cert-foo-gcs \
  --private-key-file=foo-gcs-key.pem \
  --certificate-file=foo-gcs-cert.pem \
  --location=${REGION_1}

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

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

Развернуть скрипт создания балансировщика нагрузки

# create script file
cat > create_lbs.sh << EOF
#!/bin/bash
set -e

# --- Create load balancer for www service port 80 ---
echo "--- Creating Load Balancer for WWW Service (ilb-foo-www) on port 80 ---"

echo "ilb-foo-www: creating health check (hc-foo-www)"
gcloud compute health-checks create http hc-foo-www \
  --use-serving-port \
  --region=${REGION_1}

echo "ilb-foo-www: creating backend service (bes-foo-www)"
gcloud compute backend-services create bes-foo-www \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --port-name=www-port \
  --health-checks=hc-foo-www \
  --health-checks-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: adding managed instance group (mig-foo) to backend service (bes-foo-www)"
gcloud compute backend-services add-backend bes-foo-www \
  --balancing-mode=UTILIZATION \
  --instance-group=mig-foo \
  --instance-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: creating url map (ilb-foo-www)"
gcloud compute url-maps create ilb-foo-www \
  --default-service=bes-foo-www \
  --region=${REGION_1}

echo "ilb-foo-www: creating target http proxy (proxy-foo-www)"
gcloud compute target-http-proxies create proxy-foo-www \
  --url-map=ilb-foo-www \
  --url-map-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-www: creating forwarding rule (fr-foo-www)"
gcloud compute forwarding-rules create fr-foo-www \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-www \
  --ports=80 \
  --target-http-proxy=proxy-foo-www \
  --target-http-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for WWW Service (ilb-foo-www) ---"
echo

# --- Create load balancer for api service port 8080 ---
echo "--- Creating Load Balancer for API Service (ilb-foo-api) on port 8080 ---"

echo "ilb-foo-api: creating health check (hc-foo-api)"
gcloud compute health-checks create http hc-foo-api \
  --use-serving-port \
  --region=${REGION_1}

echo "ilb-foo-api: creating backend service (bes-foo-api)"
gcloud compute backend-services create bes-foo-api \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTP \
  --port-name=api-port \
  --health-checks=hc-foo-api \
  --health-checks-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: adding managed instance group (mig-foo) to backend service (bes-foo-api)"
gcloud compute backend-services add-backend bes-foo-api \
  --balancing-mode=UTILIZATION \
  --instance-group=mig-foo \
  --instance-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: creating url map (ilb-foo-api)"
gcloud compute url-maps create ilb-foo-api \
  --default-service=bes-foo-api \
  --region=${REGION_1}

echo "ilb-foo-api: creating target http proxy (proxy-foo-api)"
gcloud compute target-http-proxies create proxy-foo-api \
  --url-map=ilb-foo-api \
  --url-map-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-api: creating forwarding rule (fr-foo-api)"
gcloud compute forwarding-rules create fr-foo-api \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-api \
  --ports=8080 \
  --target-http-proxy=proxy-foo-api \
  --target-http-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for API Service (ilb-foo-api) ---"
echo

# --- Create load balancer for gcs service port 443 ---
echo "--- Creating Load Balancer for GCS Service (ilb-foo-gcs) on port 443 ---"

echo "ilb-foo-gcs: creating network endpoint group (neg-psc-gcs)"
gcloud compute network-endpoint-groups create neg-psc-gcs \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=storage.${REGION_1}.rep.googleapis.com \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating backend service (bes-foo-gcs)"
gcloud compute backend-services create bes-foo-gcs \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --protocol=HTTPS \
  --region=${REGION_1}

echo "ilb-foo-gcs: adding network endpoint group (neg-psc-gcs) to backend service (bes-foo-gcs)"
gcloud compute backend-services add-backend bes-foo-gcs \
  --network-endpoint-group=neg-psc-gcs \
  --network-endpoint-group-region=${REGION_1} \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating url map (ilb-foo-gcs)"
gcloud compute url-maps create ilb-foo-gcs \
  --default-service=bes-foo-gcs \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating target https proxy (proxy-foo-gcs)"
gcloud compute target-https-proxies create proxy-foo-gcs \
  --url-map=ilb-foo-gcs \
  --url-map-region=${REGION_1} \
  --certificate-manager-certificates=cert-foo-gcs \
  --region=${REGION_1}

echo "ilb-foo-gcs: creating forwarding rule (fr-foo-gcs)"
gcloud compute forwarding-rules create fr-foo-gcs \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=vnet-foo \
  --subnet=subnet-foo-1 \
  --subnet-region=${REGION_1} \
  --address=vip-foo-gcs \
  --ports=443 \
  --target-https-proxy=proxy-foo-gcs \
  --target-https-proxy-region=${REGION_1} \
  --region=${REGION_1}

echo "--- Successfully created Load Balancer for GCS Service (ilb-foo-gcs) ---"
echo

echo "All load balancers created successfully."
EOF

# make script executable
chmod +x create_lbs.sh

# run script
./create_lbs.sh

Примечание: выполнение этого скрипта занимает несколько минут.

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

Проверьте, развернуты ли правила пересылки и серверные службы.

# check forwarding rules
gcloud compute forwarding-rules list

# check backend services
gcloud compute backend-services list

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

6. Доступ клиента

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

В этом разделе вы развернете клиенты и проверите сквозное соединение.

Создание экземпляров виртуальных машин

# set variables for client ip addresses
export VM_ALLOW_IP="10.0.0.11"
export VM_DENY_IP="10.0.0.12"
echo ${VM_ALLOW_IP}
echo ${VM_DENY_IP}

# create client 1 vm
gcloud compute instances create vm-allow \
  --machine-type=e2-micro \
  --zone=${ZONE_1} \
  --subnet=subnet-foo-1 \
  --no-address \
  --private-network-ip=${VM_ALLOW_IP} \
  --scopes=cloud-platform \
  --shielded-secure-boot

# create client 2 vm
gcloud compute instances create vm-deny \
  --machine-type=e2-micro \
  --zone=${ZONE_1} \
  --subnet=subnet-foo-1 \
  --no-address \
  --private-network-ip=${VM_DENY_IP} \
  --scopes=cloud-platform \
  --shielded-secure-boot

Тестирование базового сервиса

Тестирование с клиентской `vm-allow`

ПРИМЕЧАНИЕ: Экземпляры виртуальных машин будут подключены к сети и станут доступны по ssh с использованием IAP вскоре после выполнения команд instances create . Возможно, вам потребуется немного подождать, если запрос не удастся выполнить с первой попытки.

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

Протестируйте загрузку файла в Google Cloud Storage через балансировщик нагрузки.

# send request to foo gcs service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  echo 'test one on the way' > test-upload-1.txt
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k -X POST \"https://gcs.foo.com/upload/storage/v1/b/${BUCKET}/o?uploadType=media&name=test-upload-object-1.txt\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -H \"Content-Type: text/plain\" \
  --data-binary @test-upload-1.txt"

Ответ API облачного хранилища подтверждает корректную работу сетевого пути.

Тестирование с клиентской виртуальной машины `vm-deny`

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

# send request to foo gcs service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  echo 'test two on the way' > test-upload-2.txt
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k -X POST \"https://gcs.foo.com/upload/storage/v1/b/${BUCKET}/o?uploadType=media&name=test-upload-object-2.txt\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -H \"Content-Type: text/plain\" \
  --data-binary @test-upload-2.txt"

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

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

7. Межсетевой экран балансировщика нагрузки

В этом разделе вы развернете правила политики брандмауэра, ориентированные на балансировщики нагрузки. Последовательность настроек позволит создать систему безопасности, которая разрешает доступ vm-allow и блокирует трафик, vm-deny для всех служб.

Разрешить выборочный трафик для `fr-foo-www`

Добавьте новое правило политики брандмауэра к существующей политике брандмауэра fw-policy-foo-${REGION_1}

Разрешить диапазон исходных IP-адресов, включающий IP-адреса из списка vm-allow и исключающий IP-адреса vm-deny
Добавьте дополнительный фильтр источника INTRA_VPC , чтобы использовать тип сети в правиле политики брандмауэра, нацеленном на балансировщик нагрузки.

Типы исходной сети INTRA_VPC и VPC_NETWORKS поддерживаются в правилах политик брандмауэра, ориентированных на балансировщики нагрузки, при использовании в сочетании с другим параметром источника. Логика оценки представляет собой операцию AND между двумя параметрами источника. В данном случае трафик должен соответствовать критериям для INTRA_VPC и --src-ip-ranges=${VM_ALLOW_IP}/32 чтобы быть разрешенным.

Создайте правило, разрешающее целевую аудиторию `vm-allow` `fr-foo-www`

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2001 \
  --description="allow vm traffic to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-network-type=INTRA_VPC \
  --src-ip-ranges=${VM_ALLOW_IP}/32 \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

Тестирование с клиентской `vm-allow`

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

Тестирование с клиентской виртуальной машины `vm-deny`

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

ПРИМЕЧАНИЕ: Это работает, потому что неявное поведение правила политики брандмауэра по умолчанию для балансировщиков нагрузки --action=allow . Для изменения этого необходимо правило запрета по умолчанию ( catchall ).

Запретить трафик по умолчанию для `fr-foo-www`

Добавьте новое правило политики брандмауэра с более низким приоритетом (более высоким номером приоритета).

Запретить весь трафик с любого IP-адреса.
Трафик с vm-allow на fr-foo-www будет разрешен до срабатывания правила запрета.

Создайте правило для запрета трафика, нацеленного `fr-foo-www`

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2999 \
  --description="allow vm traffic to fr-www" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=deny \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-ip-ranges=0.0.0.0/0 \
  --target-type=INTERNAL_MANAGED_LB \
  --target-forwarding-rules=projects/${PROJECT_ID}/regions/${REGION_1}/forwardingRules/fr-foo-www

Тестирование с клиентской виртуальной машины `vm-deny`

# send request to foo www service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s www.foo.com"

Теперь это должно не сработать, поскольку правило брандмауэра 2999 запрещает весь трафик, исходящий из сети VPC. Правило 2001 с более высоким приоритетом (более низким номером приоритета) разрешало только диапазон источников, включающий vm-allow .

Остановите процесс curl , нажав Ctrl+C .

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

vm-deny по-прежнему может получить доступ к API-сервису! Это удалось, потому что правило брандмауэра было применено только к правилу переадресации fr-foo-www и не затрагивало fr-foo-api .

Обновите правила, чтобы они применялись ко всем балансировщикам нагрузки.

ПРИМЕЧАНИЕ: Правила политики брандмауэра можно применять ко всем балансировщикам нагрузки в сети VPC, опустив --target-forwarding-rules= FR_NAME .

Измените правила политики брандмауэра таким образом, чтобы они применялись ко всем целевым объектам правил пересылки балансировщика нагрузки в сети VPC.

Создайте новое правило разрешения входящего трафика 2003 которое будет применяться ко всем правилам пересылки для разрешения трафика виртуальных машин (диапазон IP-адресов vm-allow ).
Создайте новое правило разрешения входящего трафика 2004 нацеленное на все правила пересылки, чтобы разрешить трафик проверок работоспособности (группа адресов uhc-probes ).
Создайте новое правило запрета входящего трафика 2998 нацеленное на все правила переадресации как правило запрета для всего остального трафика.

Измените правила брандмауэра, чтобы они применялись ко всем балансировщикам нагрузки.

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2003 \
  --description="allow vm traffic to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp  \
  --src-ip-ranges=${VM_ALLOW_IP}/32 \
  --target-type=INTERNAL_MANAGED_LB

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2004 \
  --description="allow health checks to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=allow \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-address-groups=projects/${PROJECT_ID}/locations/${REGION_1}/addressGroups/uhc-probes \
  --target-type=INTERNAL_MANAGED_LB

# create fw policy rule
gcloud beta compute network-firewall-policies rules create 2998 \
  --description="deny all vnet traffic to all vnet lb fr" \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1} \
  --enable-logging \
  --action=deny \
  --direction=INGRESS \
  --layer4-configs=tcp \
  --src-ip-ranges=0.0.0.0/0 \
  --target-type=INTERNAL_MANAGED_LB

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

# delete redundant fw policy rules
gcloud beta compute network-firewall-policies rules delete 2001 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud beta compute network-firewall-policies rules delete 2002 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud beta compute network-firewall-policies rules delete 2999 \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

Тестирование с клиентской виртуальной машины `vm-deny`

# send request to foo api service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

Теперь это должно завершиться неудачей, поскольку fr-foo-api также является целью всех правил политики брандмауэра с --target-type=INTERNAL_MANAGED_LB .

Остановите процесс curl , нажав Ctrl+C .

Протестируйте загрузку файла из Google Cloud Storage через балансировщик нагрузки.

# send request to foo gcs service
gcloud compute ssh vm-deny --zone=${ZONE_1} --command="
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k \"https://gcs.foo.com/storage/v1/b/${BUCKET}/o/test-upload-object.txt?alt=media\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -o test-download.txt"

Остановите процесс curl , нажав Ctrl+C .

Тестирование с клиентской `vm-allow`

# send request to foo www service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s www.foo.com"

# send request to foo api service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  curl -s api.foo.com:8080"

# send request to foo gcs service
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  TOKEN=\$(gcloud auth print-access-token)
  curl -s -k \"https://gcs.foo.com/storage/v1/b/${BUCKET}/o/test-upload-object-1.txt?alt=media\" \
  -H \"Authorization: Bearer \${TOKEN}\" \
  -o test-download-1.txt"

Проверьте содержимое загрузки.

# send request from vm
gcloud compute ssh vm-allow --zone=${ZONE_1} --command="
  cat test-download-1.txt"

Все службы балансировщика нагрузки доступны для vm-allow и успешно заблокированы для vm-deny .

На этом завершается тестирование... далее краткий обзор процесса ведения журналов.

8. Ведение журнала правил брандмауэра.

Формат журнала межсетевого экрана содержит поля и записи для правил, нацеленных на балансировщики нагрузки ( --target-type=INTERNAL_MANAGED_LB ).

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

load_balancer_details.forwarding_rule_name отображает целевое правило пересылки в политике брандмауэра.
load_balancer_details.type указывает, какой тип балансировщика нагрузки на основе прокси-сервера является целевым.
load_balancer_details.url_map_name регистрирует используемый ресурс карты URL-адресов, если тип — балансировщик нагрузки приложения.

Просмотреть журналы

Чтобы просмотреть результаты применения правил политики брандмауэра, запросите журналы брандмауэра.

gcloud logging read \
  "logName=projects/${PROJECT_ID}/logs/compute.googleapis.com%2Ffirewall \
  AND (jsonPayload.connection.src_ip=\"${VM_ALLOW_IP}\" OR jsonPayload.connection.src_ip=\"${VM_DENY_IP}\")" \
  --project=${PROJECT_ID} \
  --freshness=30m \
  --limit=50 \
  --format="table(
    timestamp:label=TIMESTAMP,
    jsonPayload.connection.src_ip:label=SRC_IP,
    jsonPayload.connection.src_port:label=SRC_PORT,
    jsonPayload.connection.dest_ip:label=DEST_IP,
    jsonPayload.connection.dest_port:label=DEST_PORT,
    jsonPayload.disposition:label=ACTION,
    jsonPayload.rule_details.priority:label=PRIORITY,
    jsonPayload.load_balancer_details.forwarding_rule_name:label=FWD_RULE
  )"

В журнале отображаются действующие правила, применяемые данной политикой:

Согласно правилу 2011 весь трафик vm-allow , ко всем балансировщикам нагрузки разрешен.
Согласно правилу 2998 весь трафик, предназначенный для балансировщиков нагрузки, блокируется.

TIMESTAMP                       SRC_IP     SRC_PORT  DEST_IP     DEST_PORT  ACTION   PRIORITY  FWD_RULE
YYYY-MM-DDTHH:MM:SS.850967068Z  10.0.0.11  48480     10.0.0.103  443        ALLOWED  2003      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.418613380Z  10.0.0.11  37340     10.0.0.101  80         ALLOWED  2003      fr-foo-www
YYYY-MM-DDTHH:MM:SS.213234118Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.981484412Z  10.0.0.11  41738     10.0.0.101  80         ALLOWED  2003      fr-foo-www
YYYY-MM-DDTHH:MM:SS.189358071Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.061463883Z  10.0.0.12  55950     10.0.0.103  443        DENIED   2998      fr-foo-gcs
YYYY-MM-DDTHH:MM:SS.965498098Z  10.0.0.12  53284     10.0.0.102  8080       DENIED   2998      fr-foo-api

Журналы также можно просмотреть в консоли Google Cloud с помощью Logs Explorer. Перейдите по адресу console.cloud.google.com/logs/query и используйте стандартный журнал брандмауэра VPC compute.googleapis.com/firewall .

logName=projects/${PROJECT_ID}/logs/compute.googleapis.com%2Ffirewall

На этом завершается этап регистрации данных... пора приступать к уборке!

9. Уборка

# delete client compute resources
gcloud -q compute instances delete vm-deny --zone=${ZONE_1}

gcloud -q compute instances delete vm-allow --zone=${ZONE_1}

# next

# delete load balancer resources for gcs
gcloud -q compute forwarding-rules delete fr-foo-gcs --region=${REGION_1}

gcloud -q compute target-https-proxies delete proxy-foo-gcs --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-gcs --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-gcs --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-gcs --region=${REGION_1}

# next

# delete load balancer resources for api
gcloud -q compute forwarding-rules delete fr-foo-api --region=${REGION_1}

gcloud -q compute target-http-proxies delete proxy-foo-api --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-api --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-api --region=${REGION_1}

gcloud -q compute health-checks delete hc-foo-api --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-api --region=${REGION_1}

# next

# delete load balancer resources for www
gcloud -q compute forwarding-rules delete fr-foo-www --region=${REGION_1}

gcloud -q compute target-http-proxies delete proxy-foo-www --region=${REGION_1}

gcloud -q compute url-maps delete ilb-foo-www --region=${REGION_1}

gcloud -q compute backend-services delete bes-foo-www --region=${REGION_1}

gcloud -q compute health-checks delete hc-foo-www --region=${REGION_1}

gcloud -q compute addresses delete vip-foo-www --region=${REGION_1}

# next

# delete service backend resources
gcloud -q storage rm --recursive gs://${BUCKET}

gcloud -q certificate-manager certificates delete cert-foo-gcs --location=${REGION_1}

gcloud -q compute network-endpoint-groups delete neg-psc-gcs --region=${REGION_1}

gcloud -q compute instance-groups managed delete mig-foo --region=${REGION_1}

gcloud -q compute instance-templates delete mig-template-foo --global

# next

# delete dns, nat, fw resources
gcloud -q dns record-sets delete gcs.foo.com --type=A --zone=zone-foo

gcloud -q dns record-sets delete api.foo.com --type=A --zone=zone-foo

gcloud -q dns record-sets delete www.foo.com --type=A --zone=zone-foo

gcloud -q dns managed-zones delete zone-foo

gcloud -q compute routers delete cr-nat-foo --region=${REGION_1}

gcloud -q compute network-firewall-policies associations delete \
  --firewall-policy=fw-policy-foo-${REGION_1} \
  --name=fw-policy-association-foo-${REGION_1} \
  --firewall-policy-region=${REGION_1}

gcloud -q compute network-firewall-policies delete fw-policy-foo-${REGION_1} --region=${REGION_1}

gcloud -q network-security address-groups delete uhc-probes --location=${REGION_1}

# next

# delete network resources
gcloud -q compute networks subnets delete subnet-foo-3 --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-foo-2 --region=${REGION_1}

gcloud -q compute networks subnets delete subnet-foo-1 --region=${REGION_1}

gcloud -q compute networks delete vnet-foo

# next

# delete shell variables and local files
unset PROJECT_ID REGION_1 ZONE_1 VM_ALLOW_IP VM_DENY_IP BUCKET

rm vm-server-startup.sh create_lbs.sh foo-gcs-key.pem foo-gcs-cert.pem

# end

10. Заключение

Поздравляем! Вы успешно настроили Cloud NGFW Essentials для балансировщиков нагрузки!

Пожалуйста, оставляйте свои комментарии, вопросы или замечания, используя эту форму обратной связи.

Спасибо!

Основы облачных межсетевых экранов нового поколения для балансировщиков нагрузки

1. Введение

Чему вы научитесь

Что вам нужно

2. Понятия

Уровни функциональности брандмауэра

Фильтрация плоскости данных

Целевые значения балансировщика нагрузки

Сеть Codelab

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

Получите доступ к своему проекту

Укажите идентификатор вашего проекта.

Включить API-сервисы

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

4. Основа сети

Создание сетевых ресурсов

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

Создать группу адресов

Создать политику брандмауэра

Настройка сетевых служб

Создание облачного маршрутизатора и NAT-шлюза

Зарезервировать IP-адреса

Создание DNS-записей

5. Услуги балансировки нагрузки

Настройка ресурсов бэкэнда

Создайте группу серверов экземпляров виртуальных машин.

Создать хранилище

Создать сертификат

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

Развернуть скрипт создания балансировщика нагрузки

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

6. Доступ клиента

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

Создание экземпляров виртуальных машин

Тестирование базового сервиса

Тестирование с клиентской vm-allow

Тестирование с клиентской виртуальной машины vm-deny

7. Межсетевой экран балансировщика нагрузки

Разрешить выборочный трафик для fr-foo-www

Создайте правило, разрешающее целевую аудиторию vm-allow fr-foo-www

Тестирование с клиентской vm-allow

Тестирование с клиентской виртуальной машины vm-deny

Запретить трафик по умолчанию для fr-foo-www

Создайте правило для запрета трафика, нацеленного fr-foo-www

Рекомендации по прохождению медицинского осмотра

Тестирование с клиентской виртуальной машины vm-deny

Обновите правила, чтобы они применялись ко всем балансировщикам нагрузки.

Измените правила брандмауэра, чтобы они применялись ко всем балансировщикам нагрузки.

Тестирование с клиентской виртуальной машины vm-deny

Тестирование с клиентской vm-allow

8. Ведение журнала правил брандмауэра.

Просмотреть журналы

9. Уборка

10. Заключение

Тестирование с клиентской `vm-allow`

Тестирование с клиентской виртуальной машины `vm-deny`

Разрешить выборочный трафик для `fr-foo-www`

Создайте правило, разрешающее целевую аудиторию `vm-allow` `fr-foo-www`

Тестирование с клиентской `vm-allow`

Тестирование с клиентской виртуальной машины `vm-deny`

Запретить трафик по умолчанию для `fr-foo-www`

Создайте правило для запрета трафика, нацеленного `fr-foo-www`

Тестирование с клиентской виртуальной машины `vm-deny`

Тестирование с клиентской виртуальной машины `vm-deny`

Тестирование с клиентской `vm-allow`