1. Введение
Балансировка нагрузки Google Cloud развернута на периферии сети Google в точках присутствия (POP) Google по всему миру. Пользовательский трафик, направляемый на балансировщик нагрузки TCP Proxy, поступает в ближайшую к пользователю точку присутствия, а затем распределяется по глобальной сети Google на ближайший бэкэнд, обладающий достаточной пропускной способностью.
Cloud Armor — это система обнаружения атак типа «отказ в обслуживании» и межсетевой экран веб-приложений (WAF) от Google. Cloud Armor тесно связан с балансировщиком нагрузки TCP-прокси Google Cloud и позволяет проверять входящий трафик на наличие нежелательных запросов. Функция ограничения скорости позволяет ограничивать трафик к ресурсам бэкэнда в зависимости от объема запросов и предотвращает потребление ресурсов вашей виртуальной частной сети (VPC) нежелательным трафиком.
Балансировщики нагрузки Google Cloud TCP/SSL-прокси позволяют перенаправлять трафик типа TCP/SSL между вашими бэкэнд-сервисами.
В этом практическом задании вы создадите балансировщик нагрузки на основе TCP/SSL-прокси с бэкэнд-сервисом и используете Cloud Armor для ограничения доступа к балансировщику нагрузки только для определенного набора пользовательских клиентов.

Что вы узнаете
- Как создать балансировщик нагрузки TCP/SSL-прокси
- Как создать политику безопасности Cloud Armor
- Как создать правило запрета IP-адресов для балансировщика нагрузки TCP/SSL-прокси в Cloud Armor
- Как создать правило ограничения скорости для балансировщика нагрузки TCP-прокси в Cloud Armor
- Как добавить политику безопасности в службу балансировки нагрузки TCP/SSL
Что вам понадобится
- Базовые знания Google Compute Engine ( практический урок ).
- Базовые знания сетевых технологий и протокола TCP/IP.
- Базовые знания командной строки Unix/Linux.
- Полезно предварительно ознакомиться с основами работы с сетями в GCP, в частности, с разделом «Сетевые возможности в Google Cloud».
2. Требования
Настройка среды для самостоятельного обучения
- Войдите в Cloud Console и создайте новый проект или используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .
Примечание: Вы можете легко получить доступ к Cloud Console, запомнив ее URL-адрес: console.cloud.google.com.



Запомните идентификатор проекта (Project ID) — уникальное имя для всех проектов Google Cloud (указанное выше имя уже занято и вам не подойдёт, извините!). В дальнейшем в этом практическом занятии оно будет обозначаться как PROJECT_ID.
Примечание: Если вы используете учетную запись Gmail, вы можете оставить значение по умолчанию «Без организации». Если вы используете учетную запись Google Workspace, выберите местоположение, подходящее для вашей организации.
- Далее вам потребуется включить оплату в Cloud Console, чтобы использовать ресурсы Google Cloud.
Выполнение этого практического задания не должно стоить дорого, если вообще что-либо. Обязательно следуйте инструкциям в разделе «Очистка», где указано, как отключить ресурсы, чтобы избежать дополнительных расходов после завершения этого урока. Новые пользователи Google Cloud имеют право на бесплатную пробную версию стоимостью 300 долларов США .
Запустить Cloud Shell
Хотя Google Cloud можно управлять удаленно с ноутбука, в этом практическом занятии вы будете использовать Google Cloud Shell — среду командной строки, работающую в облаке.
В консоли GCP щелкните значок Cloud Shell на панели инструментов в правом верхнем углу:

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

