Маршруты на основе политик (PBR) Codelab

1. Введение

Маршруты, основанные на политике

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

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

• Вся сеть: все экземпляры виртуальных машин (ВМ), VPN-шлюзы и межсетевые соединения.
• Использование сетевых тегов: выберите экземпляры виртуальных машин в VPC.
• Регион межсетевого соединения: Весь трафик, поступающий в сеть VPC через VLAN-подключения для данного региона.

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

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

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

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

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

Для использования маршрутов на основе политик с Cloud Interconnect маршрут должен применяться ко всем соединениям Cloud Interconnect в пределах всего региона. Маршруты на основе политик нельзя применять только к отдельному соединению Cloud Interconnect.

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

Вопросы, касающиеся PBR

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

Например, использование PBR с GKE, PSC или с PGA/PSA.

Более подробную информацию о PBR с GKE можно найти здесь , а раздел об общих ограничениях PBR — здесь .

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

• Как настроить маршруты на основе политик

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

• Знание развертывания экземпляров и настройки сетевых компонентов.
• Знание конфигурации межсетевого экрана VPC

2. Тестовая среда

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

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

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

Для работы в Codelab требуется всего один проект.

Примечание : идентификатор организации можно получить с помощью консоли Cloud Console или gcloud projects get-ancestors [project-id] .

Примечание : Если вы уже работали с GCP и у вас установлен gcloud , он обновлен и авторизован для работы в вашем проекте, вы можете использовать свой локальный компьютер вместо Google Cloud Shell для выполнения этой лабораторной работы. Если не указано иное, все команды gcloud следует запускать с компьютера, на котором уже установлен gcloud или Cloud Shell.

Из Cloudshell:

export project_id=`gcloud config list --format="value(core.project)"`
export region=us-central1
export zone=us-central1-a
export prefix=codelab-pbr

4. Включите API.

Если это еще не сделано, включите API для использования продуктов.

Из Cloudshell:

gcloud services enable compute.googleapis.com
gcloud services enable networkconnectivity.googleapis.com

5. Создайте сеть и подсеть VPC.

Примечание : Убедитесь, что API Compute Engine включен. Если при выполнении приведенных ниже команд вы получаете сообщение об ошибке или не уверены, выполните команду gcloud services enable compute.googleapis.com и попробуйте снова.

Сеть VPC

Создайте VPC codelab-pbr-vpc:

Из Cloudshell:

gcloud compute networks create $prefix-vpc --subnet-mode=custom 

Подсеть

Создайте соответствующие подсети в выбранном регионе:

Из Cloudshell:

gcloud compute networks subnets create $prefix-vpc-subnet \
   --range=10.10.10.0/24 --network=$prefix-vpc --region=${region}

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

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

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

Из Cloudshell:

gcloud compute firewall-rules create $prefix-allow-iap-proxy \
--direction=INGRESS \
--priority=1000 \
--network=$prefix-vpc \
--action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20

Чтобы разрешить серверу доступ к стандартному HTTP-порту (TCP 80) и протоколу ICMP:

• Применяется к ресурсам с сетевым тегом "сервер".
• Обеспечивает доступ из всех источников.

Из Cloudshell:

gcloud compute firewall-rules create $prefix-allow-http-icmp \
--direction=INGRESS \
--priority=1000 \
--network=$prefix-vpc \
--action=ALLOW \
--rules=tcp:80,icmp \
--source-ranges=0.0.0.0/0 \
--target-tags=server

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

• Применяется к ресурсам с сетевым тегом "fw".
• Разрешает входящий трафик из источников 10.10.10.0/24

Из Cloudshell:

gcloud compute firewall-rules create $prefix-fw-allow-ingress \
--direction=INGRESS \
--priority=1000 \
--network=$prefix-vpc \
--action=ALLOW \
--rules=all \
--source-ranges=10.10.10.0/24 \
--target-tags=fw

Для проведения медицинских осмотров с помощью зондов

• Применяется к ресурсам с сетевым тегом "fw".
• Обеспечивает доступ из зон медицинского осмотра.

Из Cloudshell:

gcloud compute firewall-rules create $prefix-allow-hc-ingress \
--direction=INGRESS \
--priority=1000 \
--network=$prefix-vpc \
--action=ALLOW \
--rules=tcp:80 \
--source-ranges=130.211.0.0/22,35.191.0.0/16 \
--target-tags=fw

7. Создайте облачный маршрутизатор и облачный NAT.

Цель этого раздела — предоставить частным виртуальным машинам возможность загрузить соответствующие программные пакеты из интернета.

Создать облачный маршрутизатор

