NCC hub-and-spoke дизайн: один гибридный spoke получает локальные маршруты через Interconnect в us-east4. VPC spoke должен достигать локальной сети из us-west1, europe-central1, asia-southeast1, сохраняя при этом облачное IP-пространство (192.168.0.0/20). Локальная сеть — 172.16.0.0/16. Что следует предпринять?

Правильный ответ позволяет VPC-спицам в разных регионах достигать локальной сети, сохраняя при этом облачное IP-пространство. Создание Private NAT gateway в каждом соответствующем регионе с использованием уникальных подсетей (192.168.x.0/24) гарантирует, что трафик из этих VPC будет транслироваться в эти подсети перед отправкой в локальную сеть. Настройка политики экспорта (export include policy) в Network Connectivity Center (NCC) для анонсирования только этих NAT-подсетей в хаб предотвращает утечку внутренних IP-адресов VPC в локальную сеть и обеспечивает контролируемый доступ. Включение глобальной динамической маршрутизации необходимо для того, чтобы маршруты из локальной сети, полученные в us-east4, были доступны во всех регионах Google Cloud, позволяя трафику возвращаться к источникам в us-west1, europe-central1 и asia-southeast1. Неправильные варианты: Использование 172.16.x.0/24 для подсетей NAT неверно, так как это диапазон локальной сети, что приведет к конфликтам IP-адресов. Создание Private NAT gateway только в us-east4 не позволит VPC-спицам в других регионах использовать NAT для доступа к локальной сети, так как NAT является региональным сервисом. Использование политики экспорта (export exclude policy) не подходит, так как она исключает указанные маршруты, а нам нужно анонсировать только определенные NAT-подсети.