Эта виртуальная машина оснащена всеми необходимыми инструментами разработки. Она предоставляет постоянный домашний каталог размером 5 ГБ и работает в облаке Google, что значительно повышает производительность сети и аутентификацию. Всю работу в этой лаборатории можно выполнять с помощью обычного браузера.
Прежде чем начать
Внутри Cloud Shell убедитесь, что идентификатор вашего проекта указан правильно.
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] PROJECT_ID=[YOUR-PROJECT-NAME] echo $PROJECT_ID
Включить API
Включите все необходимые службы
gcloud services enable compute.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable monitoring.googleapis.com
3. Создайте серверные службы.
Создайте 2 экземпляра следующим образом: создайте экземпляр instance1-b1 в зоне us-central1-b.
gcloud compute instances create vm-1-b1 \
--image-family debian-9 \
--image-project debian-cloud \
--tags tcp-lb \
--zone us-central1-b \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
sudo service apache2 restart
echo '<!doctype html><html><body><h1>This is VM1-b1 in central1-b</h1></body></html>' | tee /var/www/html/index.html
EOF"
Создайте экземпляр 1-b2 в зоне us-central1-b
gcloud compute instances create vm-1-b2 \
--image-family debian-9 \
--image-project debian-cloud \
--tags tcp-lb \
--zone us-central1-b \
--metadata startup-script="#! /bin/bash
sudo apt-get update
sudo apt-get install apache2 -y
sudo sed -i '/Listen 80/c\Listen 110' /etc/apache2/ports.conf
sudo service apache2 restart
echo '<!doctype html><html><body><h1>This is VM1-b2 in central1-b</h1></body></html>' | tee /var/www/html/index.html
EOF"
Создайте группу экземпляров vm-ig1
gcloud compute instance-groups unmanaged create vm-ig1 --zone us-central1-b
Создайте именованный порт для группы экземпляров. В этой лабораторной работе мы будем использовать порт 110.
gcloud compute instance-groups set-named-ports vm-ig1 \ --named-ports tcp 110:110 --zone us-central1-b
Добавьте экземпляры в группу экземпляров.
gcloud compute instance-groups unmanaged add-instances vm-ig1 \ --instances vm-1-b1,vm-1-b2 --zone us-central1-b
4. Настройка балансировщика нагрузки
Далее мы создадим проверку состояния здоровья.
gcloud compute health-checks create tcp my-tcp-health-check --port 110
Создайте серверную службу
gcloud compute backend-services create my-tcp-lb --global-health-checks --global \ --protocol TCP --health-checks my-tcp-health-check --timeout 5m --port-name tcp110
Добавьте группу экземпляров в службу бэкэнда.
gcloud compute backend-services add-backend my-tcp-lb --global --instance-group \ vm-ig1 --instance-group-zone us-central1-b --balancing-mode UTILIZATION \ --max-utilization 0.8
Настройте целевой TCP-прокси.
gcloud compute target-tcp-proxies create my-tcp-lb-target-proxy --backend-service \ my-tcp-lb --proxy-header NONE
Зарезервировать глобальные статические IPv4-адреса
Этот IP-адрес будет использоваться для доступа к сервису балансировки нагрузки.
gcloud compute addresses create tcp-lb-static-ipv4 --ip-version=IPV4 --global
Настройте глобальные правила пересылки для IP-адреса балансировщика нагрузки.
gcloud compute forwarding-rules create my-tcp-lb-ipv4-forwarding-rule \
--global --target-tcp-proxy my-tcp-lb-target-proxy --address LB_STATIC_IPV4 \ --ports 110
5. Создание правила брандмауэра для балансировщика нагрузки TCP-прокси.
gcloud compute firewall-rules create allow-tcplb-and-health \ --source-ranges 130.211.0.0/22,35.191.0.0/16 \ --target-tags tcp-lb \ --allow tcp:110
После создания балансировщика нагрузки протестируйте его с помощью следующей команды.
Curl LB_IP:110
Далее создайте виртуальные машины для проверки отказов в доступе к балансировщику нагрузки.
Вам следует создать 2 экземпляра, каждый с публичным IP-адресом и именами test-server1 и test-server2.
6. Создайте политику безопасности в Cloud Armor.
В этом разделе вы создадите политику безопасности для бэкэнда и 2 правила в этой политике в Cloud Armor.
Первое правило запретит доступ к балансировщику нагрузки TCP ограниченному числу IP-адресов, установив политику безопасности, запрещающую доступ определенным IP-адресам, а второе правило выполнит ограничение скорости запросов.
- В Cloud Shell (инструкции по использованию Cloud Shell см. в разделе «Запуск Cloud Shell» в подразделе «Настройка и требования») создайте политику безопасности для серверной службы с именем rate-limit-and-deny-tcp следующим образом:
gcloud compute security-policies create rate-limit-and-deny-tcp \
--description "policy for tcp proxy rate limiting and IP deny"
Добавить правила в политику безопасности
Далее добавьте правило списка запрещенных действий в политику Cloud Armor "rate-limit-and-deny-tcp".
gcloud compute security-policies rules create 1000 --action deny --security-policy \ rate-limit-and-deny-tcp --description "deny test-server1" --src-ip-ranges \ "enter-test-server-1ip-here"
Добавьте правило ограничения скорости в политику безопасности Cloud Armor "rate-limit-and-deny-tcp".
gcloud compute security-policies rules create 3000 \ --security-policy=rate-limit-and-deny-tcp \ --expression="true" --action=rate-based-ban --rate-limit-threshold-count=5 \ --rate-limit-threshold-interval-sec=60 --ban-duration-sec=300 \ --conform-action=allow --exceed-action=deny-404 --enforce-on-key=IP
Прикрепить политику к серверной службе TCP-прокси:
Выполните следующую команду, чтобы убедиться, что политика безопасности применена к службе бэкэнда TCP-прокси.
gcloud compute backend-services update my-tcp-lb --security-policy \ rate-limit-and-deny-tcp
Включить логирование на балансировщике нагрузки TCP-прокси
gcloud beta compute backend-services update my-tcp-lb \ --enable-logging --logging-sample-rate=1
7. Проверка правила списка запрещенных действий.
Проверьте правильность правила «Запрещенный список», войдя на тестовый сервер, IP-адрес которого был указан в правиле, и выполните следующую команду.
Curl LB_IP:110
При немедленных запросах балансировщик нагрузки может дать ответ, но лучше подождать, пока запрос curl не будет отклонен или отброшен, а затем посмотреть журналы в Cloud Logging, чтобы проверить запись в журнале о срабатывании правила запрета IP-адресов.
Перейдите в раздел Cloud Logging и в подразделе ресурсов выберите тип ресурса "tcp_ssl_proxy_rule" и установите целевой бэкэнд как "my-tcp-lb".
Используя ресурсы, определенные для фильтрации, мы можем убедиться, что правило запрета IP-адресов действует, проверив значение PRIORITY, равное 1000, в записи журнала, а также что настроенное действие "ЗАПРЕТИТЬ" выполняется, поскольку оба действия были предписаны правилом запрета и IP-адресом, который был запрещен, как показано ниже.

