Google ACE: Сети VPC, подключения и управление трафиком — Руководство по подготовке

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Обзор

Сеть Virtual Private Cloud (VPC) в Google Cloud предоставляет программно-определяемые глобальные сетевые примитивы с детальным контролем адресации, маршрутизации, безопасности и управления трафиком. В этом разделе рассматриваются практические вопросы проектирования и эксплуатации, которые вы будете использовать для создания отказоустойчивых, безопасных и наблюдаемых сетей, соединяющих сервисы Google Cloud, локальные среды и публичный интернет.

Основная архитектура VPC и планирование IP-адресации

• Сети VPC и подсети

  • VPC — это глобальный ресурс; его подсети являются региональными и могут охватывать несколько зон. Экземпляры в любой зоне региона могут использовать одну и ту же подсеть.
  • Для производственных сред используйте VPC в пользовательском режиме (custom mode). Автоматический режим (auto mode) предварительно создает по одной подсети в каждом регионе, используя предопределенный набор CIDR-диапазонов, что может привести к ограничениям из-за пересекающихся IP-адресов, нерациональному использованию адресного пространства и сложностям при рефакторинге в будущем.
  • Дополнительные (secondary) IP-диапазоны в подсетях позволяют использовать IP-адреса для подов/сервисов GKE и IP-псевдонимы (alias IP) для ВМ. Планируйте основные и дополнительные CIDR-диапазоны заранее, чтобы избежать перенумерации.

• Планирование IP-адресов

  • Выбирайте непересекающееся адресное пространство RFC1918 для всех текущих и будущих сетей VPC и локальных сетей, которые вы можете подключить. Зарезервируйте блоки адресов для будущего роста в новых регионах и для новых сервисов.
  • Подбирайте правильный размер подсетей (например, от /24 до /20) с учетом роста и избегайте слишком больших диапазонов, которые усложняют ACL и диагностику.
  • Документируйте использование IP-адресов: основные диапазоны для рабочих нагрузок, дополнительные диапазоны для GKE и зарезервированные блоки для пулов NAT или конечных точек сервисов.

• Пример

undefined

undefined

Маршрутизация, брандмауэры и иерархия политик

• Маршруты и режимы динамической маршрутизации

  • Каждая сеть VPC имеет таблицу маршрутизации, состоящую из системных маршрутов подсетей, маршрутов по умолчанию, а также пользовательских статических или динамических маршрутов.
  • Режим динамической маршрутизации:
    • Региональный (Regional): динамические маршруты (BGP), полученные через Cloud Router, могут использоваться только ресурсами в том же регионе.
    • Глобальный (Global): динамические маршруты могут использоваться ресурсами во всех регионах VPC. Предпочитайте глобальный режим для гибридных сетей, которым требуется доступ к локальной среде из нескольких регионов.
  • Следующие переходы (next hops): интернет-шлюз по умолчанию (0.0.0.0/0), VPN-туннель, Cloud Router (BGP), экземпляр (маршрутизирующее устройство) или внутренний балансировщик нагрузки в качестве следующего перехода для виртуальных устройств.
  • Приоритет маршрута: чем меньше число, тем выше приоритет. Неправильно настроенные приоритеты могут привести к потере трафика (blackhole) или направить его на непредусмотренный следующий переход. Используйте четкие соглашения (например, 1000 для исходящего трафика по умолчанию, 900 для более специфичных маршрутов).

• Иерархия брандмауэров

  • Правила брандмауэра VPC работают с отслеживанием состояния (stateful) и оцениваются до пересылки пакетов. Они существуют на уровне VPC и применяются ко всем подсетям.
  • Иерархические политики брандмауэра (применяемые на уровне организации, папки или проекта) применяют правила разрешения/запрета до правил VPC. Используйте их для реализации централизованных защитных барьеров (например, для запрета доступа к административным портам из интернета).
  • Неявные правила: существуют неявное правило, разрешающее исходящий трафик (allow egress), и неявное правило, запрещающее входящий трафик (deny ingress), с самым низким приоритетом; их нельзя удалить. Для любого соединения требуется явное разрешающее правило для входящего трафика.

