Google PCNE: Гибридное подключение, Cloud Router и BGP — Руководство по подготовке

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Часть Google Professional Cloud Network Engineer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

Гибридное подключение в Google Cloud обеспечивает частную, контролируемую связь между сетями VPC и внешними сетями, такими как локальные центры обработки данных или другие облака. Основные компоненты — это шлюзы HA VPN и Cloud VPN, Cloud Router с BGP для динамической маршрутизации и Interconnect с подключениями VLAN (VLAN attachments). При проектировании необходимо сбалансировать пропускную способность, задержку, надежность, сложность эксплуатации и стоимость, придерживаясь детерминированного поведения маршрутизации и изоляции доменов отказа. В этом разделе рассматриваются принципы проектирования и эксплуатации, распространенные режимы сбоев и систематический поиск неисправностей.

Гибридное подключение: HA VPN, Cloud Router и Interconnect

HA VPN и Cloud VPN
- HA VPN — это региональный, высокодоступный IPsec VPN, который поддерживает IKEv2 и требует Cloud Router для динамической маршрутизации (eBGP). Шлюз HA VPN имеет два интерфейса; для обеспечения SLA и ECMP создайте по два туннеля на каждом интерфейсе к разным пиринговым конечным точкам.
- Classic Cloud VPN поддерживает IKEv1 или IKEv2, а также статические туннели или туннели на основе маршрутов; он не поддерживает SLA для HA VPN. Используйте его только в тех случаях, когда пиринговые устройства не поддерживают BGP или когда необходимо использовать селекторы на основе политик.
- Пиринговый шлюз (peer gateway) — это удаленное VPN-устройство/IP-адрес. Для HA VPN определите пиринговый VPN-шлюз с одним или несколькими публичными IP-адресами, чтобы смоделировать отдельные интерфейсы или устройства для резервирования.
- Проектирование с учетом SLA: Чтобы соответствовать требованиям SLA 99,99% для HA VPN, разверните резервные туннели через независимые локальные устройства или интерфейсы и используйте динамическую маршрутизацию. Classic VPN не имеет гарантированного SLA.
- Масштабирование пропускной способности: Один туннель IPsec имеет ограниченную пропускную способность. Используйте ECMP через несколько туннелей для увеличения совокупной пропускной способности. Это достигается путем терминирования дополнительных туннелей на уникальных публичных IP-адресах пиринговых устройств.
Cloud Router и BGP
- Cloud Router — это региональный сервис уровня управления (control-plane), который устанавливает сессии BGP с VPN-туннелями или подключениями VLAN для Interconnect и динамически обменивается маршрутами.
- Режим динамической маршрутизации (на уровне VPC) определяет, где могут использоваться полученные динамические маршруты и какие маршруты подсетей VPC анонсируются пирам:
  - Regional: изучение и использование/импорт динамических маршрутов только в том же регионе.
  - Global: изучение и использование/импорт динамических маршрутов во всех регионах; анонсирование всех маршрутов подсетей VPC (глобально) пирам.
Dedicated Interconnect и Partner Interconnect
- Dedicated Interconnect предоставляет физические каналы 10 Гбит/с или 100 Гбит/с напрямую к Google в колокейшн-центре. Вы получаете авторизационное письмо (Letter of Authorization – Connecting Facility Assignment, LOA‑CFA), чтобы разрешить установку кросс-соединений. Создайте подключения VLAN (VLAN attachments, или interconnect attachments), которые сопоставляют теги 802.1Q с региональным подключением уровня L3, связанным с Cloud Router.
- Partner Interconnect обеспечивает логическое подключение через поставщика услуг. Вы запрашиваете подключения VLAN у партнера; пропускная способность предоставляется на пограничном оборудовании партнера. Подключения также необходимо связать с Cloud Router для работы BGP.
- Резервирование и SLA: Используйте два подключения в одном регионе, размещенные в разных доменах доступности (edge availability domains) (и, если применимо, на разных физических Interconnect), чтобы достичь более высоких показателей SLA (например, 99,99%). Одно подключение или один канал снижает SLA. В случае Partner Interconnect общий SLA также зависит от партнера.
Кросс-соединения и подключения VLAN
- Кросс-соединения (cross-connects) — это физические оптоволоконные соединения между вашей стойкой/оборудованием и стойкой Google в коммутационной комнате (meet-me room). Предоставьте LOA‑CFA вашему провайдеру для их выполнения.
- Подключения VLAN (VLAN attachments) — это логическая демаркация уровня L2 для региона VPC. Каждое подключение:
  - Связывается ровно с одной сетью VPC и одним регионом через Cloud Router.
  - Настраивается парами для резервирования и ECMP.
  - Передает только трафик уровня L3; расширение L2 не поддерживается.

