Як спрямувати трафік SaaS до правильного VPN клієнта
Перекривані клієнтські підмережі ламають спільну маршрутизацію. Виберіть модель ізоляції, прив’яжіть кожне завдання до перевіреного орендаря та перевірте шляхи між орендарями перед запуском.
SaaS-платформа підключається до десятка клієнтських мереж, і двоє з цих клієнтів використовують 10.20.0.10 для своєї основної бази даних. Працівник, який отримує цю адресу в завданні, не може зрозуміти, яку базу даних має на увазі завдання, а спільна таблиця маршрутизації охоче надішле його до тунелю, на який указує префікс. Рішення — не більше тунелів; рішення в тому, щоб визначити, де ідентичність орендаря входить у шлях і яка модель ізоляції потрібна плану адрес. Три умови визначають вибір: чи перетинаються клієнтські префікси, як далеко може поширитися помилка і хто керує конектором.
Дві клієнтські бази даних, одна адреса призначення
IP-адреса — це місце, а не ідентичність. Запит має нести орендаря, якого перевірив сервер, і цей орендар має вибрати мережевий контекст до того, як адресу призначення буде розв’язано.
Коли цього не відбувається, збій тихий. З’єднання встановлюється, запит виконується, а відповідь надходить із бази даних неправильного клієнта, бо в таблиці маршрутизації був один запис для 10.20.0.10. DNS погіршує: кешоване ім’я, розв’язане в контексті орендаря A, може повторно використати завдання, що працює для орендаря B. Ніщо в пакеті не розрізняє ці два випадки, тож жодна логіка повторних спроб це не виправить.
Спочатку визначте модель ізоляції
Запишіть три умови до порівняння продуктів. Перетин визначає, чи можна взагалі ділити один адресний простір; радіус ураження визначає, чи є помилка маршрутизації заявкою в підтримку чи порушенням; операційна відповідальність визначає, чи можете ви керувати парком конекторів для кожного орендаря.
| Condition | Hub with per-tenant route tables | Per-tenant connector context |
|---|---|---|
| Customer CIDRs overlap | No, unless you add 1:1 NAT | Yes, each context keeps its own view |
| A mistake must stay inside one VPC | Weak, routing is shared infrastructure | Strong, each connector has its own egress |
| You can run one fleet per tenant | Not required | Required |
Якщо префікси різні й політика дозволяє керований хаб, один Transit Gateway з таблицями маршрутизації для кожного орендаря є здійсненним. Асоціація приєднання вибирає таблицю маршрутизації, яка використовується для трафіку, що надходить із цього приєднання, а поширення вибирає, які маршрути з’являються в таблиці. Приєднання орендаря, пов’язане лише з власною таблицею й таке, що поширює лише власні префікси, досягає хаба і нічого більше. Це рішення про маршрутизацію, і воно залишається правильним лише поки ніхто не додає маршрут за замовчуванням до спільної таблиці.
Якщо префікси перетинаються, сама маршрутизація не може їх розділити. Вам потрібен або окремий мережевий контекст для кожного орендаря, або план трансляції, який дає простору кожного клієнта однозначний сенс.
Що насправді означає ізоляція Transit Gateway
Асоціація та поширення — дві важливі налаштування, і їх легко переплутати. Асоціація відповідає, у якій таблиці шукається пакет із цього приєднання; поширення відповідає, які таблиці вивчають маршрути цього приєднання. Ізоляція виникає з того, що обидва стають специфічними для орендаря, а не зі створення більшої кількості приєднань.
Конфігурація за замовчуванням «усі з усіма» зручна й не є ізоляцією. Окремі таблиці маршрутизації обмежують зв’язність, але не дають одній незмінній адресі призначення двох смислів у тому самому контексті маршрутизації. Якщо застосунок розв’язує 10.20.0.10 до того, як дізнається орендаря, рівень маршрутизації вже втратив потрібну інформацію.
AWS 23 жовтня 2026 року додала NAT 1:1 на рівні приєднання для Transit Gateway і Cloud WAN, що змінює відповідь про перетин для підтримуваних приєднань. Документація Transit Gateway NAT описує статичні, безстанові IPv4-зіставлення з рівним префіксом і збереженими бітами хоста. Перевірте підтримувані типи приєднань і регіональні обмеження, перш ніж проєктувати з огляду на це.
Прив’яжіть завдання до перевіреного орендаря
Кожне завдання має нести перевірену сервером ідентичність орендаря, і ця ідентичність має вибирати запис з’єднання, що належить адміністратору. Запис називає схвалений мережевий контекст, адресу служби, посилання на облікові дані та дозволені там операції. Недовірений запит ніколи не повинен надавати власний ідентифікатор VPN, шлюз або приватну ціль, бо дійсний вхід не є дозволом досліджувати адресний простір кожного підключеного клієнта.
У схемі з ізольованими конекторами робота орендаря A йде до конектора, специфічного для A, який працює в VPC орендаря A і може досягти лише схвалених ресурсів A. Окремі контейнери на одному хості самі не створюють цього розділення; простори імен мережі, маршрути та політика виходу мають його реалізувати. Конектору також потрібні облікові дані й черги в межах орендаря, оскільки приватний маршрут не обмежує спільний секрет чи спільний елемент роботи. Об’єднані робочі процеси застосунку допустимі, поки мережевий контекст і облікові дані вибираються для кожного орендаря, а не для кожного хоста.
Перевірки працездатності мають називати орендаря й етап: встановлений тунель, наявний маршрут і успішний реальний запит до служби — це три різні сигнали. Сукупна кількість активних тунелів приховає того єдиного клієнта, чий конектор зламаний.
Перевірте шляхи, які мають зазнавати невдачі
Проведіть три тести перед запуском. Дозволена операція A має виконатися успішно, дозволена операція B має виконатися успішно, а завдання A, навмисно спрямоване на конектор B або його перекладений псевдонім, має зазнати закритої невдачі. Потім розірвіть один тунель і переконайтеся, що завдання зазнає невдачі лише для цього орендаря, не відкочуючись до підмережі з тим самим номером іншого клієнта. Відновлення також треба перевірити, бо застарілий маршрут або кешовані облікові дані можуть пережити збій.
Архітектура може бути об’єднаними працівниками з ізольованими конекторами або повністю розділеними ресурсами орендарів. Інваріант той самий: перевірений контекст орендаря вибирає маршрут і облікові дані, і жодна зміна маршруту ніколи не надає застосунку дозволу між орендарями.