1. Введение
Статические пользовательские маршруты влияют на поведение маршрутизации по умолчанию в VPC. Пользовательские маршруты IPv6 теперь поддерживают новые атрибуты следующего перехода: next-hop-gateway, next-hop-instance и next-hop-address. В этом практическом занятии описывается, как использовать пользовательские маршруты IPv6 с этими новыми параметрами следующего перехода, используя две VPC, соединенные экземпляром виртуальной машины с несколькими сетевыми адаптерами. Вы также продемонстрируете смешивание адресации ULA и GUA и обеспечение доступности VPC ULA для доступа к общедоступному интернету с помощью новой возможности пользовательских маршрутов.
Что вы узнаете
- Как создать пользовательский маршрут IPv6 с указанием следующего перехода через ILB, указав имя ILB.
- Как создать пользовательский маршрут IPv6 с указанием IPv6-адреса балансировщика нагрузки (ILB) в качестве следующего хопа.
Что вам понадобится
- Проект Google Cloud
2. Прежде чем начать
Обновите проект, чтобы он поддерживал практическое занятие.
В этом практическом занятии используется переменная `$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)")
Общая архитектура лаборатории
Для демонстрации обоих типов пользовательских маршрутов перехода к следующему узлу вам потребуется создать две VPC: клиентскую и серверную VPC, использующие адресацию ULA.
Для доступа клиентской VPC к серверу необходимо использовать пользовательский маршрут с параметром next-hop-ilb, указывающим на ILB (используя имя ILB) перед группой многосетевых шлюзовых экземпляров, расположенных между двумя ILB. Для обеспечения обратной маршрутизации к клиентскому экземпляру (после удаления маршрута по умолчанию ::/0) необходимо использовать пользовательский маршрут с параметром next-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
Внутри клиентского экземпляра выполните команду curl, используя IPv6-адрес ULA экземпляра server1 (команда устанавливает короткий тайм-аут в 5 секунд, чтобы избежать слишком долгого ожидания curl).
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Эта команда curl должна завершиться по истечении времени ожидания, поскольку у клиентской VPC пока нет маршрута к серверной VPC.
Давайте попробуем это исправить! Пока что выйдем из SSH-сессии.
Добавьте пользовательский маршрут в клиентскую VPC.
Поскольку в клиентской VPC отсутствует маршрут к префиксу ULA, давайте добавим его, создав маршрут, указывающий на балансировщик нагрузки на стороне клиента по адресу.
Примечание: Внутренним балансировщикам нагрузки 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
Внутри клиентского экземпляра повторите попытку выполнения команды curl к серверному экземпляру. (Команда устанавливает короткий тайм-аут в 5 секунд, чтобы избежать слишком долгого ожидания curl).
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Эта команда curl по-прежнему выдает ошибку тайм-аута, потому что у серверной VPC еще нет маршрута обратно к клиентской VPC через экземпляр шлюза.
Чтобы продолжить выполнение практического задания, выйдите из SSH-сессии.
Добавьте пользовательский маршрут в 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 к серверному экземпляру.
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Эта команда curl теперь выполняется успешно, что подтверждает наличие сквозной доступности от клиентского экземпляра к серверному экземпляру ULA. Такое соединение теперь возможно только при использовании пользовательских маршрутов IPv6 с next-hop-ilb в качестве next-hops.
Пример выходных данных
<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
Внутри клиентского экземпляра выполните команду curl, используя IPv6-адрес ULA экземпляра server1 (команда устанавливает короткий тайм-аут в 5 секунд, чтобы избежать слишком долгого ожидания curl).
curl -m 5.0 -g -6 'http://[ULA-ipv6-address-of-server1]:80/'
Эта команда curl должна завершиться по истечении времени ожидания, поскольку у клиентской VPC больше нет маршрута к серверной VPC.
Добавление пользовательских маршрутов в клиентские и серверные VPC
Давайте повторно добавим пользовательские маршруты в клиентские и серверные VPC, но вместо адреса 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
Внутри клиентского экземпляра повторите попытку выполнения команды curl к серверному экземпляру. (Команда устанавливает короткий тайм-аут в 5 секунд, чтобы избежать слишком долгого ожидания curl).
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-hops, установленным на next-hop-ilb. Вы также проверили сквозную связь IPv6 с использованием этих маршрутов.
Что дальше?
Посмотрите некоторые из этих практических занятий по программированию...
- Доступ к API Google с локальных хостов с использованием IPv6-адресов.
- Варианты IP-адресации: IPv4 и IPv6
- Использование статических маршрутов IPv6: экземпляр следующего перехода, адрес следующего перехода и шлюз следующего перехода.