Краткий пример:

Создание Cloud Router и BGP для подключения или пира HA VPN: gcloud compute routers create cr-us-east1 –region=us-east1 –network=my-vpc –asn=65010 gcloud compute routers add-bgp-peer cr-us-east1 –region=us-east1 –peer-name=onprem-peer1 –peer-asn=65020 –interface=if-1 –peer-ip-address=169.254.0.2 –advertise-mode=DEFAULT –enable-bfd

Маршрутизация и поведение BGP

Динамическая и статическая маршрутизация
- Динамическая маршрутизация с помощью Cloud Router обеспечивает автоматическое изучение маршрутов, конвергенцию и ECMP. Она хорошо масштабируется и снижает операционные издержки по мере роста сети.
- Статическая маршрутизация подходит, когда у пиров отсутствует BGP или для узкоспециализированных, детерминированных путей. В VPC статические маршруты имеют числовой приоритет; меньшие значения предпочтительнее среди статических маршрутов с одинаковой длиной префикса.
- Выбор маршрута в VPC:
  - Побеждает наиболее длинное совпадение префикса (longest prefix match).
  - Маршруты подсетей не могут быть переопределены пользовательскими маршрутами.
  - При одинаковой длине префикса статические маршруты выбираются по наименьшему приоритету. Среди динамических маршрутов Cloud Router уже определяет лучшие пути перед их установкой. Системный маршрут по умолчанию имеет самый низкий приоритет.
BGP-сессии, анонсирование и импорт/экспорт
- Cloud Router по умолчанию экспортирует подсети VPC или настраиваемый набор префиксов. При необходимости можно анонсировать 0.0.0.0/0 или агрегированные префиксы, но это перенаправляет локальный трафик в облако, если позволяют политики; проектируйте это осознанно.
- Cloud Router импортирует все разрешенные локальные префиксы и устанавливает их как динамические маршруты в соответствии с режимом динамической маршрутизации VPC.
- Приоритет анонсируемого маршрута для каждого пира позволяет влиять на то, как локальные маршрутизаторы предпочитают один путь Google другому; меньшее значение приоритета транслируется в более предпочтительный MED в сторону пира.
ASN, MED и режим active-standby
- Используйте уникальный частный ASN для каждого административного домена, если не требуются публичные ASN. Для нескольких локальных маршрутизаторов, устанавливающих пиринг с одной VPC для одних и тех же префиксов:
  - Чтобы включить ECMP или обеспечить согласованный выбор лучшего пути, используйте один и тот же удаленный локальный ASN на всех маршрутизаторах, анонсирующих одинаковые префиксы. Разные удаленные ASN могут помешать установке равноценных маршрутов на Cloud Router.
  - Для режима active/standby управляйте MED (меньшее значение предпочтительнее) с локальной стороны или настраивайте приоритет анонсируемого маршрута для каждого пира в Cloud Router, чтобы локальная сеть предпочитала основной путь. Добавление ASN в AS-path (prepending) является альтернативным, но более грубым инструментом.
Проектирование многопутевой маршрутизации
- Cloud Router поддерживает ECMP по нескольким равноценным BGP-путям как для HA VPN, так и для подключений Interconnect. Убедитесь в равенстве атрибутов (длина AS-path, MED, local-pref) и в том, что следующие переходы (next hops) различны. Для HA VPN терминируйте туннели на разных IP-адресах пиров. Для Interconnect используйте резервные подключения (attachments).