• Правила брандмауэра, теги, сервисные аккаунты, безопасные теги

  • Нацеливание: используйте сетевые теги или сервисные аккаунты для применения правил к определенным ВМ; нацеливание на сервисные аккаунты обеспечивает более строгий контроль на основе идентификационных данных.
  • Безопасные теги (Secure tags) предоставляют централизованно управляемые, защищенные с помощью IAM метки для нацеливания политик; они предотвращают самостоятельное присвоение тегов рабочими нагрузками и поддерживают сегментацию по принципу нулевого доверия (zero-trust).
  • Ведение журналов: включайте ведение журналов брандмауэра выборочно для наиболее важных правил, чтобы сбалансировать наблюдаемость и затраты; регистрируйте выборочные пакеты, а не полные данные.
  • Распространенные сценарии сбоев: отсутствие диапазонов источников для проверок состояния, асимметричная маршрутизация, приводящая к потере ответных пакетов, слишком широкие диапазоны источников, создающие непреднамеренное раскрытие.

• Пример

undefined

Балансировка нагрузки, IP-адреса, DNS и управление трафиком

• Типы и поведение Cloud Load Balancing

  • Глобальные прокси-балансировщики: External HTTP(S), External TCP Proxy, External SSL Proxy. Завершают клиентские соединения на границе сети Google, поддерживают глобальные VIP-адреса anycast и вставляют заголовки (например, X-Forwarded-For). Исходный IP-адрес клиента доступен через заголовки или протокол PROXY (для TCP), а не сохраняется как источник на уровне L3.
  • Региональные сквозные (passthrough) балансировщики: External Network Load Balancer и Internal TCP/UDP Load Balancer маршрутизируют трафик на уровне L4 и сохраняют IP-адрес клиента. Используйте их, когда требуется видимость исходного IP на бэкендах без использования протокола PROXY.
  • Internal HTTP(S) Load Balancer: региональный прокси-сервер L7 для внутренних сервисов с расширенными возможностями маршрутизации и mTLS.

• Бэкенд-сервисы, проверки работоспособности и политики трафика

  • Бэкенд-сервисы определяют бэкенды (группы экземпляров, NEG/VM/Endpoint, сервисы GKE), режим балансировки (UTILIZATION или RATE), ограничения пропускной способности, привязку сессий (session affinity) и плавное отключение соединений (connection draining).
  • Проверки работоспособности (health checks) должны быть разрешены в правилах брандмауэра для IP-адресов проверяющих систем Google. Неработоспособные бэкенды автоматически удаляются; неправильно настроенные проверки могут привести к полному отказу сервиса.
  • Политики трафика включают локальность (регион/зона), бэкенды для переполнения (overflow) и аварийного переключения (failover), а также взвешенное разделение трафика для постепенного развертывания на некоторых типах балансировщиков.

• Внешние и внутренние IP-адреса, правила пересылки

  • Внешние и внутренние адреса могут быть временными (ephemeral) или зарезервированными статическими. Глобальные статические внешние адреса используются глобальными балансировщиками; большинство других адресов являются региональными.
  • Правила пересылки (forwarding rules) сопоставляют пару IP:порт с целевым объектом (например, targetHttpProxy или бэкенд-сервисом). Выбирайте глобальные или региональные правила в соответствии с типом балансировщика; несоответствие не позволит создать правило.

• Cloud DNS

  • Зоны: публичные зоны разрешаются в общедоступном интернете; частные зоны разрешаются только из авторизованных сетей VPC. Используйте управляемые записи (A/AAAA, CNAME, TXT, MX, SRV и т. д.).
  • Split-horizon (разделение DNS-горизонтов): создайте публичную и частную зоны для одного и того же домена, чтобы внутренние резолверы получали частные ответы (например, IP-адрес внутреннего балансировщика), а публичные пользователи — IP-адреса, доступные из интернета.
  • Пересылка частных DNS-запросов: используйте политики Cloud DNS для входящей и исходящей пересылки для интеграции с локальными (on-prem) резолверами; используйте DNS peering между сетями VPC для совместного использования частных зон без необходимости полного пирингового соединения.

• Пример

undefined

Гибридные и частные подключения

• Cloud Router, Cloud NAT и Private Google Access

  • Cloud Router обменивается маршрутами с локальной средой (on-prem) по протоколу BGP, анонсирует подсети VPC и импортирует локальные префиксы. Используйте глобальную динамическую маршрутизацию, когда нескольким регионам требуется доступ к on-prem.
  • Cloud NAT обеспечивает исходящий доступ в интернет для частных ВМ и узлов GKE без внешних IP-адресов. Правильно рассчитайте размер пула IP-адресов NAT, чтобы избежать исчерпания портов; отслеживайте журналы на предмет сброшенных соединений и соответствующим образом масштабируйте количество адресов.
  • Private Google Access (PGA) позволяет частным ВМ обращаться к API Google без внешних IP-адресов по маршруту по умолчанию. Private Service Connect (PSC) для API Google предоставляет конечные точки с частными IP-адресами в вашей сети VPC с контролем политик и полностью исключает исходящий публичный трафик; отдавайте предпочтение конечным точкам PSC для более строгого контроля исходящего трафика и согласованности DNS.

