Google PCNE: Маршрутизация, Network Connectivity Center и сегментация — Руководство по подготовке

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

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

Обзор

В этом разделе рассматриваются маршрутизация, Network Connectivity Center (NCC) и шаблоны сегментации в Google Cloud. Основное внимание уделяется тому, как создаются и выбираются маршруты, как соединять VPC и организации, сохраняя при этом изоляцию, как создавать масштабируемые транзитные архитектуры и схемы с внедрением сервисов, а также как проверять и локализовывать сбои.

Основы и управление маршрутизацией

• Типы маршрутов

  • Системные маршруты для подсетей: По одному для каждого основного и дополнительного диапазона подсети; всегда имеют наивысший приоритет для своих точных префиксов.
  • Маршрут по умолчанию к интернет-шлюзу: Автоматически создается в новых VPC; можно удалить или переопределить.
  • Статические маршруты: Пользовательские префиксы со следующими переходами (next hop), такими как интернет-шлюз по умолчанию, конкретный экземпляр, внутренний балансировщик нагрузки TCP/UDP (ILB) в качестве следующего перехода или туннель Cloud VPN. Маршруты на основе политик добавляют условия соответствия (теги, сервисные аккаунты, протокол/порт) и направляют трафик на экземпляр или ILB в качестве следующего перехода для продвинутого внедрения сервисов.
  • Динамические маршруты: Получаются через Cloud Router по протоколу BGP от Cloud VPN или Cloud Interconnect. Их область действия контролируется режимом динамической маршрутизации VPC (региональным или глобальным).

• Выбор маршрута

  • Сначала выбирается маршрут с самым длинным совпадающим префиксом.
  • Если несколько маршрутов имеют одинаковую длину префикса, приоритет отдается маршруту с наименьшим числовым значением приоритета (по умолчанию 1000 для пользовательских маршрутов). Избегайте пересечений маршрутов с одинаковыми префиксами между статическими и динамическими путями; проектируйте сеть так, чтобы однозначно предпочитать один из путей.
  • Конфликты при одинаковом приоритете разрешаются с помощью внутренних механизмов платформы; не следует на них полагаться.

• Выбор следующего перехода и внедрение сервисов

  • Чтобы централизовать исходящий трафик или внедрять сервисы L3/L7, направьте статический маршрут 0.0.0.0/0 или маршруты на основе политик на ILB в качестве следующего перехода, бэкендами которого являются сетевые виртуальные устройства (NVA).
  • Когда экземплярам без внешних IP-адресов требуется доступ к Google API в обход сетевых устройств, включите Private Google Access для подсетей и добавьте пользовательские статические маршруты для опубликованных диапазонов VIP Google API к интернет-шлюзу по умолчанию. Это сохраняет частный доступ к сервисам Google, в то время как остальной исходящий трафик следует через NGFW.

• Режим динамической маршрутизации и поведение в нескольких регионах

  • Региональный: Маршруты, полученные Cloud Router, устанавливаются только для подсетей в том же регионе.
  • Глобальный: Маршруты, полученные в любом регионе, устанавливаются для всех регионов в VPC, что упрощает межрегиональное взаимодействие и снижает операционные издержки для архитектур «звезда» (hub-and-spoke). Для пользователей и рабочих нагрузок, расположенных вблизи us-east1 и europe-west1, единая VPC с региональными подсетями и глобальной динамической маршрутизацией позволяет им обмениваться данными в частном порядке по RFC1918 с оптимальной эффективностью.

• Управление анонсированием маршрутов

  • Cloud Router может анонсировать все подсети или настраиваемый набор префиксов (включая маршрут по умолчанию) в локальную среду (on-premises). Управляйте выбором входящего пути из локальной среды с помощью стандартных инструментов BGP (MED, AS-path prepending, local preference в локальной среде). Для конфигурации active/standby в направлении локальной среды установите более низкий MED для основного пути и более высокий для резервного.
  • Избегайте анонсирования одного и того же префикса от разных локальных пиров с разными ASN на один и тот же Cloud Router; для ECMP с двойным подключением или чистого переключения при сбое используйте один и тот же ASN пира на резервных локальных маршрутизаторах.

Взаимодействие и сегментация VPC

