Справочник - PCNE Google Cloud Professional Cloud Network Engineer
Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене PCNE. Читайте сверху вниз или переходите к нужному разделу.
Домен 1: Проектирование и планирование сети VPC
Планирование IP-адресации для крупномасштабных или гибридных облачных развертываний.
Используйте VPC в пользовательском режиме. Выделяйте непересекающиеся блоки CIDR RFC 1918 (например, 172.16.0.0/12), чтобы избежать конфликтов с локальной сетью (часто 10.0.0.0/8). Используйте 100.64.0.0/10 для вторичных диапазонов подов GKE.
Почему: Позволяет избежать конфликтов IP-адресов с локальной сетью для будущей гибридной связи и обеспечивает полный контроль над адресным пространством, что крайне важно для масштабирования и предотвращения дорогостоящего переадресования IP-адресов.
Обеспечение сетевой изоляции для нескольких клиентов/сред (разработка, производство) при централизации управления сетью и общих сервисов.
Используйте Shared VPC. Хост-проект содержит VPC, подсети, межсетевые экраны и межсоединения. Клиенты/среды являются сервисными проектами, прикрепленными к хост-проекту.
Почему: Централизует сетевое администрирование в хост-проекте, делегируя управление ресурсами сервисным проектам. Более масштабируемо и управляемо, чем VPC peering для многих проектов в организации.
Планирование IP-адресации для больших кластеров GKE с использованием VPC-native сети.
В VPC в пользовательском режиме запланируйте три диапазона CIDR: основной диапазон для узлов, вторичный диапазон для Pods и еще один для Services. Для расширения используйте несмежный мульти-под CIDR.
Почему: VPC-native сеть требует выделенных, непересекающихся вторичных диапазонов для подов и сервисов. Правильное определение размера предотвращает исчерпание IP-адресов, что является частой и разрушительной проблемой в больших кластерах.
Виртуальные машины без внешних IP-адресов должны получать доступ к Google Cloud API (например, Cloud Storage, BigQuery).
Включите Private Google Access в подсети. При желании настройте DNS для разрешения `*.googleapis.com` в `restricted.googleapis.com` (199.36.153.4/30) для принудительного использования VPC-SC.
Почему: Маршрутизирует трафик к Google API через внутреннюю сеть Google без необходимости использования публичных IP-адресов на виртуальных машинах. Использование `restricted.googleapis.com` добавляет уровень защиты от утечки данных.
Предоставление приватного доступа к сервису в вашем VPC для потребителей (партнеров, других бизнес-подразделений), чьи VPC имеют пересекающиеся диапазоны IP-адресов.
Опубликуйте сервис (через Internal Load Balancer), используя Private Service Connect (PSC) service attachment. Потребители создают PSC endpoint в своем VPC с IP-адресом из собственного диапазона.
Почему: PSC разделяет сети производителя и потребителя, используя NAT для обработки пересекающихся IP-адресов. Он обеспечивает безопасный доступ на уровне сервиса, а не полное сетевое соединение, как VPC peering.
Подключение большого количества (50+) VPC и/или локальных сайтов в топологии "звезда" для централизованного управления и подключения.
Используйте Network Connectivity Center. Настройте хаб и подключите VPC как VPC spokes, а локальные соединения (VPN/Interconnect) как hybrid spokes.
Почему: NCC - это управляемое решение Google для крупномасштабных топологий "звезда", упрощающее управление маршрутами и масштабирование за пределы лимита в 25 пиров для VPC peering.
Развертывание кластера GKE, где узлы и управляющий план не имеют публичных IP-адресов для повышения безопасности.
Создайте Private GKE cluster. Это присваивает узлам только внутренние IP-адреса и создает приватную конечную точку для управляющего плана. Настройте авторизованные сети для ограничения доступа к управляющему плану.
Почему: Приватный кластер удаляет управляющий план и узлы из публичного интернета, значительно уменьшая поверхность атаки. Весь трафик управления и рабочих нагрузок остается в приватной сети.
Бессерверным рабочим нагрузкам (Cloud Run, Functions) требуется доступ к ресурсам (например, Cloud SQL, Memorystore) внутри VPC.
Создайте Serverless VPC Access connector в целевом VPC. Настройте бессерверный сервис на использование этого коннектора для исходящего трафика.
Почему: Коннектор действует как прокси, позволяя бессерверным сервисам (которые работают в управляемой Google среде) отправлять трафик в управляемый клиентом VPC, используя внутренние IP-адреса.
Приложение (например, HPC, финансовый трейдинг) требует минимальной задержки сети между группой виртуальных машин.
Создайте политику компактного размещения и примените ее к виртуальным машинам. Используйте типы машин с сетью Tier_1.
Почему: Размещение виртуальных машин в одной сетевой стойке минимизирует сетевые переходы и физическое расстояние, значительно сокращая задержку по сравнению со стандартным размещением виртуальных машин.
Реализация модели безопасности "нулевого доверия" для микросервисов, требующей строгой идентификации, зашифрованной связи (mTLS) и детализированной авторизации.
Разверните Anthos Service Mesh. Включите автоматический mTLS для всего взаимодействия сервис-сервис. Используйте ресурсы `AuthorizationPolicy` для определения разрешенного взаимодействия.
Почему: Service Mesh отделяет безопасность от базовой сети, предоставляя идентификацию рабочей нагрузки, прозрачный mTLS и авторизацию L7, которые являются ключевыми принципами архитектуры "нулевого доверия".
Домен 2: Реализация сети VPC
Рабочим нагрузкам (ВМ, GKE подам) без публичных IP-адресов требуется стабильный, предсказуемый исходный IP-адрес для исходящих подключений к внешним API, использующим белый список.
Почему: Cloud NAT с ручным выделением предоставляет общий пул статических исходящих IP-адресов. Это отделяет рабочую нагрузку от IP-адреса, позволяя масштабировать без необходимости обновления внешних белых списков.
VPC peering установлен, но виртуальные машины не могут обмениваться данными между пиринговыми VPC.
Убедитесь, что правила межсетевого экрана в *обоих* VPC разрешают входящий трафик из диапазона IP-адресов другого VPC. Пиринговое соединение только устанавливает маршрутизацию; оно не создает неявно разрешающих правил межсетевого экрана.
Почему: Распространенная ошибка - предполагать, что пиринг открывает порты межсетевого экрана. Неявное правило deny-all для входящего трафика блокирует трафик до тех пор, пока не будет создано явное правило allow.
В Shared VPC предоставьте команде/сервисному проекту разрешение использовать только определенную подсеть, а не весь VPC.
В хост-проекте предоставьте роль IAM `compute.networkUser` идентификатору сервисного проекта (например, сервисной учетной записи, группе) на уровне ресурса подсети.
Почему: Роли IAM могут быть применены к конкретным ресурсам. Применение `compute.networkUser` на уровне подсети обеспечивает принцип наименьших привилегий, позволяя использовать только эту подсеть.
Реализация микросегментации для многоуровневого приложения (например, веб, приложение, база данных) в Compute Engine.
Присвойте сетевые теги виртуальным машинам на основе их уровня (например, `web-server`). Создайте правила межсетевого экрана, которые используют эти теги в качестве исходных и целевых спецификаторов.
Почему: Теги предоставляют гибкую, масштабируемую альтернативу правилам на основе IP. Политика межсетевого экрана не зависит от количества или IP-адресов виртуальных машин на уровне.
Сбор метаданных трафика для соответствия/аудита при минимизации объема журналов и затрат на хранение.
Включите VPC Flow Logs с более длительным интервалом агрегации (например, 10 минут), уменьшенной частотой выборки (например, 0.5) и фильтрацией метаданных для исключения ненужных полей.
Почему: Настройки по умолчанию генерируют огромные объемы данных. Настройка этих параметров значительно снижает затраты, при этом обеспечивая достаточную видимость для большинства случаев использования аудита.
Домен 3: Настройка управляемых сетевых сервисов
Предоставление глобального приложения с низкой задержкой, маршрутизация пользователей к ближайшему работоспособному бэкенду с автоматическим переключением.
Используйте Global External Application Load Balancer (или TCP/SSL Proxy LB для не-HTTP). Настройте бэкенд-сервисы/NEGs в нескольких регионах. Используйте сеть Premium Tier.
Почему: Anycast IP балансировщика нагрузки направляет пользователей к ближайшему пограничному PoP Google. Затем трафик проходит по частной магистрали Google к ближайшему работоспособному бэкенду для оптимальной производительности.
Маршрутизация внутреннего трафика на основе пути URL или имени хоста, с завершением SSL, доступная только внутри VPC или из локальной сети.
Используйте Regional Internal Application Load Balancer. Настройте карту URL для маршрутизации трафика на основе правил хоста/пути. Требует подсети только для прокси.
Почему: Это управляемый Google внутренний балансировщик нагрузки L7. Он предоставляет расширенные функции маршрутизации, недоступные в L4 Internal Passthrough Network LB.
Использование Cloud CDN для кэширования и предоставления приватного или специфичного для пользователя контента без публикации.
Включите Cloud CDN на приватном бэкенде (например, GCS bucket). Генерируйте Cloud CDN Signed URLs или Signed Cookies в вашем приложении, чтобы предоставить пользователям временный, аутентифицированный доступ.
Почему: Подписанные URL/Cookies предоставляют безопасный токен, который Cloud CDN проверяет перед отдачей кэшированного объекта, используя кэширование на границе сети при сохранении строгого контроля доступа.
Включение двунаправленного разрешения DNS между локальной сетью и GCP VPC.
1) Локальная сеть разрешает GCP: Создайте политику входящего сервера Cloud DNS. Настройте локальный DNS для перенаправления на входящие IP-адреса пересылки. 2) GCP разрешает локальную сеть: Создайте зону пересылки Cloud DNS, которая указывает на локальные DNS-серверы.
Почему: Эта стандартная двухкомпонентная конфигурация обеспечивает бесшовное, приватное разрешение имен для гибридных сред, что является критически важным компонентом для взаимодействия приложений.
Коэффициент попадания в кэш Cloud CDN низок из-за ненужных вариаций URL (например, параметров отслеживания).
Настройте пользовательскую политику ключа кэша для бэкенд-сервиса. Исключите несущественные параметры запроса, куки и заголовки из ключа кэша.
Почему: По умолчанию, полный URL является ключом кэша. Нормализация ключа путем исключения нерелевантных параметров предотвращает фрагментацию кэша и значительно улучшает коэффициент попадания.
Разрешение DNS-имени во внутренний IP для внутренних клиентов и в публичный IP для внешних клиентов.
Создайте приватную зону Cloud DNS для домена (видимую для вашего VPC) с записью внутреннего IP. Создайте соответствующую публичную зону Cloud DNS с записью публичного IP.
Почему: Cloud DNS автоматически отправляет ответ из приватной зоны клиентам внутри авторизованного VPC, а ответ из публичной зоны - всем остальным.
Внутреннее приложение в одном регионе должно быть доступно клиентам (ВМ, локальная сеть) в других регионах.
Включите опцию "Global Access" для правила пересылки Internal TCP/UDP Load Balancer или Internal Application Load Balancer.
Почему: По умолчанию внутренние балансировщики нагрузки являются региональными. Global Access делает их доступными из любого региона в сети VPC, упрощая архитектуры внутренних сервисов, охватывающих несколько регионов.
Домен 4: Реализация гибридного и мультиоблачного взаимодействия
Установление высокодоступного (SLA 99.99%), высокоскоростного (10G+) подключения между локальной сетью и GCP.
Предусмотрите минимум четыре Dedicated Interconnect соединения: два в одном метрополитене и два в другом, причем каждая пара в метрополитене должна находиться в разных зонах доступности на границе сети. Настройте BGP.
Почему: Избыточность в разных метрополитенах и доменах отказа (зонах доступности на границе сети) требуется для SLA 99.99%.
Требуется зашифрованное, надежное (SLA 99.9% или 99.99%) и быстро развертываемое гибридное соединение с умеренной пропускной способностью (< 6 Гбит/с).
Используйте HA VPN с BGP для динамической маршрутизации. Для SLA 99.99% используйте два шлюза HA VPN. Для SLA 99.9% используйте один шлюз с двумя туннелями.
Почему: HA VPN быстрее настраивается, чем Interconnect, обеспечивает высокий SLA и достаточную пропускную способность для многих случаев использования, что делает его выбором по умолчанию для нефизических соединений.
Шифрование всего трафика, проходящего через Dedicated или Partner Interconnect соединение, для соответствия требованиям.
Настройте HA VPN поверх Interconnect. Создайте туннели HA VPN, которые используют VLAN attachments Interconnect для их основного транспорта.
Почему: Этот шаблон сочетает высокую пропускную способность и низкую задержку Interconnect с IPsec шифрованием HA VPN, обеспечивая лучшее из обоих миров.
Установление выделенного, приватного, высокоскоростного соединения между GCP и другим крупным облачным провайдером (AWS, Azure, OCI).
Используйте Cross-Cloud Interconnect. Обеспечьте выделенное физическое соединение между сетью Google и сетью другого облачного провайдера. Настройте BGP с Cloud Router.
Почему: Обеспечивает прямой, поддерживаемый SLA, низколатентный путь между облаками, избегая публичного интернета и переменной производительности VPN.
Локальной сети, подключенной через Interconnect к одному региону GCP, требуется доступ к ресурсам во всех других регионах GCP.
Включите режим динамической маршрутизации "Global" в VPC. Cloud Router будет затем анонсировать маршруты для всех подсетей в VPC, а не только для тех, что находятся в его локальном регионе.
Почему: Глобальная маршрутизация позволяет единой точке гибридного подключения служить входом в всю глобальную сеть Google, упрощая многорегиональный доступ.
Влияние на выбор пути трафика через избыточные гибридные соединения (VPN/Interconnect) с использованием BGP.
Чтобы повлиять на трафик из GCP в локальную сеть, настройте локальную сеть на анонсирование более специфичных маршрутов или используйте более короткий AS_PATH для предпочтительного пути. Чтобы повлиять на трафик из локальной сети в GCP, анонсируйте с Cloud Router с более низким значением MED для предпочтительного пути.
Почему: Выбор пути BGP следует четкому алгоритму. Самое длинное совпадение префикса является ключевым для исходящего трафика, тогда как MED влияет на решения по входящему трафику.
Настройка активно/пассивного переключения при отказе между основным Dedicated Interconnect и резервным HA VPN.
Используйте BGP на обоих. В Cloud Router анонсируйте маршруты через Interconnect с более низким базовым приоритетом (например, 100) и через VPN с более высоким базовым приоритетом (например, 200).
Почему: GCP предпочитает маршруты BGP с более низким значением приоритета (более высоким предпочтением). Трафик использует основной Interconnect. В случае сбоя его маршруты отзываются, и резервные маршруты VPN становятся активными.
Домен 5: Реализация сетевой безопасности
Предотвращение утечки данных из чувствительных сервисов Google Cloud (например, BigQuery, GCS), обеспечивая доступ только из авторизованных сетей.
Внедрите VPC Service Controls. Создайте периметр сервиса вокруг проектов с чувствительными данными. Настройте уровни доступа для определения авторизованных источников (диапазоны IP-адресов, состояние устройства, идентификатор).
Почему: VPC-SC создает виртуальную границу сети вокруг управляемых Google сервисов, блокируя доступ из-за периметра даже при наличии действительных учетных данных. Важный контроль управления данными.
Принудительное применение согласованных, неизменяемых базовых правил межсетевого экрана по всей организации, при этом допуская настройку на уровне проекта.
Реализуйте иерархические политики межсетевого экрана на уровне организации или папки. Разместите здесь критические правила. Используйте действие `goto_next` для делегирования оценки политикам нижнего уровня.
Почему: Иерархические политики оцениваются до правил уровня VPC и не могут быть изменены владельцами проектов, что обеспечивает централизованное управление. `goto_next` обеспечивает гибкость.
Защита веб-приложения от уязвимостей OWASP Top 10 и применение ограничения скорости на основе IP-адреса клиента.
Прикрепите политику безопасности Cloud Armor к Global External Application LB. Примените предварительно настроенные правила WAF (например, `sqli-v3.3-stable`) и добавьте правило на основе скорости.
Почему: Cloud Armor обеспечивает безопасность на границе сети. Предварительно настроенные правила WAF предлагают управляемую защиту, а правила на основе скорости снижают риски DoS и атак методом перебора.
Реализация детализированной сетевой безопасности на уровне пода внутри кластера GKE на основе меток.
Включите принудительное применение Network Policy в кластере GKE. Создайте ресурсы Kubernetes `NetworkPolicy`, которые определяют правила ingress/egress для подов, используя селекторы меток.
Почему: Kubernetes NetworkPolicy - это нативный способ реализации микросегментации на уровне пода, предлагающий большую детализацию, чем правила межсетевого экрана VPC, которые работают на уровне узла.
Проверка всего трафика между VPC или VPC-в-интернет с использованием централизованного стороннего межсетевого экрана/NVA.
Создайте топологию "звезда". Разверните NVA в хабовом VPC. Настройте пользовательские маршруты в спицах, которые направляют трафик к Internal Load Balancer в хабе в качестве следующего перехода.
Почему: Этот шаблон заставляет трафик проходить через центральную точку проверки. ILB предоставляет стабильный, высокодоступный IP-адрес следующего перехода для NVA.
Обеспечение безопасного, основанного на идентификации, бездоверительного доступа для пользователей к внутренним веб-приложениям или ВМ без использования VPN.
Для веб-приложений включите IAP на бэкенд-сервисе External HTTPS LB. Для SSH/RDP используйте IAP для пересылки TCP. Предоставьте пользователям соответствующие роли IAM для IAP.
Почему: IAP перемещает контроль доступа с периметра сети на идентификацию пользователя, аутентифицируя и авторизуя каждый запрос. Это основной компонент модели бездоверия BeyondCorp от Google.
Реализация предотвращения угроз (IDS/IPS) для трафика между VPC или VPC-в-интернет, включая обнаружение вредоносного ПО и проверку TLS.
Используйте Cloud NGFW. Свяжите политику межсетевого экрана с VPC, создайте правила с профилями безопасности для предотвращения угроз и, при желании, включите проверку TLS.
Почему: Cloud NGFW - это распределенный, управляемый сервис межсетевого экрана Google, предоставляющий расширенные возможности инспекции L7 от Palo Alto Networks, интегрированный непосредственно в VPC.
Централизованная проверка, ведение журналов и контроль всего исходящего интернет-трафика из VPC для обеспечения безопасности и соответствия требованиям.
Разверните Secure Web Proxy. Настройте политики безопасности для фильтрации URL и проверки TLS. Маршрутизируйте трафик из подсетей на прокси, используя пользовательские маршруты.
Почему: Это управляемое решение Google для безопасного исходящего трафика, обеспечивающее видимость и контроль на уровне L7 без необходимости самостоятельного управления прокси-парками.
Домен 6: Управление, мониторинг и устранение неполадок сетевых операций
Быстрая диагностика сбоя подключения между двумя конечными точками в GCP (например, ВМ-к-ВМ, ВМ-к-Cloud SQL).
Используйте Connectivity Tests из Network Intelligence Center. Укажите источник и назначение, и он проанализирует весь настроенный путь на наличие проблем.
Почему: Этот неинтрузивный инструмент обеспечивает окончательный анализ пути, указывая точную точку отказа (межсетевой экран, маршрут и т.д.) гораздо быстрее, чем ручная проверка.
Сессия BGP по гибридному соединению периодически сбрасывается ("флаппинг").
Проверьте несоответствие таймеров BGP keepalive/hold. Если таймеры истекают под нагрузкой, увеличьте их (например, 60с keepalive, 180с hold). Также проверьте настройки MTU и включите BFD.
Почему: Несоответствующие или слишком агрессивные таймеры являются частой причиной BGP-флаппинга, так как временная перегрузка сети может задерживать keepalive-пакеты сверх времени удержания.
Расследование сообщений об увеличенной задержке для трафика между регионами GCP.
Используйте Performance Dashboard из Network Intelligence Center для просмотра исторических и текущих метрик задержки и потери пакетов между всеми парами зон GCP.
Почему: Этот инструмент обеспечивает прямую видимость производительности магистральной сети Google, помогая отличить проблему приложения от проблемы сетевой инфраструктуры.
Виртуальные машины, использующие Cloud NAT, сталкиваются с периодическими сбоями исходящих соединений, а журналы NAT показывают отбрасывания `OUT_OF_RESOURCES`.
Это, вероятно, истощение портов NAT. Увеличьте количество выделенных NAT IP, увеличьте "Минимальное количество портов на экземпляр ВМ" и/или включите Dynamic Port Allocation.
Почему: Высокие скорости соединения от многих ВМ могут исчерпать выделенный пул исходных портов на каждый NAT IP. Выделение дополнительных ресурсов является необходимым исправлением.