• Private Service Connect (сервисы-производители и сервисы-потребители)

  • Публикуйте внутренние сервисы через service attachment в проекте-производителе и используйте их через частные конечные точки (private endpoints) в проектах-потребителях. Доступ контролируется с помощью сопоставления DNS и явных разрешающих политик. Это улучшает изоляцию по сравнению с VPC Peering и централизует публикацию сервисов.

• VPC Network Peering, Shared VPC и сегментация

  • VPC Peering обеспечивает частное соединение между сетями VPC с низкой задержкой. Оно не транзитивно и не допускает пересечения IP-адресов. Опциональный импорт/экспорт кастомных маршрутов расширяет доступность, но все равно не создает транзитивную маршрутизацию; тщательно планируйте архитектуру “звезда” (hub-and-spoke).
  • Shared VPC позволяет централизовать подсети в хост-проекте для использования сервисными проектами. Это обеспечивает централизованную маршрутизацию, брандмауэры, NAT и балансировщики нагрузки, делегируя при этом IAM для каждого приложения. Комбинируйте с иерархическими правилами брандмауэра и безопасными тегами для сегментации.
  • Network Connectivity Center (NCC) предоставляет центральный узел (hub) для оркестрации периферийных подключений (spokes) (VPN, Interconnect, router appliance, VPC spokes) и единообразного управления топологиями корпоративных сетей WAN.

• Cloud VPN, Cloud Interconnect и BGP

  • Cloud VPN: используйте HA VPN с динамической маршрутизацией (BGP) для обеспечения высокой доступности и автоматического переключения маршрутов при сбое. По возможности создавайте по два туннеля для каждого пира через независимые интерфейсы Cloud VPN и разные локальные устройства/каналы.
  • Cloud Interconnect: Dedicated Interconnect предоставляет частные каналы 10–100 Гбит/с; Partner Interconnect использует услуги сервис-провайдера. для отказоустойчивости развертывайте резервные соединения Interconnect в разных доменах доступности (edge availability domains) и используйте BFD с BGP там, где это поддерживается.
  • Домены отказа (Failure domains): изолируйте по региону, зоне, устройству и провайдеру. Регулярно тестируйте аварийное переключение; асимметричные пути могут нарушить работу локальных межсетевых экранов с отслеживанием состояния (stateful firewalls).

• Примеры

undefined

undefined

undefined

Наблюдаемость и устранение неисправностей

• Тесты связности (Connectivity Tests)
  • Моделирование и проверка доступности между источниками и назначениями в разных VPC, в локальной среде (через гибридные подключения) и через балансировщики нагрузки. Инструмент анализирует маршруты, правила брандмауэра и конфигурацию для обнаружения потерь или неверно направленного трафика до внесения изменений в производственную среду.
  • Пример:

undefined

• VPC Flow Logs

  • Включаются на уровне подсети для получения в реальном времени информации о потоках (5-tuple), байтах, потерях и задержках. Экспортируются в Cloud Logging, Pub/Sub или BigQuery для аналитики. Настраивайте уровень выборки и метаданных для контроля затрат.
  • Сценарии использования: проверка эффективности брандмауэра, обнаружение утечки данных, планирование емкости и мониторинг SLO.

• Packet Mirroring

  • Зеркалирование трафика VM или GKE на эндпоинты-сборщики для глубокого анализа пакетов (DPI) или систем обнаружения вторжений (IDS). Ограничивайте область зеркалирования подсетью, тегом или экземпляром. Учитывайте снижение производительности и убедитесь, что сборщики могут обрабатывать объем зеркалируемого трафика. Избегайте зеркалирования трафика после NAT, если вам нужны исходные заголовки.

• Распространенные сценарии диагностики

  • Черная дыра (Blackhole): маршрут существует, но обратный путь заблокирован брандмауэром или асимметричной маршрутизацией; проверяйте с помощью Connectivity Tests и VPC Flow Logs с обеих сторон.
  • Сбои проверок работоспособности (Health check): убедитесь, что брандмауэр разрешает трафик от проверяющих систем (health-checkers) и что бэкенды прослушивают правильные порты; протестируйте локально с ВМ в той же подсети.
  • Исчерпание портов NAT: ищите отклоненные потоки с причиной “no available NAT ports”; добавьте больше IP-адресов для NAT или уменьшите лимиты портов на одну ВМ.

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

