Маршруты на основе политик (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. Тестовая среда

Эта Codelab будет использовать один 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.

Из облачной оболочки:

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 для использования продуктов.

Из облачной оболочки:

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

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

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

Сеть VPC

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

Из облачной оболочки:

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

Подсеть

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

Из облачной оболочки:

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.

Из облачной оболочки:

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:

• Применяется к ресурсам с сетевым тегом «сервер».
• Разрешает доступ из всех источников

Из облачной оболочки:

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.

Из облачной оболочки:

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».
• Разрешает вход из диапазонов проверки работоспособности.

Из облачной оболочки:

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.

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

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

Из облачной оболочки:

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

Создать облачный NAT-шлюз

Из облачной оболочки:

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. Создание вычислительных экземпляров

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

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

Из облачной оболочки:

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'

Из облачной оболочки:

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'

Из облачной оболочки:

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'

Из облачной оболочки:

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 войдите в clienta:

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

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

ping 10.10.10.200 -c 5

curl 10.10.10.200/index.html

Запросы ping и 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

Запросы ping и 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.

Из облачной оболочки:

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

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

Из облачной оболочки:

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

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

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

Из облачной оболочки:

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

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

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

Из облачной оболочки:

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

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

Из облачной оболочки:

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

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

Из облачной оболочки:

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.

Из облачной оболочки:

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.

Из облачной оболочки:

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 работает, запросы, которые ранее обрабатывались на clienta, теперь завершатся неудачей, в то время как clientb по-прежнему выполняется успешно.

Подключитесь по 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 активно маршрутизирует трафик для клиента на экземпляр fw, который был настроен на блокировку этого трафика.

Подключитесь по SSH к clientb и запустите тот же тест подключения.

Из 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>

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

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

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

У вас по-прежнему должно быть SSH-соединение в cloudshell1 и cloudshell2 с 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

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

sudo tcpdump -i any icmp -nn

Из клиента (cloudshell1) запустите пинг-тест:

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

Вы не увидите никаких пакетов в tcpdump от 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. Поздравляем!

Поздравляем с завершением работы над кодом.

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

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