• VPC Network Peering

  • Обеспечивает частное подключение по RFC1918 между VPC с низкой задержкой и без устройств на уровне передачи данных. По умолчанию обменивается маршрутами подсетей и опционально может импортировать/экспортировать пользовательские маршруты (статические и динамические), чтобы расширить доступность до ресурсов за Cloud VPN/Interconnect. Транзитная маршрутизация отсутствует: маршруты, полученные от одного пира, не передаются другому.
  • Режимы сбоев и ограничения: Не должно быть пересекающихся CIDR-блоков; правила брандмауэра остаются независимыми для каждой VPC; пропускная способность высока, но не заменяет балансировщики нагрузки; асимметричная маршрутизация через ячеистый пиринг не поддерживается. Чтобы соединить три VPC в треугольник, настройте полносвязную топологию (full mesh) пиринговых соединений; соединения «Продажи↔Финансы» и «Маркетинг↔Финансы» не обеспечивают связь «Продажи↔Маркетинг», если между ними также не настроен пиринг.
  • Планирование адресного пространства: При пиринге с VPC в автоматическом режиме (которая резервирует 10.128.0.0/9), создайте пиринговую VPC в пользовательском режиме с непересекающимся CIDR, например 10.0.0.0/9.

• Shared VPC и подключение нескольких проектов

  • Хост-проект владеет VPC; сервисные проекты подключаются к выбранным подсетям. Это централизует сетевые функции и гибридное подключение (Cloud Routers, Cloud NAT, Interconnect), позволяя при этом делегировать владение приложениями по проектам. Размещайте подключения VLAN и Cloud Routers для Dedicated Interconnect в хост-проекте, чтобы обеспечить экономичное, централизованное подключение к локальной среде для всех сервисных проектов.
  • Принцип наименьших привилегий: Администраторы сети (Network Admins) управляют маршрутизацией и подсетями; администраторы безопасности (Security Admins) — правилами и политиками брандмауэра. Если вы не можете обновить правила брандмауэра с ролью Network Admin, запросите роль Security Admin в области видимости Shared VPC.
  • Сегментация: Предоставляйте доступ только к тем подсетям, которые необходимы сервисному проекту. Это соответствует лучшим практикам Google по строгому контролю распространения маршрутов между средами Production и Staging.

• Средства сетевой изоляции

  • Границы VPC: Маршрутизация между VPC отсутствует без явной настройки пиринга, VPN или Private Service Connect. Используйте отдельные VPC для отделов или арендаторов, которые должны быть полностью изолированы; настраивайте пиринг только для тех, кому требуется связь, чтобы минимизировать операционные издержки.
  • Политики брандмауэра: Используйте иерархические политики брандмауэра на уровне организации/папки для создания единых защитных барьеров и правила на уровне VPC для локальных исключений. Правила по умолчанию (запрет входящего трафика, разрешение исходящего) можно ужесточить.
  • Периметры: Используйте VPC Service Controls для ограничения доступа к Google API и снижения рисков утечки данных между проектами и сетями.
  • Доступность по IPv6: Для публичного доступа по IPv6 назначьте адрес IPv6 глобальному внешнему балансировщику нагрузки HTTP(S), который находится перед вашим сервисом. Бэкенды остаются в частной сети.

Network Connectivity Center и транзитные архитектуры

• NCC по схеме «звезда» (hub-and-spoke)

  • Центральный узел (hub) предоставляет уровень управления (control-plane) для маршрутизации между периферийными узлами (spokes). Периферийные узлы включают подключения VLAN (Interconnect), туннели HA VPN, периферийные узлы с виртуальными маршрутизаторами (router appliance spokes) и поддерживаемые периферийные узлы VPC для передачи данных между площадками. Таблицы маршрутизации NCC контролируют, какие префиксы импортируются/экспортируются и какие периферийные узлы их получают, обеспечивая точную сегментацию.
  • Передача данных между площадками (site-to-site) позволяет локальным (on-prem) площадкам взаимодействовать друг с другом через магистральную сеть Google, используя центральный узел в качестве транзитного, что снижает потребность в стороннем транзите и упрощает эксплуатацию.

• Периферийные узлы с виртуальными маршрутизаторами и сторонние NVA

  • Периферийные узлы с виртуальными маршрутизаторами (router appliance spokes) позволяют подключать виртуальные маршрутизаторы/межсетевые экраны, размещенные на Compute Engine, в качестве транзитных или встроенных (inline) сервисов. Используйте ILB в качестве следующего перехода (next hop) для достижения масштабируемости и отказоустойчивости с проверкой работоспособности (health-checked failover) между несколькими устройствами.
  • Проектирование высокой доступности (HA): разверните как минимум два устройства в разных зонах; по возможности разместите их за ILB с MIG; включите IP-форвардинг на инстансах; используйте симметричное управление трафиком (symmetric steering) с ILB в качестве next hop; распределяйте нагрузку с помощью маршрутов на основе политик (policy-based routes), основанных на тегах или сервисных аккаунтах.
  • Компромиссы между пропускной способностью и отказами: производительность NVA ограничена типом инстанса и пропускной способностью сетевого интерфейса (NIC); планируйте горизонтальное масштабирование. Сбой устройства или проверки работоспособности инициирует его удаление из ILB и быстрое переключение на резерв (fast failover), но убедитесь, что таймеры сходимости маршрутов и пороги проверок работоспособности настроены так, чтобы избежать частых переключений (flaps).