Отказоустойчивость, обнаружение сбоев и сервисы исходящего трафика

BFD и обнаружение сбоев
- BFD ускоряет обнаружение сбоев для BGP-сессий на HA VPN и Interconnect. Включите BFD на обеих сторонах с совместимыми интервалами для достижения субсекундного или низкосекундного обнаружения, в зависимости от ваших требований к стабильности. Комбинируйте с IKE DPD на туннелях IPsec. Убедитесь, что ваши пиринговые устройства могут обрабатывать более частый управляющий трафик.
- Остерегайтесь асимметричного обнаружения: агрессивные настройки BFD в сочетании с перегруженными каналами могут вызывать нестабильность сессий (flapping); начинайте с консервативных таймеров и ведите мониторинг.
Шаблоны резервных топологий
- HA VPN: Используйте один шлюз HA VPN на регион и терминируйте туннели на двух разных локальных устройствах или интерфейсах. Создайте как минимум четыре туннеля (по два на интерфейс) и один Cloud Router на регион. Сохраняйте согласованность удаленных ASN при использовании ECMP.
- Interconnect: Используйте как минимум два подключения (attachments) в каждом регионе через разные домены доступности на границе сети (edge availability domains). Для Dedicated Interconnect по возможности развертывайте каналы на разных пограничных устройствах и в разных ЦОД.
Cloud NAT, внешние адреса и исходящий трафик частных рабочих нагрузок
- Cloud NAT — это региональный управляемый сервис для исходящего трафика ресурсов без внешних IP-адресов. Он не выполняет SNAT для инстансов, у которых есть внешние IP; они выходят в интернет напрямую. Выберите подсети или все подсети в регионе для охвата частных рабочих нагрузок.
- Определите размер пулов IP-адресов для NAT с учетом одновременных подключений и эфемерных портов; выберите ручное или автоматическое выделение IP. Включите логирование для диагностики.
- Для частного доступа к Google API:
  - Внутри VPC: включите Private Google Access на подсетях, чтобы ВМ без внешних IP-адресов могли обращаться к Google API через виртуальные IP-адреса Google.
  - Из локальной сети: используйте эндпоинты Private Service Connect для Google API и гибридный DNS, чтобы локальные клиенты могли разрешать имена и обращаться к API по частным гибридным каналам, минуя интернет.
- Если маршрут по умолчанию указывает на сторонний файрвол, но вы хотите, чтобы частные рабочие нагрузки обходили его для доступа к Google API, используйте либо Private Service Connect, либо установите статические маршруты с более высоким приоритетом для опубликованных диапазонов IP-адресов Google API, направленные на шлюз интернета по умолчанию, в сочетании с Private Google Access на подсетях.
Интеграция гибридного DNS
- Используйте частные зоны Cloud DNS для разрешения имен внутри VPC. Расширьте их на локальную сеть с помощью:
  - Входящая пересылка (Inbound forwarding): локальные DNS-резолверы пересылают запросы в Cloud DNS для частных зон, размещенных в VPC.
  - Исходящая пересылка (Outbound forwarding): резолверы VPC пересылают запросы для выбранных доменов на локальные DNS-серверы.
  - Пиринговые зоны (Peering zones) для разрешения имен между VPC в средах Shared VPC или в многопроектных конфигурациях.
- Для обеспечения частного доступа к API создайте частную зону, сопоставляющую хост-имена API с эндпоинтами Private Service Connect или с соответствующими частными VIP-адресами Google при использовании Private Google Access, и убедитесь, что эти имена могут быть разрешены из локальной сети через пересылку DNS-запросов.

Планирование и устранение неполадок

