Как направить трафик 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 или его переведённый псевдоним, должна отказать закрыто. Затем разорвите один туннель и убедитесь, что задача завершается неудачей только для этого арендатора, не откатываясь к подсети с тем же номером другого клиента. Восстановление тоже нужно проверить, потому что устаревший маршрут или кэшированные учётные данные могут пережить сбой.
Архитектура может быть объединёнными работниками с изолированными коннекторами или полностью раздельными ресурсами арендаторов. Инвариант один: проверенный контекст арендатора выбирает маршрут и учётные данные, и никакое изменение маршрута никогда не даёт приложению разрешения между арендаторами.