• Компромиссы транзитных топологий

  • Схема «звезда» (hub-and-spoke) с NCC: централизованная политика, высокая масштабируемость, четкий контроль радиуса поражения (blast-radius); требует проектирования таблиц маршрутизации и определения намерений импорта/экспорта.
  • Полносвязная топология (full mesh peering): простое решение для небольшого числа VPC, нет центрального транзита, но плохо масштабируется и не обеспечивает транзитивность или встраивание сервисов (service insertion).
  • Централизованный исходящий трафик (egress): простое применение политик безопасности через один NGFW или NAT; может добавлять задержку и становиться узким местом (choke point); можно смягчить с помощью региональных точек выхода и автомасштабирования.
  • Ячеистая сеть (mesh) VPN с Cloud Routers: гибкое и быстрое развертывание; эксплуатационные издержки растут с увеличением числа пиров; рассмотрите использование NCC для консолидации.

• Особенности Cloud VPN

  • Если локальное (on-prem) устройство не поддерживает BGP, используйте Cloud VPN на основе политик (policy-based) со статическими маршрутами и тщательно настроенными селекторами трафика; запланируйте последующий переход на HA VPN с BGP, чтобы минимизировать долгосрочные эксплуатационные издержки.
  • Для туннелей в режиме active/standby в сторону локальной площадки (on-prem) манипулируйте атрибутами MED или AS-path на локальной стороне.
  • При подключении двух локальных маршрутизаторов к одному Cloud Router предпочтительно использовать одинаковые ASN пиров, чтобы разрешить установку обоих путей и ECMP; использование разных ASN пиров обычно приводит к выбору только одного пути.

Эксплуатация: проверка, анализ и локализация сбоев

• Проверка подключения и анализ маршрутов

  • Используйте Connectivity Tests в Network Intelligence Center для трассировки пути данных между ВМ, балансировщиками нагрузки, VPC-пирингом, Cloud VPN и Interconnect, проверяя правила брандмауэра и маршруты.
  • Анализируйте действующие маршруты для каждой ВМ/подсети, чтобы подтвердить следующие переходы (next hops) и динамические префиксы; убедитесь, что область действия режима динамической маршрутизации соответствует намерениям.
  • При проблемах с производительностью или пользовательским опытом отдавайте предпочтение глобальной балансировке нагрузки HTTP(S), чтобы уменьшить задержку для пользователей по всему миру за счет anycast-адресации для входящего трафика и терминирования на границе сети; сетевые балансировщики нагрузки являются региональными и не уменьшают глобальную задержку.

• Локализация сбоев и уменьшение радиуса поражения (blast radius)

  • Сегментируйте с помощью VPC, таблиц маршрутизации NCC и подсетей Shared VPC для каждого проекта, чтобы предотвратить непреднамеренное распространение сбоев или неверных конфигураций.
  • Избегайте транзитивных зависимостей через пиринг; там, где требуется транзит, используйте NCC и контролируемый импорт/экспорт для ограничения доступности.
  • Используйте централизованные политики брандмауэра на уровне организации для базовых правил запрета/разрешения и локальные политики для исключений на уровне приложений; тестируйте изменения с помощью Connectivity Tests.
  • Там, где требуется встроенная (inline) безопасность, развертывайте ILB в качестве следующего перехода (next-hop) с проверками состояния и маршрутизацией на основе политик для отказоустойчивого переключения. Убедитесь, что критически важные Google API доступны через Private Google Access или Cloud NAT без зависимости от внешних IP-адресов.
  • Отслеживайте BGP-сессии и изменения маршрутов; стандартизируйте метрики (MED, local preference) и планы адресации, чтобы избежать колебаний маршрутов и асимметричных потоков.

• Краткие примеры конфигурации

  • Создание статического маршрута для направления трафика через встроенный ILB:

undefined

• Выбор одного из двух входящих BGP-путей к локальной сети с помощью MED (на локальном маршрутизаторе):

