Справочник

Планирование 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, которые являются ключевыми принципами архитектуры "нулевого доверия".

Рабочим нагрузкам (ВМ, GKE подам) без публичных IP-адресов требуется стабильный, предсказуемый исходный IP-адрес для исходящих подключений к внешним API, использующим белый список.

→Разверните Cloud NAT. Используйте опцию "ручное распределение NAT IP" и назначьте зарезервированные статические внешние IP-адреса шлюзу NAT.

Почему: 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) и фильтрацией метаданных для исключения ненужных полей.

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

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

→Используйте 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, упрощая архитектуры внутренних сервисов, охватывающих несколько регионов.

Установление высокодоступного (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 становятся активными.

Предотвращение утечки данных из чувствительных сервисов 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 без необходимости самостоятельного управления прокси-парками.

Быстрая диагностика сбоя подключения между двумя конечными точками в 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. Выделение дополнительных ресурсов является необходимым исправлением.