Нужно соединять тенантные сети, DMZ и внутренние сервисы — без сведения их в одну плоскость.
Одна из сложнейших задач в enterprise-сетях — безопасное управление разными сетевыми доменами на одном устройстве без конфликтов адресов. В MSP, государственных, финансовых, медицинских и мультитенантных средах каждый тенант может принести свой IP-план. Повторное использование одного блока CIDR у разных клиентов широко распространено.
Классическое разделение маршрутов обычно изолирует только таблицу маршрутизации. Однако истинная изоляция требует большего, чем просто маршруты — интерфейсы, ARP, firewall, сокет и поведение соединений также должны быть разделены. Без этого `10.0.0.5` тенанта A и `10.0.0.5` тенанта B становятся операционно и с точки зрения безопасности рискованными на одном устройстве.
Вторая проблема возникает, когда сервисы должны оставаться в разных сетевых доменах. VIP должен прослушивать на стороне DMZ, бэкенд должен оставаться во внутренней сети, управляющий трафик должен быть ограничен своей Route Table, или старые и новые сети должны сосуществовать при миграции. Принудительное объединение этих доменов нарушает сегментацию безопасности и операционный порядок.
Правильный подход — изолировать каждый сетевой домен в своей Route Table и обеспечить контролируемое пересечение на уровне vService. vService должен иметь возможность прослушивать в нескольких Route Tables и пересылать трафик на бэкенды в других Route Tables.
Маршрутизация Cross-NS TR7 удовлетворяет эту потребность: она создаёт изолированные сетевые домены на одном устройстве, разделяет перекрывающиеся IP-планы и превращает vService в контролируемый мост трафика между Route Tables.
Наш подход
TR7 реализует мультисетевую архитектуру через изоляцию Route Table, межсетевую маршрутизацию, управление процессами на таблицу и жизненный цикл через UI.
Route Tables TR7 обеспечивают полную сетевую изоляцию
Каждая Route Table имеет собственную маршрутизацию, интерфейсы, ARP, firewall и пространство имён сокетов. Тенанты, сервисные зоны или тестовые среды могут работать на одном устройстве, не мешая друг другу.
vService может устанавливать потоки Cross-Route-Table N-to-M
Один vService может прослушивать VIP в нескольких Route Tables и пересылать трафик на бэкенды в других Route Tables. Это обеспечивает контролируемую передачу сервисов без выравнивания сети.
Каждая Route Table контролируется выделенным процессом
TR7 может запускать отдельный процесс мониторинга и управления сетью для каждой Route Table. Состояние канала, IP-адреса, маршруты, статистика и работоспособность сервисов собираются независимо для каждого сетевого домена.
Жизненный цикл Route Table управляется из UI
Операторы могут создавать, удалять, именовать и настраивать DNS и параметры hosts для Route Tables. То, какой Route Table принадлежит интерфейс, также можно изменять из консоли управления.
Возможности
Мультипространственная архитектура делает разные сетевые домены управляемыми на одном ADC — от изоляции тенантов до межсервисной маршрутизации.
Каждая Route Table TR7 — самодостаточное сетевое рабочее пространство
Route Table TR7 — это не просто отдельный список маршрутов. Интерфейс, ARP, firewall, сокет и поведение соединений работают независимо внутри домена. Сетевое поведение одного тенанта не может просочиться к другому. Операционные команды управляют несколькими сетевыми доменами на одном устройстве более безопасно и наглядно.
Один и тот же CIDR могут использовать разные тенанты без конфликтов
В мультитенантных средах разные клиенты могут использовать одни частные IP-блоки. Route Tables TR7 держат эти перекрывающиеся планы адресов в отдельных сетевых доменах. `10.0.0.5` тенанта A и `10.0.0.5` тенанта B могут сосуществовать на одном устройстве с различными значениями. Это даёт MSP и суверенным облачным архитектурам существенную гибкость IP-планирования.
vService может прослушивать VIP в нескольких Route Tables
Интерфейс vService не ограничен одним сетевым доменом. Один и тот же сервис может прослушивать на разных VIP в prod, DMZ, управляющих или тенантных Route Tables. В зависимости от того, из какой Route Table пришёл клиент, может применяться другая политика или выборка бэкенда. Эта модель упрощает сценарии мультисетевой публикации без дублирования экземпляров сервисов.
Трафик можно пересылать на бэкенды в разных Route Tables
TR7 может принять трафик, поступающий по одной Route Table, и переслать его на бэкенд в другой Route Table. VIP может оставаться в DMZ, пока бэкенд находится во внутренней сети; тенантная сеть может оставаться отдельной, пока сеть общих сервисов живёт в своей Route Table. Через TR7 проходят только разрешённые сервисные потоки — сети никогда не объединяются. Сегментация сохраняется, доступ к приложениям упрощается.
Интерфейсами можно перемещать между Route Tables контролируемым образом
То, какой Route Table принадлежит физический или виртуальный интерфейс, можно управлять из TR7. Это практично при миграции, переводе тенантов или переходах из тестовой среды в production. Влияние на маршруты, IP и сервисы при перемещении интерфейса следует оценивать полностью. Операционным командам не нужно рассматривать сетевые домены как статичные, неподвижные структуры.
V-ETH(peer) обеспечивает контролируемый канал между Route Tables
Пару V-ETH(peer) можно использовать для создания контролируемого виртуального соединения между двумя разными Route Tables. Это ценно, когда только определённые, задокументированные пути трафика должны пересекать иначе полностью изолированные домены. Применимо для тестирования, миграции, совместного использования сервисов и доступа тенантов к общим сервисам. Соединение по-прежнему регулируется политиками TR7 и правилами firewall.
DNS и настройки hosts разделяются по Route Table
Каждая Route Table может работать со своими DNS и записями hosts. Одно и то же имя хоста может разрешаться в разные IP в разных тенантных Route Tables, или тестовая среда может использовать иное разрешение имён, чем production. Это разделение снижает конфликты имён хостов в мультитенантных средах и сценариях миграции. Операторы управляют поведением DNS на уровне сетевого домена, а не глобально.
Процессы динамической маршрутизации разделяются по Route Table
Каждая динамическая Route Table может запускать собственный процесс маршрутизации. Поведение BGP, OSPF или аналогичной динамической маршрутизации можно изолировать по тенанту или сетевому домену. Изменение маршрута в домене одного тенанта не влияет на маршрутную плоскость другого. Это существенное преимущество в плане безопасности и операций в MSP и многорегиональных enterprise-архитектурах.
Поведение firewall и ipset независимо в каждой Route Table
TR7 может применять отдельное управление firewall для каждой Route Table. Правила, ipset и разрешения трафика работают в пределах соответствующего сетевого домена. Открытый порт или предоставленное разрешение для одного тенанта не распространяется автоматически на сервисы другого. Команды безопасности могут определять область применения политик более точно.
Статистика и мониторинг состояния по Route Table
Статистику канала, IP, маршрутов и трафика можно собирать отдельно для каждой Route Table. Операционные команды могут видеть, какой канал, IP или маршрут вызывает проблему в каком сетевом домене в изоляции. Это сокращает время устранения неполадок в многодоменных средах. Среды, работающие на одном устройстве, контролируются в чётко разделённых представлениях.
Health check Cross-NS проверяет реальный путь доступа
Health check может проверять не только доступность бэкенда, но и его достижимость из соответствующей Route Table. Проверка, выданная из фронтального сетевого домена к бэкенду в другой Route Table, проходит реальный путь трафика — проверяя прохождение маршрута, ARP и firewall, а не только доступность сервиса. Это обеспечивает критически важную операционную уверенность в настройках межсетевой маршрутизации.
Модель Route Table не ведёт себя как отдельно лицензируемый тенантный продукт
Поведение с несколькими Route Tables является нативной частью сетевой архитектуры TR7. Операторам не нужно предоставлять отдельное виртуальное устройство для каждого тенанта. Изоляция, маршрутизация и передача сервисов на одном ADC — всё это остаётся в единой плоскости управления. Это снижает как потребление ресурсов, так и операционную сложность.
Операционная глубина
Мультитабличная архитектура эксплуатируется с полным управлением жизненным циклом, миграцией интерфейсов, восстановлением процессов, DNS/hosts на таблицу и координацией состояния между доменами.
Создание Route Table
Когда оператор создаёт новую Route Table, TR7 подготавливает отдельный контекст выполнения для этого сетевого домена. Этот домен несёт собственное поведение интерфейса, маршрута и firewall. Поля имени и описания помогают операционным командам различать тенантов или сервисные зоны.
Безопасное поведение при удалении
Удаление Route Table, к которой ещё привязаны интерфейсы, рассматривается как небезопасное. Поведение по умолчанию блокирует удаление до тех пор, пока интерфейсы не будут перенесены. При необходимости интерфейсы можно сначала вернуть в дефолтный домен, делая удаление контролируемым и явным.
Восстановление при сбое процесса
Если процесс мониторинга и управления, выполняющийся для Route Table, завершается неожиданно, его можно перезапустить автоматически. Это сохраняет непрерывность поведения мультидоменного мониторинга. Операционные команды не теряют навсегда видимость сетевого домена из-за единичного сбоя процесса.
Влияние миграции интерфейса
При перемещении интерфейса из одной Route Table в другую влияние на IP, маршруты, сервисы и правила firewall необходимо оценивать совместно. Операция мощна для целей миграции, но в production-средах её следует планировать. TR7 делает это поведение видимым в UI, снижая риск непреднамеренных перемещений.
Межпроцессное взаимодействие Route Table
Между основным процессом управления и каждым процессом Route Table можно установить обмен сообщениями на основе событий. Состояние канала, состояние IP, информация GTM и сервисные сигналы доставляются отдельно в каждый сетевой домен. Это обеспечивает контролируемую координацию между глобальным управлением и изолированными сетевыми доменами.
Индексирование Route Table
Каждой Route Table можно присвоить индексное значение. Этот индекс используется для определения портов динамической маршрутизации, смещений ID виртуального маршрутизатора и идентификаторов вспомогательных процессов на сервис. Конфликты портов и идентификаторов между несколькими сетевыми доменами тем самым снижаются.
Когда применять
Разделение перекрывающихся CIDR тенантов в MSP-среде
MSP может запускать нескольких клиентов, использующих блок адресов `10.0.0.0/8`, на одном TR7 ADC, каждый в своей Route Table. Каждый тенант остаётся изолированным в собственном сетевом домене без IP-конфликтов.
Передача трафика от VIP DMZ к бэкенду внутренней сети
Организации могут держать VIP прослушивающим в Route Table DMZ, пока бэкенд остаётся во внутренней Route Table. TR7 переносит только разрешённый сервисный трафик между двумя доменами — без их объединения.
Контролируемая миграция трафика между тенантными Route Tables
При переносе сервиса из старой тенантной сети в новую Route Table трафик vService можно перенаправить контролируемым образом. IP-план и доступ к сервисам управляются совместно на протяжении всей миграции.
Изоляция тестовых и staging-сетей от production
Тестовая Route Table может работать с настройками, близкими к production, но не имеет прямого доступа к production-трафику. При необходимости операционная команда может тестировать определённые сервисы через межтабличную маршрутизацию, сохраняя изоляцию.
Часто задаваемые вопросы
Чем Route Table TR7 отличается от классического VRF?
Может ли один блок CIDR действительно работать в разных тенантных Route Tables без конфликтов?
Сколькими Route Tables может прослушивать один vService?
Зачем запускать отдельный процесс мониторинга для каждой Route Table?
Когда следует использовать V-ETH(peer)?
Требует ли эта возможность дополнительной лицензии или отдельного модуля тенанта?
Изоляция тенантов и межсервисная маршрутизация — без слияния сетей
Перекрывающиеся IP-планы, маршрутизация DMZ-to-internal и мультитенантная архитектура Route Table. Проведём живое демо настройки в вашей среде.