Компания Acme Retail управляет мультирегиональной e-commerce платформой с приватными бэкендами, публичной точкой входа и локальной ERP-системой. Им необходимо сегментировать рабочие нагрузки, обеспечить приватный исходящий трафик к Google API, организовать гибридную связность из всех регионов и усилить безопасность, сохраняя при этом наблюдаемость.

1. Создание Shared VPC в режиме custom для централизованного управления

undefined

• Обоснование: Режим custom позволяет избежать автоматически назначаемых CIDR-блоков и обеспечивает продуманное планирование IP-адресации. Shared VPC централизует маршрутизацию, брандмауэры и NAT в хост-проекте, позволяя сервисным проектам безопасно развертывать ресурсы.

2. Планирование и создание подсетей со вторичными диапазонами для GKE

undefined

• Обоснование: Непересекающиеся основной и вторичные диапазоны предотвращают будущие конфликты пиринга и позволяют использовать alias IP для GKE без исчерпания IP-адресов.

3. Установка глобального режима динамической маршрутизации для VPC и развертывание Cloud Router

undefined

undefined

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

4. Настройка HA VPN для подключения к локальной сети и анонсирование подсетей

• Создайте два туннеля HA VPN через разные локальные устройства. Используйте BGP для обмена префиксами и обеспечения плавного переключения при сбое.
• Обоснование: Два туннеля устраняют единую точку отказа; BGP обеспечивает быструю сходимость маршрутов во время обслуживания или сбоев.

5. Развертывание Cloud NAT для приватного исходящего трафика и PSC для Google API

undefined

• Создайте эндпоинты Private Service Connect для Google API и обновите приватный DNS, чтобы сопоставить эндпоинты API с PSC.
• Обоснование: NAT обеспечивает исходящий доступ в интернет без внешних IP-адресов у ВМ; PSC направляет трафик к API по приватным IP-адресам под явным контролем политик, устраняя пути выхода в публичный интернет.

6. Фронтенд через глобальный External HTTP(S) Load Balancer; внутренние сервисы через Internal HTTP(S)

• Создайте глобальный внешний HTTP(S) LB с управляемым сертификатом и бэкенд-сервисом, указывающим на NEG-бэкенды.
• Создайте региональные Internal HTTP(S) LB для трафика между сервисами с использованием mTLS между микросервисами.
• Обоснование: Глобальный прокси-балансировщик обеспечивает anycast, автомасштабирование и CDN; внутренний L7-балансировщик предлагает расширенные возможности маршрутизации и безопасности для трафика “восток-запад”.

7. Внедрение иерархических политик брандмауэра и таргетинга по идентификаторам рабочих нагрузок

• Примените политику на уровне организации, запрещающую доступ к административным портам из интернета; разрешите доступ только источникам проверок работоспособности балансировщика.
• Создайте правила VPC, нацеленные на сервисные аккаунты, для реализации принципа наименьших привилегий между уровнями; используйте безопасные теги (secure tags) для динамической сегментации.
• Обоснование: Иерархия позволяет централизованно применять защитные ограничения; таргетинг на основе идентификаторов устойчив к подмене тегов и упрощает автоматизацию.

8. Настройка Cloud DNS с разделением зон (split-horizon) и перенаправлением

• Создайте публичную зону acme.com для VIP-адреса веб-сервиса и приватную зону acme.com для сопоставления внутренних имен сервисов с ILB.
• Настройте исходящее перенаправление на локальный DNS и входящее, чтобы локальная сеть могла разрешать имена из приватных зон.
• Обоснование: Разделение зон (split-horizon) предотвращает утечку данных и обеспечивает корректное разрешение имен в зависимости от исходной сети; перенаправление интегрирует унаследованные пространства имен.

9. Использование Connectivity Tests, VPC Flow Logs и Packet Mirroring для обеспечения видимости

• Создайте тесты для критически важных путей (пользователь -> веб-балансировщик, веб-сервис -> внутренние сервисы, сервисы -> локальная ERP).
• Включите VPC Flow Logs на подсетях; экспортируйте данные в BigQuery для анализа тенденций. Временно включайте Packet Mirroring во время реагирования на инциденты.
• Обоснование: Проактивная проверка и телеметрия сокращают среднее время восстановления (MTTR), выявляют неверные конфигурации и предоставляют информацию для планирования емкости.

10. Документирование и тестирование сценариев сбоя

• Смоделируйте потерю VPN-туннеля, региона и бэкенда MIG. Проверьте переключение BGP, удаление бэкенда из балансировщика по результатам health-check и корректность работы DNS.
• Обоснование: Регулярные учения (game days) подтверждают предположения о резервировании и выявляют дрейф конфигурации до того, как он приведет к сбоям.

← Контейнеры · Все домены · Хранилища →

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

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