Из Cloudshell:

gcloud compute routers create ${prefix}-cr \
--region=${region} \
--network=${prefix}-vpc

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

Из Cloudshell:

gcloud compute routers nats create ${prefix}-nat-gw-${region} \
--router=${prefix}-cr \
--router-region=${region} \
--auto-allocate-nat-external-ips \
--nat-all-subnet-ip-ranges

8. Создание вычислительных экземпляров

Примечание : В целях безопасности в этом практическом задании предполагается, что включена функция Identity-Aware Proxy для пересылки TCP-пакетов , позволяющая осуществлять SSH-доступ без назначения публичных IP-адресов экземплярам. Пожалуйста, настройте её перед продолжением.

Создайте вычислительные экземпляры ClientA, ClientB, FW и Server:

Из Cloudshell:

gcloud compute instances create clienta \
   --subnet=$prefix-vpc-subnet \
   --no-address \
   --private-network-ip=10.10.10.10 \
   --zone $zone \
   --tags client \
   --metadata startup-script='#! /bin/bash
apt-get update'

Из Cloudshell:

gcloud compute instances create clientb \
   --subnet=$prefix-vpc-subnet \
   --no-address \
   --private-network-ip=10.10.10.11 \
   --zone $zone \
   --tags client \
   --metadata startup-script='#! /bin/bash
apt-get update'

Из Cloudshell:

gcloud compute instances create server \
   --subnet=$prefix-vpc-subnet \
   --no-address \
   --private-network-ip=10.10.10.200 \
   --zone $zone \
   --tags server \
   --metadata startup-script='#! /bin/bash
sudo su
apt-get update
apt-get -y install tcpdump
apt-get -y install nginx
cat > /var/www/html/index.html << EOF
<html><body><p>Server</p></body></html>
EOF'

Из Cloudshell:

gcloud compute instances create fw \
   --subnet=$prefix-vpc-subnet \
   --can-ip-forward \
   --no-address \
   --private-network-ip=10.10.10.75 \
   --zone $zone \
   --tags fw \
   --metadata startup-script='#! /bin/bash
apt-get update
sudo apt-get -y install tcpdump
sudo apt-get -y install nginx
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -I FORWARD -d 10.10.10.200 -j REJECT'

9. Проверка подключения без PBR.

Подключитесь по SSH к недавно созданным виртуальным машинам на клиентских компьютерах и проверьте подключение обоих клиентов к серверу.

При входе в систему через cloudshell1 на клиентском компьютере:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

Выполните следующие команды:

ping 10.10.10.200 -c 5

curl 10.10.10.200/index.html

Пинг-запросы и запросы curl должны быть успешными.

Выход:

root@clienta:~$ ping 10.10.10.200 -c 5
PING 10.10.10.200 (10.10.10.200) 56(84) bytes of data.
64 bytes from 10.10.10.200: icmp_seq=1 ttl=64 time=1.346 ms
64 bytes from 10.10.10.200: icmp_seq=2 ttl=64 time=0.249 ms
64 bytes from 10.10.10.200: icmp_seq=3 ttl=64 time=0.305 ms
64 bytes from 10.10.10.200: icmp_seq=4 ttl=64 time=0.329 ms
64 bytes from 10.10.10.200: icmp_seq=5 ttl=64 time=0.240 ms

root@clienta:~$ curl 10.10.10.200/index.html
<html><body><p>Server</p></body></html>

Откройте дополнительную вкладку Cloudshell, нажав на значок +.

В Cloudshell2 заданы переменные для использования:

export project_id=`gcloud config list --format="value(core.project)"`
export region=us-central1
export zone=us-central1-a
export prefix=codelab-pbr

От Cloudshell2 по SSH к ClientB:

gcloud compute ssh clientb --zone=$zone --tunnel-through-iap

Выполните следующие команды:

ping 10.10.10.200 -c 5

curl 10.10.10.200/index.html

Пинг-запросы и запросы curl должны быть успешными.

Выход:

root@clientb:~$ ping 10.10.10.200 -c 5
PING 10.10.10.200 (10.10.10.200) 56(84) bytes of data.
64 bytes from 10.10.10.200: icmp_seq=1 ttl=64 time=1.346 ms
64 bytes from 10.10.10.200: icmp_seq=2 ttl=64 time=0.249 ms
64 bytes from 10.10.10.200: icmp_seq=3 ttl=64 time=0.305 ms
64 bytes from 10.10.10.200: icmp_seq=4 ttl=64 time=0.329 ms
64 bytes from 10.10.10.200: icmp_seq=5 ttl=64 time=0.240 ms