Компромиссы между пропускной способностью, задержкой и стоимостью
- VPN: самый быстрый в развертывании, самая низкая фиксированная стоимость, ограниченная пропускная способность на туннель, более высокая нагрузка на CPU/шифрование на бит и обычно более высокая задержка по сравнению с частными каналами.
- Dedicated Interconnect: самая высокая пропускная способность и самая низкая стоимость на бит с предсказуемой задержкой; более высокие фиксированные затраты и время на подготовку (кросс-коннекты, колокация).
- Partner Interconnect: промежуточный вариант; использует инфраструктуру провайдера; SLA и задержка зависят от маршрута партнера.
- Размещайте подключения (attachments) и шлюзы регионально близко к рабочим нагрузкам, чтобы минимизировать задержку. Используйте Shared VPC для централизации подключений в хост-проекте при обслуживании нескольких сервисных проектов.
- Учитывайте симметрию трафика, требования к инспекции и домены отказа. Избегайте единых точек отказа на последней миле в локальной среде и на путях провайдера.
Систематическая диагностика проблем с туннелями, BGP и маршрутизацией
1. Установление туннеля
  - Проверьте совместимость версий IKE: HA VPN требует IKEv2; если пир поддерживает только IKEv1 или VPN на основе политик, используйте Classic VPN.
  - Проверьте общие секреты, предложения (шифрование, группы DH), NAT-T и доступность портов UDP 500/4500.
  - Убедитесь в правильности IP-адресов пиров и в том, что каждый туннель указывает на отдельный интерфейс пира для резервирования.
2. Состояние сессии BGP
  - Проверьте состояния BGP на обоих концах; изучите статус Cloud Router. Если BFD включен, но сессии нестабильны («флапают»), увеличьте значения таймеров.
  - Проверьте конфигурацию ASN; несоответствие ожиданий может помешать работе ECMP или привести к неожиданному выбору лучшего пути.
  - Убедитесь, что для IP-адресации сессий BGP используются правильные link-local адреса или адреса из RFC1918, настроенные на интерфейсе туннеля или подключения.
3. Обмен и распространение маршрутов
  - Проверьте режим анонсирования Cloud Router (DEFAULT или CUSTOM). Убедитесь, что ожидаемые подсети или агрегированные маршруты экспортируются.
  - Изучите полученные маршруты на Cloud Router; оцените AS-path, MED. Если предполагается режим активный/резервный, убедитесь, что MED или приоритет анонсируемого маршрута отражают это намерение.
  - Проверьте режим динамической маршрутизации VPC (REGIONAL или GLOBAL), чтобы полученные маршруты появлялись там, где это необходимо. Помните, что маршруты подсетей не могут быть переопределены.
  - В случае конфликтов, если статический и динамический маршруты совпадают по длине префикса, преимущество имеет статический маршрут с наименьшим приоритетом. При необходимости скорректируйте или удалите перекрывающиеся статические маршруты.
4. Проверка плоскости данных (data-plane)
  - Используйте VPC Flow Logs и логи Cloud NAT для подтверждения пути исходящего трафика и трансляции адресов. Если ВМ по-прежнему выходит в сеть со своим внешним IP, удалите этот внешний IP, чтобы принудительно использовать NAT.
  - Для Interconnect проверьте рабочее состояние подключения (attachment) и убедитесь, что оба подключения административно включены и связаны с правильным Cloud Router.
  - Убедитесь, что правила брандмауэра разрешают трафик BGP и приложений; помните, что диапазоны IP-адресов для проверок состояния Google должны иметь доступ к бэкендам балансировщика нагрузки.
5. Особенности запуска Interconnect
  - Получите LOA-CFA из консоли или по контактному email сетевого операционного центра (NOC). Перед запуском BGP согласуйте с провайдером уровни оптического сигнала на кросс-коннекте и тегирование VLAN.

Практический сценарий

Компания Contoso Manufacturing переносит свои ERP-системы в Google Cloud, сохраняя при этом работу локальных производственных площадок. Требования: частное подключение на 20 Гбит/с с переключением при сбое менее чем за секунду, централизованное управление маршрутизацией, исходящий трафик из локальной среды в облако в режиме активный/резервный, частный доступ к Google API без использования публичного интернета и минимальные операционные издержки.

