Несколько проектов Google Cloud, один гибридный VPN? Сначала решите
Общий VPC, пиринг и центр связности отвечают на разные вопросы владения. Выберите границу сети, прежде чем развёртывать по одному VPN на проект.
Когда нескольким проектам Google Cloud нужен гибридный доступ, инстинкт подсказывает один VPN на проект, и это почти всегда неправильная форма. Владение проектом и маршрутизация пакетов — связанные, но разные вопросы, и полезная архитектура сохраняет нужные административные границы, одновременно давая предусмотренным префиксам один продуманный путь в офис или центр обработки данных. Эти проверки решают, какая модель сети вам действительно нужна, в том порядке, который избегает переделок. Каждая из них может закончить обсуждение раньше, и в этом смысл.
Граница проекта не требует автоматически собственного туннеля.
Проверьте, является ли общий объект сетью
Начните с вопроса о владении, а не о связности: может ли центральное владение сетью поддерживать эти рабочие нагрузки? Если ответ да и у организации есть подходящая конфигурация, хост-проект владеет VPC, подсетями и связностью, а сервисные проекты владеют своими ресурсами приложений. Одно подключение Cloud VPN в этой общей сети затем может обслуживать предусмотренные префиксы рабочих нагрузок, с соблюдением политик маршрутизации и безопасности .
Будьте точны в том, что делает присоединение. Подключение сервисного проекта не объединяет его существующий независимый VPC с хост-сетью и не перемещает автоматически каждый ресурс. Присоединение рабочих нагрузок, разрешения, адресное пространство и DNS — всё это часть архитектуры, а не следствие настройки. Читайте присоединение сначала как изменение разрешений, а затем как изменение маршрутизации, потому что команды обычно обнаруживают разницу во время перехода.
Если центральное владение неприемлемо для вовлечённых команд, остановитесь здесь и рассматривайте остальное как проект пиринга или центра. Навязывание Shared VPC группе, которой нужны независимые жизненные циклы сети, порождает политическую проблему с техническим названием.
Проверьте, могут ли независимые VPC оставаться независимыми
Пиринг сохраняет отдельные VPC, и именно поэтому он привлекает команды, которым нужны собственные планы адресов и собственный контроль изменений. Подвох в том, что пиринг не транзитивен: пиринг A-к-B и B-к-C сам по себе не создаёт маршрутизацию A-к-C через B. Если трём проектам нужно достичь одного гибридного назначения, вам нужен продуманный план обмена, а не цепочка пирингов.
Совместное использование гибридной доступности также зависит от документированного обмена пользовательскими маршрутами и от предусмотренных анонсов Cloud Router. Активный статус пиринга доказывает, что пиринг существует, а не то, что префиксы, важные для каждой стороны, когда-либо экспортировались. Проверьте экспортированные диапазоны с обеих сторон пира, в конфигурации, которая выполняет экспорт, и сравните их с адресами, которые ваши рабочие нагрузки действительно используют. Несоответствие там — самая частая причина того, что пиринг выглядит здоровым, а префикс остаётся недоступным.
Напишите план адресов прежде всего остального. Непересекающиеся диапазоны, маршруты к каждому предусмотренному назначению и обратные анонсы — это три артефакта, на которых эта модель живёт или умирает.
Проверьте, подходит ли модель центра к топологии
Для более крупного или иначе сегментированного проекта обзор Google Network Connectivity Center описывает модели центра и луча. Читайте его ради того, что поддерживает текущий выпуск, а не ради того, что подразумевает схема: какие комбинации VPC и гибридных подключений, какие семейства маршрутов и какие политики допускает каждый тип луча.
Проверьте семейство адресов явно. Примеры планирования в большинстве руководств, включая это, касаются IPv4, а функция, существующая для одного типа луча, не применяется автоматически без изменений к другому. Если ваша среда с двойным стеком, этот вопрос относится к выбору модели, а не к более поздней миграции.
Таблица ниже — это сводка трёх моделей и вопроса, который решает каждую.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
Проверьте, чего не даёт маршрутизация
Обмен маршрутами — это не всеобъемлющая выдача доверия. Разрешение DNS, разрешение межсетевого экрана и авторизация приложений остаются их собственными обязанностями, и каждое из них в большинстве организаций настраивает другой владелец. Проект, который предполагает, что доступность означает авторизацию, пройдёт тест связности и провалит проверку безопасности.
Подтвердите также историю DNS для каждой модели, потому что настройки зон и пересылки различаются между общей сетью и сетями с пирингом. Частные имена, разрешаемые в одном проекте, не следуют по маршруту в другой.
Запишите решение и его владельца
Централизуйте там, где организация хочет общего владельца сети; сохраняйте отдельные VPC там, где этого требуют жизненный цикл или политика. Затем выберите поддерживаемое отношение связности и запишите, какое выбрали, кто владеет общей сетью и что каждому проекту разрешено анонсировать.
Подсчёт проектов и покупка одного VPN на каждый не заменяет это решение о владении. Это то же решение, принятое позже, тем, кто наследует счёт и таблицу маршрутизации.