undefined

-

undefined

-

undefined

-

undefined

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

Компания Acme Retail работает в организации Google Cloud с несколькими проектами, обслуживая две группы пользователей вблизи регионов us-east1 и europe-west1. Им требуется частное, недорогое взаимодействие между рабочими нагрузками в разных регионах, централизованное подключение к локальной сети и встроенная (inline) URL-фильтрация для исходящего интернет-трафика, при этом отдел финансов (Finance) должен быть изолирован от отдела разработки (Engineering).

1. Создайте единую Shared VPC в хост-проекте с региональными подсетями в us-east1 и europe-west1 и установите режим динамической маршрутизации в global.

• Обоснование: Единая VPC обеспечивает прямое взаимодействие по RFC1918 между регионами без накладных расходов на пиринг. Глобальная динамическая маршрутизация устанавливает полученные гибридные маршруты во всех регионах, упрощая эксплуатацию и обеспечивая эффективные потоки трафика внутри VPC.

2. Предоставьте доступ только к необходимым подсетям каждому сервисному проекту; разместите отделы Finance и Engineering в разных сервисных проектах.

• Обоснование: Предоставление доступа на уровне подсетей обеспечивает организационную сегментацию и минимизирует непреднамеренное раскрытие маршрутов. Отдел Finance остается изолированным благодаря тому, что ему не предоставляется доступ к подсетям отдела Engineering, а также за счет отдельных областей действия политик брандмауэра.

3. Терминируйте Dedicated Interconnect в хост-проекте и подключите Cloud Routers; анонсируйте только необходимые префиксы, используя кастомные объявления (custom advertisements).

• Обоснование: Централизованное гибридное подключение снижает затраты и сложность, сохраняя контроль над тем, какие маршруты достигают локальной сети. Кастомные объявления предотвращают избыточное раскрытие маршрутов и ограничивают радиус поражения.

4. Внедрите встроенное (inline) устройство для URL-фильтрации L7 за региональным внутренним балансировщиком нагрузки TCP/UDP; направляйте исходящий трафик с помощью статического маршрута 0.0.0.0/0 на ILB в качестве следующего перехода (next hop) в каждом регионе.

• Обоснование: Использование ILB в качестве следующего перехода (next hop) вместе с проверками состояния обеспечивает высокодоступное внедрение сервиса с симметричными потоками трафика через устройства. Статические маршруты с более высоким приоритетом, чем у маршрута по умолчанию, гарантируют, что весь исходящий трафик будет отфильтрован.

5. Убедитесь, что экземпляры без внешних IP-адресов могут напрямую обращаться к Google API: включите Private Google Access на всех подсетях и добавьте статические маршруты для диапазонов VIP Google API к шлюзу интернета по умолчанию, чтобы обойти устройство фильтрации.

• Обоснование: Private Google Access сохраняет частный доступ к BigQuery и Pub/Sub; кастомные маршруты предотвращают ненужный “заворот” трафика (hairpinning) через фильтр, снижая затраты и задержку.

6. Изолируйте отдел Finance: запретите трафик между проектами в иерархических политиках брандмауэра и не настраивайте пиринг между проектами Finance и Engineering. Там, где необходимо взаимодействие между Engineering и Analytics, создайте выделенную пару VPC с пирингом и непересекающимися CIDR-блоками.

• Обоснование: Границы VPC, отсутствие пиринга и политики брандмауэра на уровне организации обеспечивают изоляцию. Целевой пиринг предлагает низкие операционные издержки для специфических подключений между отделами без транзитивности.

7. Проверяйте и отслеживайте: используйте Connectivity Tests для проверки межрегиональной доступности и внедрения устройства; отслеживайте состояние BGP и таблицы маршрутов в Cloud Router; реализуйте MED на локальных маршрутизаторах для отказоустойчивого переключения active/standby при наличии нескольких туннелей.

• Обоснование: Проактивная проверка позволяет выявлять неверные конфигурации на ранней стадии. Управление BGP обеспечивает детерминированность путей к локальной сети во время обслуживания или сбоев, а телеметрия NCC/Cloud Router ускоряет поиск и устранение неисправностей.

Эта архитектура отвечает требованиям Acme Retail с минимальными затратами и высокой эффективностью: частная межрегиональная маршрутизация в одной VPC, централизованное гибридное подключение, контролируемое внедрение сервисов и строгая организационная сегментация.

← Приватное подключение к Google и управляемым сервисам · Все домены · GKE →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Google →