root@clientb:~$ curl 10.10.10.200/index.html
<html><body><p>Server</p></body></html>

Теперь выйдите из терминала виртуальной машины и вернитесь в Cloudshell.

10. Создайте группу экземпляров

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

Из Cloudshell:

gcloud compute instance-groups unmanaged create pbr-uig --zone=$zone

Добавьте экземпляр fw в группу неуправляемых экземпляров.

Из Cloudshell:

gcloud compute instance-groups unmanaged add-instances pbr-uig --instances=fw --zone=$zone

11. Создайте проверку состояния здоровья.

Создайте проверку работоспособности для бэкэнд-сервиса. Мы выполним простую проверку работоспособности по TCP-порту 80.

Из Cloudshell:

gcloud compute health-checks create tcp $prefix-hc-tcp-80 --region=$region --port 80

12. Создайте серверную службу.

Создайте серверную службу для привязки к правилу переадресации.

Из Cloudshell:

gcloud compute backend-services create be-pbr --load-balancing-scheme=internal --protocol=tcp --region=$region --health-checks=$prefix-hc-tcp-80 --health-checks-region=$region

Теперь добавьте группу экземпляров в службу бэкэнда.

Из Cloudshell:

gcloud compute backend-services add-backend be-pbr --region=$region --instance-group=pbr-uig --instance-group-zone=$zone

13. Создайте правило пересылки.

Из Cloudshell:

gcloud compute forwarding-rules create fr-pbr --region=$region --load-balancing-scheme=internal --network=$prefix-vpc --subnet=$prefix-vpc-subnet --ip-protocol=TCP --ports=ALL --backend-service=be-pbr --backend-service-region=$region --address=10.10.10.25 --network-tier=PREMIUM

14. Создайте правило PBR.

Это правило PBR применяется к клиентам. Оно будет направлять весь трафик IPv4 на правило переадресации 10.10.10.25, если исходный IP-адрес — 10.10.10.10/32 (адрес клиента), а целевой IP-адрес — 10.10.10.0/24.

Это означает, что clienta будет соответствовать PBR, а не clientb.

Из Cloudshell:

gcloud network-connectivity policy-based-routes create pbr-client \
   --network=projects/$project_id/global/networks/$prefix-vpc \
   --next-hop-ilb-ip=10.10.10.25 \
   --source-range=10.10.10.10/32 \
   --destination-range=10.10.10.0/24 \
   --protocol-version=IPv4 \
   --priority=1000 \
   --tags=client

Это правило PBR применяется к серверу. Оно будет направлять весь трафик IPv4 на правило переадресации 10.10.10.25, если исходный IP-адрес — 10.10.10.200/32, а целевой IP-адрес — 10.10.10.10/32.

Из Cloudshell:

gcloud network-connectivity policy-based-routes create pbr-server \
   --network=projects/$project_id/global/networks/$prefix-vpc \
   --next-hop-ilb-ip=10.10.10.25 \
   --source-range=10.10.10.200/32 \
   --destination-range=10.10.10.10/32 \
   --protocol-version=IPv4 \
   --priority=2000 \
   --tags=server

15. Проверка подключения с помощью PBR

Теперь проверим работоспособность PBR. Экземпляр "fw" настроен с использованием iptables для отклонения запросов, предназначенных для сервера. Если PBR работает, запросы, которые ранее работали на клиенте a, теперь будут завершаться с ошибкой, в то время как запрос на клиенте b останется успешным.

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

От cloudshell1:

gcloud compute ssh clienta --zone=$zone --tunnel-through-iap

Выполните следующие команды:

ping 10.10.10.200 -c 5

curl 10.10.10.200/index.html

Выход:

root@clienta:~$ ping 10.10.10.200 -c 5
PING 10.10.10.200 (10.10.10.200) 56(84) bytes of data.
From 10.10.10.75 icmp_seq=1 Destination Port Unreachable
From 10.10.10.75 icmp_seq=2 Destination Port Unreachable
From 10.10.10.75 icmp_seq=3 Destination Port Unreachable
From 10.10.10.75 icmp_seq=4 Destination Port Unreachable
From 10.10.10.75 icmp_seq=5 Destination Port Unreachable

root@clienta:~$ curl 10.10.10.200/index.html
curl: (7) Failed to connect to 10.10.10.200 port 80: Connection refused

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

Подключитесь к clientb по SSH и выполните тот же тест на подключение.

Из cloudshell2:

gcloud compute ssh clientb --zone=$zone --tunnel-through-iap

Выполните следующие команды:

ping 10.10.10.200 -c 5

curl 10.10.10.200/index.html

Выход:

