Кілька проєктів 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 на кожен не замінює те рішення про власність. Це те саме рішення, ухвалене пізніше, тим, хто успадкує рахунок і таблицю маршрутизації.