Подход:

Развернуть два канала Dedicated Interconnect в одном мегаполисе в разных пограничных доменах доступности (edge availability domains) и на разных площадках; создать два подключения VLAN (VLAN attachments) на регион (основное и резервное) и связать их с региональным Cloud Router.
- Обоснование: Dedicated Interconnect обеспечивает требуемую совокупную пропускную способность и предсказуемую задержку. Резервные каналы и подключения изолируют сбои и позволяют претендовать на более высокий SLA. Несколько подключений позволяют использовать ECMP и проводить техническое обслуживание без потери трафика.
Настроить один Cloud Router на регион с двумя BGP-пирами — по одному на каждое подключение — и включить BFD.
- Обоснование: Один маршрутизатор упрощает управление плоскостью управления (control-plane), при этом поддерживая ECMP через несколько следующих переходов (next hops). BFD сокращает время обнаружения сбоев до нескольких секунд, улучшая RTO конвергенции для ERP-приложения.
Стандартизировать использование одной и той же удаленной ASN на обоих пограничных маршрутизаторах на производственных площадках, которые устанавливают пиринговые отношения с Google, и анонсировать с каждого из них идентичные префиксы.
- Обоснование: Совпадающие удаленные ASN позволяют Cloud Router устанавливать равноценные пути (equal-cost paths) и балансировать нагрузку при необходимости. Если бы использовались разные ASN, мог бы быть установлен только один набор маршрутов, что сделало бы невозможным использование нескольких путей (multipath).
Реализовать предпочтение активного/резервного пути из локальной среды в Google с помощью MED, а из Google в локальную среду — с помощью приоритета анонсируемого маршрута Cloud Router; установить более низкие значения на основных путях.
- Обоснование: Двусторонняя политика обеспечивает детерминированную направленность: производственные площадки предпочитают основной мегаполис для доступа к облаку, а VPC компании Contoso предпочитает основной ЦОД на площадке для обратного трафика. Это позволяет избежать непреднамеренной асимметрии.
Включить Private Service Connect для Google API в Shared VPC и создать частную DNS-зону, сопоставляющую имена хостов API с конечной точкой PSC; настроить входящую пересылку Cloud DNS, чтобы локальные резолверы могли разрешать эти имена в частном порядке.
- Обоснование: PSC обеспечивает частный доступ к Google API внутри VPC. Гибридный DNS делает эти конечные точки доступными с производственных площадок через Interconnect, исключая доступ через интернет и зависимости от брандмауэра для вспомогательных сервисов ERP.
Для резервного подключения через VPN добавить шлюз HA VPN в каждом регионе с двумя туннелями к разным локальным устройствам; включить BFD на сессиях BGP и разрешить ECMP.
- Обоснование: В случае сбоя Interconnect, HA VPN поддерживает частную доступность. Два туннеля на устройство обеспечивают непрерывность SLA и пропускной способности, а BFD ускоряет переключение при сбое.
Для исходящего трафика частных рабочих нагрузок в интернет и к другим (не Google) ресурсам настроить региональный Cloud NAT на подсетях ERP; не назначать внешние IP-адреса виртуальным машинам.
- Обоснование: Cloud NAT масштабирует трансляцию адресов без накладных расходов на управление ВМ и сохраняет частную адресацию. Удаление внешних IP-адресов гарантирует использование NAT и упрощает контроль исходящего трафика.
Проверить маршрутизацию и отказоустойчивость с помощью поэтапных тестов: отключить одно подключение, затем один локальный маршрутизатор, затем симулировать деградацию канала; отслеживать BGP, BFD и SLO приложений. Настроить таймеры BFD, если происходят сбои сессий («флапы»).
- Обоснование: Контролируемое внесение неисправностей подтверждает, что архитектура соответствует целям по восстановлению и предотвращает неожиданности в производственной среде. Корректировка таймеров позволяет сбалансировать стабильность и скорость реакции.