root@clientb:~$ ping 10.10.10.200 -c 5
PING 10.10.10.200 (10.10.10.200) 56(84) bytes of data.
64 bytes from 10.10.10.200: icmp_seq=1 ttl=63 time=0.361 ms
64 bytes from 10.10.10.200: icmp_seq=2 ttl=63 time=0.475 ms
64 bytes from 10.10.10.200: icmp_seq=3 ttl=63 time=0.379 ms

root@clientb:~$ curl 10.10.10.200
<html><body><p>Server</p></body></html>

Как видите, запросы от клиента к серверу выполняются успешно. Это происходит потому, что запросы не соответствуют правилу PBR для исходного IP-адреса.

16. [Необязательно] Проверка с помощью перехвата данных на межсетевом экране.

В этом необязательном разделе у вас есть возможность проверить PBR, сделав захват пакетов на виртуальной машине межсетевого экрана.

В cloudshell1 и cloudshell2 по-прежнему должно быть SSH-соединение с clienta и clientb.

Откройте дополнительную вкладку Cloudshell, нажав на значок +.

В cloudshell3 установите переменные:

export project_id=`gcloud config list --format="value(core.project)"`
export region=us-central1
export zone=us-central1-a
export prefix=codelab-pbr

Подключиться к прошивке по SSH:

gcloud compute ssh fw --zone=$zone --tunnel-through-iap

Выполните следующую команду в брандмауэре (cloudshell3):

sudo tcpdump -i any icmp -nn

С клиентского компьютера (cloudshell1) выполните тест ping:

ping 10.10.10.200 -c 5

С помощью clientb (cloudshell2) запустите тест ping:

ping 10.10.10.200 -c 5

Вывод в прошивке (Cloudshell 3):

root@fw:~$ sudo tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
17:07:42.215297 ens4  In  IP 10.10.10.10 > 10.10.10.200: ICMP echo request, id 25362, seq 1, length 64
17:07:42.215338 ens4  Out IP 10.10.10.75 > 10.10.10.10: ICMP 10.10.10.200 protocol 1 port 51064 unreachable, length 92
17:07:43.216122 ens4  In  IP 10.10.10.10 > 10.10.10.200: ICMP echo request, id 25362, seq 2, length 64
17:07:43.216158 ens4  Out IP 10.10.10.75 > 10.10.10.10: ICMP 10.10.10.200 protocol 1 port 30835 unreachable, length 92
17:07:44.219064 ens4  In  IP 10.10.10.10 > 10.10.10.200: ICMP echo request, id 25362, seq 3, length 64
17:07:44.219101 ens4  Out IP 10.10.10.75 > 10.10.10.10: ICMP 10.10.10.200 protocol 1 port 2407 unreachable, length 92

В дампе TCP вы не увидите пакетов от clientb (10.10.10.11), поскольку PBR неприменим.

Для очистки ресурсов вернитесь в Cloudshell.

17. Этапы очистки

В Cloud Shell удалите правило PBR, правило переадресации, бэкэнд-службу, проверку работоспособности, группу экземпляров, вычислительные экземпляры, NAT, Cloud Router и правила брандмауэра.

gcloud -q network-connectivity policy-based-routes delete pbr-client

gcloud -q network-connectivity policy-based-routes delete pbr-server

gcloud -q compute forwarding-rules delete fr-pbr --region=$region

gcloud -q compute backend-services delete be-pbr --region=$region

gcloud -q compute health-checks delete $prefix-hc-tcp-80 --region=$region

gcloud -q compute instance-groups unmanaged delete pbr-uig --zone=$zone

gcloud -q compute instances delete clienta --zone=$zone
gcloud -q compute instances delete clientb --zone=$zone
gcloud -q compute instances delete server --zone=$zone
gcloud -q compute instances delete fw --zone=$zone


gcloud -q compute routers nats delete ${prefix}-nat-gw-${region} \
--router=$prefix-cr --router-region=$region

gcloud -q compute routers delete $prefix-cr --region=$region

gcloud -q compute firewall-rules delete $prefix-allow-iap-proxy
gcloud -q compute firewall-rules delete $prefix-allow-http-icmp
gcloud -q compute firewall-rules delete $prefix-fw-allow-ingress
gcloud -q compute firewall-rules delete $prefix-allow-hc-ingress

Удалите подсеть и VPC:

gcloud -q compute networks subnets delete $prefix-vpc-subnet \
    --region $region

gcloud -q compute networks delete $prefix-vpc

18. Поздравляем!

Поздравляем с завершением практического занятия!

Что мы рассмотрели

• Маршруты, основанные на политике