1. Введение
Статические пользовательские маршруты влияют на поведение маршрутизации по умолчанию в VPC. Пользовательские маршруты IPv6 теперь поддерживают новые атрибуты следующего прыжка: шлюз следующего прыжка, экземпляр следующего прыжка и адрес следующего прыжка. В этой лаборатории кода описывается, как использовать пользовательские маршруты IPv6 с этими новыми параметрами следующего перехода, используя два VPC, соединенных экземпляром виртуальной машины с несколькими сетевыми адаптерами. Вы также продемонстрируете смешивание адресов ULA и GUA и обеспечение доступности ULA VPC для общедоступного Интернета с использованием новой возможности настраиваемого маршрута.
Что вы узнаете
- Как создать собственный маршрут IPv6 со следующим переходом next-hop-ilb, указав имя ILB
- Как создать собственный маршрут IPv6 со следующим переходом next-hop-ilb, указав IPv6-адрес ILB
Что вам понадобится
- Облачный проект Google
2. Прежде чем начать
Обновите проект для поддержки лаборатории кода.
В этом Codelab используются переменные $variables для облегчения реализации конфигурации gcloud в Cloud Shell.
Внутри Cloud Shell выполните следующие действия.
gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
export projectname=$(gcloud config list --format="value(core.project)")
Общая архитектура лаборатории
Чтобы продемонстрировать оба типа следующих переходов настраиваемого маршрута, вы создадите 2 VPC: клиентское и серверное VPC, которые используют адресацию ULA.
Чтобы клиентский VPC получил доступ к серверу, вы будете использовать собственный маршрут с использованием next-hop-ilb, указывающего на ILB (с использованием имени ILB) перед группой экземпляров шлюза с несколькими сетевыми картами, которые расположены между двумя ILB. Чтобы обеспечить обратную маршрутизацию к экземпляру клиента (после удаления маршрута по умолчанию ::/0), вы будете использовать собственный маршрут со следующим hop-ilb (с использованием адреса ILB), указывающим на ILB.
3. Настройка клиентского VPC
Создайте клиентское VPC
Внутри Cloud Shell выполните следующие действия:
gcloud compute networks create client-vpc \
--project=$projectname \
--subnet-mode=custom --mtu=1500 \
--bgp-routing-mode=regional \
--enable-ula-internal-ipv6
Создайте клиентскую подсеть
Внутри Cloud Shell выполните следующие действия:
gcloud compute networks subnets create client-subnet \
--network=client-vpc \
--project=$projectname \
--range=192.168.1.0/24 \
--stack-type=IPV4_IPV6 \
--ipv6-access-type=internal \
--region=us-central1
Запишите назначенную подсеть IPv6 в переменную среды с помощью этой команды.
export client_subnet=$(gcloud compute networks subnets \
describe client-subnet \
--project $projectname \
--format="value(internalIpv6Prefix)" \
--region us-central1)
Запустить экземпляр клиента
Внутри Cloud Shell выполните следующие действия:
gcloud compute instances create client-instance \
--subnet client-subnet \
--stack-type IPV4_IPV6 \
--zone us-central1-a \
--project=$projectname
Добавьте правило брандмауэра для клиентского трафика VPC.
Внутри Cloud Shell выполните следующие действия:
gcloud compute firewall-rules create allow-gateway-client \
--direction=INGRESS --priority=1000 \
--network=client-vpc --action=ALLOW \
--rules=tcp --source-ranges=$client_subnet \
--project=$projectname
Добавьте правило брандмауэра, чтобы разрешить IAP для экземпляра клиента.
Внутри Cloud Shell выполните следующие действия:
gcloud compute firewall-rules create allow-iap-client \
--direction=INGRESS --priority=1000 \
--network=client-vpc --action=ALLOW \
--rules=tcp:22 --source-ranges=35.235.240.0/20 \
--project=$projectname
Подтвердите доступ по SSH к экземпляру клиента.
Внутри Cloud Shell войдите в экземпляр клиента:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
В случае успеха вы увидите окно терминала экземпляра клиента. Выйдите из сеанса SSH, чтобы продолжить работу с кодовой лабораторией.
4. Настройка сервера VPC
Создайте сервер VPC
Внутри Cloud Shell выполните следующие действия:
gcloud compute networks create server-vpc \
--project=$projectname \
--subnet-mode=custom --mtu=1500 \
--bgp-routing-mode=regional \
--enable-ula-internal-ipv6
Создайте подсети сервера
Внутри Cloud Shell выполните следующие действия:
gcloud compute networks subnets create server-subnet \
--network=server-vpc \
--project=$projectname \
--range=192.168.0.0/24 \
--stack-type=IPV4_IPV6 \
--ipv6-access-type=internal \
--region=us-central1
Запишите назначенную подсеть в переменную среды с помощью этой команды
export server_subnet=$(gcloud compute networks subnets \
describe server-subnet \
--project $projectname \
--format="value(internalIpv6Prefix)" \
--region us-central1)
Запустить виртуальную машину сервера
Внутри Cloud Shell выполните следующие действия:
gcloud compute instances create server-instance \
--subnet server-subnet \
--stack-type IPV4_IPV6 \
--zone us-central1-a \
--project=$projectname
Добавьте правило брандмауэра, чтобы разрешить доступ к серверу с клиента.
Внутри Cloud Shell выполните следующие действия:
gcloud compute firewall-rules create allow-client-server \
--direction=INGRESS --priority=1000 \
--network=server-vpc --action=ALLOW \
--rules=tcp --source-ranges=$client_subnet \
--project=$projectname
Добавьте правило брандмауэра, чтобы разрешить IAP
Внутри Cloud Shell выполните следующие действия:
gcloud compute firewall-rules create allow-iap-server \
--direction=INGRESS --priority=1000 \
--network=server-vpc --action=ALLOW \
--rules=tcp:22 \
--source-ranges=35.235.240.0/20 \
--project=$projectname
Установите Apache на экземпляре сервера ULA.
Внутри Cloud Shell войдите в экземпляр клиента:
gcloud compute ssh server-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Внутри оболочки виртуальной машины сервера выполните следующую команду
sudo apt update && sudo apt -y install apache2
Убедитесь, что Apache работает
sudo systemctl status apache2
Перезаписать веб-страницу по умолчанию
echo '<!doctype html><html><body><h1>Hello World! From Server Instance!</h1></body></html>' | sudo tee /var/www/html/index.html
Выйдите из сеанса SSH, чтобы продолжить работу с кодовой лабораторией.
5. Создайте экземпляры шлюза
Создание шаблона экземпляра шлюза с несколькими сетевыми картами
Внутри Cloud Shell выполните следующие действия:
gcloud compute instance-templates create gateway-instance-template \
--project=$projectname \
--instance-template-region=us-central1 \
--region=us-central1 \
--network-interface=stack-type=IPV4_IPV6,subnet=client-subnet,no-address \
--network-interface=stack-type=IPV4_IPV6,subnet=server-subnet,no-address \
--can-ip-forward \
--metadata=startup-script='#! /bin/bash
sudo sysctl -w net.ipv6.conf.ens4.accept_ra=2
sudo sysctl -w net.ipv6.conf.ens5.accept_ra=2
sudo sysctl -w net.ipv6.conf.ens4.accept_ra_defrtr=1
sudo sysctl -w net.ipv6.conf.all.forwarding=1'
Создать группу экземпляров шлюза с несколькими сетевыми картами.
Внутри Cloud Shell выполните следующие действия:
gcloud compute instance-groups managed create gateway-instance-group \
--project=$projectname \
--base-instance-name=gateway-instance \
--template=projects/$projectname/regions/us-central1/instanceTemplates/gateway-instance-template \
--size=2 \
--zone=us-central1-a
Проверка экземпляров шлюза
Чтобы убедиться, что наш сценарий запуска был передан правильно и таблица маршрутизации v6 правильна. SSH к одному из экземпляров шлюза
Внутри Cloud Shell перечислите экземпляры шлюза, выполнив следующую команду:
gcloud compute instances list \
--project=$projectname \
--zones=us-central1-a \
--filter name~gateway \
--format 'csv(name)'
Запишите одно из имен экземпляра и используйте его в следующей команде для подключения к экземпляру по SSH.
Внутри Cloud Shell войдите в один из экземпляров шлюза.
gcloud compute ssh gateway-instance-<suffix> \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Внутри оболочки виртуальной машины шлюза выполните следующую команду, чтобы проверить переадресацию IPv6.
sudo sysctl net.ipv6.conf.all.forwarding
Команда должна вернуть значение «1», указывающее, что переадресация IPv6 включена.
Проверьте таблицу маршрутизации IPv6 на экземпляре.
ip -6 route show
Пример вывода, показывающий маршруты подсетей ULA и GUA, причем маршрут по умолчанию указывает на интерфейс GUA.
::1 dev lo proto kernel metric 256 pref medium
2600:1900:4000:7a7f:0:1:: dev ens4 proto kernel metric 256 expires 83903sec pref medium
2600:1900:4000:7a7f::/65 via fe80::4001:c0ff:fea8:101 dev ens4 proto ra metric 1024 expires 88sec pref medium
fd20:3df:8d5c::1:0:0 dev ens5 proto kernel metric 256 expires 83904sec pref medium
fd20:3df:8d5c::/64 via fe80::4001:c0ff:fea8:1 dev ens5 proto ra metric 1024 expires 84sec pref medium
fe80::/64 dev ens5 proto kernel metric 256 pref medium
fe80::/64 dev ens4 proto kernel metric 256 pref medium
default via fe80::4001:c0ff:fea8:101 dev ens4 proto ra metric 1024 expires 88sec pref medium
Выйдите из сеанса SSH, чтобы продолжить работу с кодовой лабораторией.
6. Создайте компоненты балансировщика нагрузки.
Прежде чем мы сможем создавать маршруты в обоих VPC, нам нужно будет создать внутренние балансировщики транзитной нагрузки на обеих сторонах экземпляров шлюза для пересылки трафика.
Балансировщики нагрузки, созданные в этой лаборатории кода, состоят из
- Проверка работоспособности. В этой лаборатории кода мы создадим простые проверки работоспособности, нацеленные на порт 22. Обратите внимание, что проверки работоспособности не будут работать в развернутом виде (это потребует добавления правил брандмауэра, разрешающих проверки работоспособности, и создания специальных маршрутов на экземплярах шлюза). Поскольку эта кодовая лаборатория ориентирована на пересылку IPv6, мы будем полагаться на поведение распределения трафика по умолчанию для внутренних балансировщиков сквозной нагрузки, когда все серверные части неработоспособны, а именно на пересылку на все серверные части в крайнем случае.
- Внутренняя служба: мы будем использовать протокол TCP для внутренней службы. Но поскольку балансировщики нагрузки создаются для целей маршрутизации, все протоколы пересылаются независимо от протокола внутренней службы.
- Правило переадресации: мы создаем правило переадресации для каждого VPC.
- Внутренний адрес IPv6: в этой лаборатории мы разрешим правилу пересылки автоматически выделять адреса IPv6 из подсети.
Создать проверку работоспособности
Внутри Cloud Shell выполните следующие действия:
gcloud compute health-checks create tcp tcp-hc-22 \
--project=$projectname \
--region=us-central1 \
--port=22
Создать серверные службы
Внутри Cloud Shell выполните следующие действия:
gcloud compute backend-services create bes-ilb-clientvpc \
--project=$projectname \
--load-balancing-scheme=internal \
--protocol=tcp \
--network=client-vpc \
--region=us-central1 \
--health-checks=tcp-hc-22 \
--health-checks-region=us-central1
gcloud compute backend-services create bes-ilb-servervpc \
--project=$projectname \
--load-balancing-scheme=internal \
--protocol=tcp \
--network=server-vpc \
--region=us-central1 \
--health-checks=tcp-hc-22 \
--health-checks-region=us-central1
Добавить группу экземпляров во внутреннюю службу
Внутри Cloud Shell выполните следующие действия:
gcloud compute backend-services add-backend bes-ilb-clientvpc \
--project=$projectname \
--region=us-central1 \
--instance-group=gateway-instance-group \
--instance-group-zone=us-central1-a
gcloud compute backend-services add-backend bes-ilb-servervpc \
--project=$projectname \
--region=us-central1 \
--instance-group=gateway-instance-group \
--instance-group-zone=us-central1-a
Создать правила переадресации
Внутри Cloud Shell выполните следующие действия:
gcloud compute forwarding-rules create fr-ilb-clientvpc \
--project=$projectname \
--region=us-central1 \
--load-balancing-scheme=internal \
--network=client-vpc \
--subnet=client-subnet \
--ip-protocol=TCP \
--ip-version=IPV6 \
--ports=ALL \
--backend-service=bes-ilb-clientvpc \
--backend-service-region=us-central1
gcloud compute forwarding-rules create fr-ilb-servervpc \
--project=$projectname \
--region=us-central1 \
--load-balancing-scheme=internal \
--network=server-vpc \
--subnet=server-subnet \
--ip-protocol=TCP \
--ip-version=IPV6 \
--ports=ALL \
--backend-service=bes-ilb-servervpc \
--backend-service-region=us-central1
Запишите адреса IPv6 обоих правил переадресации, выполнив следующие команды в Cloudshell:
export fraddress_client=$(gcloud compute forwarding-rules \
describe fr-ilb-clientvpc \
--project $projectname \
--format="value(IPAddress)" \
--region us-central1)
export fraddress_server=$(gcloud compute forwarding-rules \
describe fr-ilb-servervpc \
--project $projectname \
--format="value(IPAddress)" \
--region us-central1)
7. Создайте и протестируйте маршруты к балансировщикам нагрузки (используя адрес балансировщика нагрузки).
В этом разделе вы добавите маршруты как к клиентскому, так и к серверному VPC, используя IPv6-адреса балансировщиков нагрузки в качестве следующих переходов.
Запишите адреса серверов
Внутри Cloud Shell выполните следующие действия:
gcloud compute instances list \
--project $projectname \
--zones us-central1-a \
--filter="name~server-instance" \
--format='value[separator=","](name,networkInterfaces[0].ipv6Address)'
При этом должны выводиться как имена экземпляров серверов, так и их префиксы IPv6. Пример вывода
server-instance,fd20:3df:8d5c:0:0:0:0:0
Запишите адрес сервера, поскольку вы будете использовать его позже в командах Curl из экземпляра клиента. К сожалению, переменные среды нелегко использовать для их хранения, поскольку они не передаются через сеансы SSH.
Запустите команду Curl от клиента к экземпляру сервера ULA.
Чтобы увидеть поведение перед добавлением новых маршрутов. Запустите команду curl от экземпляра клиента к экземпляру сервера1.
Внутри Cloud Shell войдите в экземпляр клиента:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Внутри экземпляра клиента выполните скручивание, используя адрес ULA IPV6 экземпляра server1 (команда устанавливает короткий тайм-аут в 5 секунд, чтобы избежать слишком длительного ожидания скручивания)
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Время ожидания этой команды curl должно истечь, поскольку у клиентского VPC еще нет маршрута к серверному VPC.
Давайте попробуем это исправить! Выйдите из сеанса SSH на данный момент.
Добавить собственный маршрут в клиентском VPC
Поскольку в клиентском VPC отсутствует маршрут к префиксу ULA. Давайте добавим его сейчас, создав маршрут, который указывает на клиентский ILB по адресу.
Примечание. Внутренним балансировщикам транзитной нагрузки IPv6 назначены адреса /96. Необходимо снять маску /96 с адреса перед передачей его следующей команде. (ниже используется замена bash на месте)
Внутри Cloud Shell выполните следующие действия:
gcloud compute routes create client-to-server-route \
--project=$projectname \
--destination-range=$server_subnet \
--network=client-vpc \
--next-hop-ilb=${fraddress_client//\/96}
SSH обратно к экземпляру клиента:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Внутри экземпляра клиента попытайтесь снова подключиться к экземпляру сервера. (команда устанавливает короткий тайм-аут в 5 секунд, чтобы избежать слишком долгого ожидания скручивания)
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Время ожидания этой команды curl все еще истекает, поскольку у серверного VPC еще нет обратного маршрута к клиентскому VPC через экземпляр шлюза.
Выйдите из сеанса SSH, чтобы продолжить работу с кодовой лабораторией.
Добавить собственный маршрут в Server VPC
Внутри Cloud Shell выполните следующие действия:
gcloud compute routes create server-to-client-route \
--project=$projectname \
--destination-range=$client_subnet \
--network=server-vpc \
--next-hop-ilb=${fraddress_server//\/96}
SSH обратно к экземпляру клиента:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Внутри экземпляра клиента попытайтесь подключиться к экземпляру сервера еще раз.
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Теперь эта команда curl работает успешно, показывая, что у вас есть сквозная доступность от экземпляра клиента к экземпляру сервера ULA. Такое подключение теперь возможно только за счет использования пользовательских маршрутов IPv6 со следующим переходом-ilb в качестве следующих переходов.
Пример вывода
<user id>@client-instance:~$ curl -m 5.0 -g -6 'http://[fd20:3df:8d5c:0:0:0:0:0]:80/'
<!doctype html><html><body><h1>Hello World! From Server Instance!</h1></body></html>
Выйдите из сеанса SSH, чтобы продолжить работу с кодовой лабораторией.
8. Создайте и протестируйте маршруты к балансировщикам нагрузки (используя имя балансировщика нагрузки).
Альтернативно, next-hop-ilb также может ссылаться на имя балансировщика нагрузки вместо его IPv6-адреса. В этом разделе мы рассмотрим процедуру и проверим, установлено ли соединение между клиентом и сервером.
Удалить предыдущие маршруты
Давайте восстановим среду перед добавлением каких-либо пользовательских маршрутов, удалив пользовательские маршруты, использующие имя экземпляра.
Внутри Cloud Shell выполните следующие действия:
gcloud compute routes delete client-to-server-route --quiet --project=$projectname
gcloud compute routes delete server-to-client-route --quiet --project=$projectname
Запустите команду Curl от клиента к экземпляру сервера ULA.
Чтобы убедиться, что предыдущие маршруты были успешно удалены, запустите команду curl от экземпляра клиента к серверу-экземпляру1.
Внутри Cloud Shell войдите в экземпляр клиента:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Внутри экземпляра клиента выполните скручивание, используя адрес ULA IPV6 экземпляра server1 (команда устанавливает короткий тайм-аут в 5 секунд, чтобы избежать слишком длительного ожидания скручивания)
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Время ожидания этой команды curl должно истечь, поскольку у клиентского VPC больше нет маршрута к серверному VPC.
Добавляйте собственные маршруты в клиентские и серверные VPC.
Давайте заново добавим пользовательские маршруты как в клиентские, так и в серверные VPC, но вместо адреса ILB мы будем использовать в команде имя и регион ILB.
Внутри Cloud Shell выполните следующие действия:
gcloud compute routes create client-to-server-route \
--project=$projectname \
--destination-range=$server_subnet \
--network=client-vpc \
--next-hop-ilb=fr-ilb-clientvpc \
--next-hop-ilb-region=us-central1
gcloud compute routes create server-to-client-route \
--project=$projectname \
--destination-range=$client_subnet \
--network=server-vpc \
--next-hop-ilb=fr-ilb-servervpc \
--next-hop-ilb-region=us-central1
SSH обратно к экземпляру клиента:
gcloud compute ssh client-instance \
--project=$projectname \
--zone=us-central1-a \
--tunnel-through-iap
Внутри экземпляра клиента попытайтесь снова подключиться к экземпляру сервера. (команда устанавливает короткий тайм-аут в 5 секунд, чтобы избежать слишком долгого ожидания скручивания)
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Теперь эта команда curl работает успешно, показывая, что у вас есть сквозная доступность от экземпляра клиента к экземпляру сервера ULA.
9. Очистка
Очистка пользовательских маршрутов
Внутри Cloud Shell выполните следующие действия:
gcloud compute routes delete client-to-server-route --quiet --project=$projectname
gcloud compute routes delete server-to-client-route --quiet --project=$projectname
Очистка компонентов LB
Внутри Cloud Shell выполните следующие действия:
gcloud compute forwarding-rules delete fr-ilb-clientvpc --region us-central1 --quiet --project=$projectname
gcloud compute forwarding-rules delete fr-ilb-servervpc --region us-central1 --quiet --project=$projectname
gcloud compute backend-services delete bes-ilb-clientvpc --region us-central1 --quiet --project=$projectname
gcloud compute backend-services delete bes-ilb-servervpc --region us-central1 --quiet --project=$projectname
gcloud compute health-checks delete tcp-hc-22 --region us-central1 --quiet --project=$projectname
Очистка экземпляров и шаблона экземпляра
Внутри Cloud Shell выполните следующие действия:
gcloud compute instances delete client-instance --zone us-central1-a --quiet --project=$projectname
gcloud compute instances delete server-instance --zone us-central1-a --quiet --project=$projectname
gcloud compute instance-groups managed delete gateway-instance-group --zone us-central1-a --quiet --project=$projectname
gcloud compute instance-templates delete gateway-instance-template --region us-central1 --quiet --project=$projectname
Очистка подсетей
Внутри Cloud Shell выполните следующие действия:
gcloud compute networks subnets delete client-subnet --region=us-central1 --quiet --project=$projectname
gcloud compute networks subnets delete server-subnet --region=us-central1 --quiet --project=$projectname
Очистка правил брандмауэра
Внутри Cloud Shell выполните следующие действия:
gcloud compute firewall-rules delete allow-iap-client --quiet --project=$projectname
gcloud compute firewall-rules delete allow-iap-server --quiet --project=$projectname
gcloud compute firewall-rules delete allow-gateway-client --quiet --project=$projectname
gcloud compute firewall-rules delete allow-client-server --quiet --project=$projectname
Очистка VPC
Внутри Cloud Shell выполните следующие действия:
gcloud compute networks delete client-vpc --quiet --project=$projectname
gcloud compute networks delete server-vpc --quiet --project=$projectname
10. Поздравления
Вы успешно использовали статические пользовательские маршруты IPv6 с параметром next-hop, установленным на next-hop-ilb. Вы также проверили сквозную связь IPv6 с использованием этих маршрутов.
Что дальше?
Посмотрите некоторые из этих кодовых лабораторий...
- Доступ к API Google с локальных хостов с использованием адресов IPv6.
- Варианты IP-адресации IPv4 и IPv6
- Использование статических маршрутов IPv6: экземпляр следующего прыжка, адрес следующего прыжка и шлюз следующего прыжка.