8. Проверьте правило ограничения скорости.
Убедитесь, что правило ограничения скорости запросов действует, отправив множество запросов за короткий промежуток времени, превышающий установленный порог (5 запросов в минуту).
После этого нажмите кнопку «Просмотреть журналы» в службе Cloud Armor, и вы перейдете в раздел «Облачное логирование», где сможете отфильтровать журналы по балансировщику нагрузки, чтобы просматривать журналы Cloud Armor по мере их поступления.
Запись об ограничении скорости должна соответствовать скриншоту ниже. Мы можем убедиться в том, что правило ограничения скорости действует, по значению PRIORITY , равному 3000, в записи журнала, а также по настроенному действию "RATE BASED BAN" , которое действует в соответствии с указаниями правила ограничения скорости.

9. Очистка окружающей среды
Обязательно очистите созданную инфраструктуру, чтобы избежать эксплуатационных расходов на неиспользуемую инфраструктуру.
Самый быстрый способ — удалить весь проект в GCP, чтобы убедиться, что не осталось незадействованных ресурсов. Однако удалить отдельные ресурсы можно с помощью следующих команд.
Балансировщик нагрузки TCP-прокси
gcloud compute target-tcp-proxies delete my-tcp-lb
Группа экземпляров
gcloud compute instance-groups unmanaged delete vm-ig1
Были созданы 2 тестовых экземпляра виртуальных машин.
gcloud compute instances delete Instance_name --zone=instance_zone
бэкэнд-сервис
gcloud compute backend-services delete BACKEND_SERVICE_NAME
Правила «Облачной брони» включены в политику.
gcloud compute security-policies rules delete 1000 \ --security-policy=rate-limit-and-deny-tcp && gcloud compute security-policies rules delete 3000 \ --security-policy=rate-limit-and-deny-tcp
Политика безопасности «Облачной брони»
gcloud compute security-policies delete rate-limit-and-deny-tcp