Развёртывание ADC не должно требовать изменения IP-адресов бэкендов, шлюзов или сетевых сегментов.
В традиционных проектах развёртывания ADC наибольшие затраты — как правило, не сам продукт, а перестройка существующей сети под продукт. Изменение шлюзов по умолчанию бэкендов, перепроектирование IP-планов, переработка поведения маршрутизации или открытие окон обслуживания — всё это несёт значительный риск в производственных средах.
В средах с сотнями или тысячами бэкендов подход «изменить шлюз каждого сервера» нежизнеспособен. У некоторых бэкендов шлюз может вообще не быть настроен, другие работают на статических маршрутах, а третьи работают на устаревших системах, которые сложно или невозможно изменить. В таких случаях вставка ADC превращается в полный проект перестройки сети.
Принудительное слияние сетевых сегментов — ещё одна проблема. VIP должен находиться в DMZ, бэкенд должен оставаться во внутренней сети, сети тенантов должны быть изолированы, а плоскость управления должна быть отдельной. Если ADC не может переносить трафик между этими доменами контролируемым образом, сегментация безопасности разрушается или команды приложений вынуждены выполнять ненужную IP-миграцию.
Единая модель reverse proxy также не удовлетворяет всем потребностям. Некоторым приложениям нужно, чтобы бэкенды видели реальный клиентский IP; некоторым L4-сервисам нужно, чтобы обратный трафик полностью обходил ADC; в некоторых inline-сценариях нужно вставить ADC без изменения IP или касания шлюзов. Единая NAT-модель не может охватить этот диапазон требований.
Режимы топологии развёртывания TR7 обеспечивают эту гибкость: они позволяют выбрать правильное размещение трафика для каждого сервиса без изменения IP-адресов бэкендов, шлюзов или назначений Route Table.
Наш подход
TR7 превращает топологию развёртывания в архитектурное решение, которое можно адаптировать к типу сервиса, размещению в сети и риску миграции.
L7 reverse proxy и transparent bind поддерживаются совместно
В классической модели reverse proxy клиент подключается к TR7, а TR7 подключается к бэкенду. В сценарии transparent bind поток трафика сохраняется так, что бэкенд видит реальный клиентский IP в качестве адреса источника.
Режимы L4 NAT, SNAT и DR предлагают разные пути возврата
В режиме NAT управляется и трансляция назначения, и трансляция источника. В режиме SNAT регулируется только сторона источника. В режиме DR обратный трафик идёт напрямую к клиенту, обеспечивая более эффективный путь для высококонкурентных L4 рабочих нагрузок.
Кросс-Route-Table пересылка соединяет сегменты без их слияния
Route Table, хостящий VIP, и Route Table, хостящий бэкенд, могут быть разными. TR7 переносит трафик между двумя сетевыми доменами контролируемым образом, соединяя DMZ, внутренние, тенантные и управленческие сегменты без их выравнивания.
IP-takeover inline вставляет ADC без изменения существующих сервисов
TR7 может взять на себя трафик, предназначенный для конкретных IP бэкендов, и работать inline. IP-адрес бэкенда, шлюз и конфигурация приложения остаются неизменными, пока ADC вставляется в путь.
Возможности
Режимы топологии развёртывания охватывают сетевые размещения — от быстрой настройки с одним интерфейсом до высокопроизводительной L4-пересылки.
One-arm route-mode обеспечивает быстрое развёртывание на одном интерфейсе
В режиме one-arm клиентский и бэкенд трафик могут обрабатываться на одной стороне сети. TR7 получает сервисный трафик через один интерфейс и перенаправляет его к нужному бэкенду с помощью правил маршрутизации. Эта модель подходит для быстрого развёртывания ADC с минимальными изменениями сети. Это практичная отправная точка для пилотных развёртываний, временных переходов или сценариев с низким риском.
Two-arm gateway-mode обеспечивает разделение DMZ и внутренней сети
В режиме two-arm TR7 позиционируется между двумя отдельными сетевыми сегментами. С одной стороны — клиентская или DMZ-сеть; с другой — сеть бэкендов. Это делает ADC не просто перенаправителем трафика, но точкой применения политики на границе сети. Подходит для корпоративных архитектур, требующих безопасности и сегментации.
Режим reverse proxy обеспечивает классическое поведение L7 vService
В режиме reverse proxy клиент подключается к VIP или vService на TR7, а TR7 открывает отдельное соединение с бэкендом. TLS-терминация, WAAP, работа с заголовками, безопасность cookie, content-aware правила и интеграция с AAM — всё полностью применимо в этом режиме. Это наиболее распространённая топология доставки приложений для HTTP и API-трафика. Бэкенды никогда не выставляются напрямую в интернет или внешние сети.
Transparent L7 bind сохраняет реальный клиентский IP на бэкенде
В сценарии transparent L7 исходным IP, который видит бэкенд, является реальный адрес клиента, а не адрес ADC. Этот режим ценен для приложений, которые не могут полагаться исключительно на header-based пересылку клиентского IP. Логи, контроль доступа и решения внутри приложения на основе IP работают более естественно. Путь возврата трафика в сети должен быть соответствующим образом спланирован.
Режим L2 Bridge снижает необходимость изменений на Layer 3
Bridge mode позволяет TR7 находиться в пути трафика как мост Layer 2. В этом сценарии снижается потребность в дополнительной перенумерации IP или широких изменениях маршрутизации. Существующая адресация может быть сохранена при входе в путь трафика через VM, контейнеры или сегменты. Bridge mode полезен в средах, где изменения сети должны быть сведены к минимуму.
Transparent gateway обеспечивает inline-транзит без NAT
В режиме transparent gateway TR7 располагается в транзитной точке сети бэкендов. IP источника сохраняется, NAT не требуется. Этот режим ценен в сценариях, где бэкенды должны естественно видеть клиентский IP. Изменения маршрута по умолчанию должны тщательно планироваться, а путь возврата должен явно контролироваться.
IP-takeover inline вставляет ADC без изменения шлюзов
TR7 может взять на себя трафик для назначенных IP бэкендов и работать inline. Этот режим особенно ценен, когда IP-адрес бэкенда, шлюз по умолчанию или настройки маршрута нельзя изменить. Даже когда у бэкенда нет настроенного шлюза, TR7 может позиционировать себя как контрольную точку в соответствующем пути трафика. В больших средах контролируемая inline-вставка заменяет необходимость индивидуальной модификации сотен бэкендов.
Кросс-Route-Table пересылка соединяет сервисы без слияния сетей
TR7 может слушать VIP в одном Route Table и перенаправлять трафик к бэкенду в другом Route Table. Это позволяет DMZ, внутренним, тенантным, управленческим и отдельным сервисным зонам соединяться друг с другом контролируемым образом без перемещения в одну сетевую плоскость. Операторы не должны перенумеровывать бэкенды или выравнивать сети. TR7 становится контролируемой транзитной точкой между Route Table, где может применяться политика безопасности.
Режимы L4 NAT и SNAT выбираются на основе требуемого пути возврата
В режиме L4 NAT трансляция назначения и источника используются вместе для гарантии пути возврата через TR7. В режиме SNAT регулируется только сторона источника, и существующий дизайн пути возврата бэкенда соблюдается. Эти два режима позволяют переносить L4-трафик способом, соответствующим топологии сети. Для UDP, TCP или конкретных диапазонов портов может быть выбрано отдельное поведение.
Режим L4 DR переносит высококонкурентный обратный трафик напрямую
В режиме DR запросный трафик перенаправляется к бэкенду через TR7, тогда как ответный трафик возвращается напрямую к клиенту. Эта модель выгодна для высококонкурентного стриминга, игр, DNS или латентно-чувствительных L4-сервисов. Поскольку ADC не несёт обратный трафик, путь данных становится более эффективным. Поведение бэкенда и сети при возврате должно быть правильно подготовлено для DR-сценариев.
L4 persistence и SIP persistence обеспечивают непрерывность сессий
L4 persistence помогает гарантировать, что трафик от конкретного клиента остаётся на том же бэкенде. CONNMARK, записи recent и настраиваемое окно персистентности обеспечивают непрерывность потоков. SIP persistence обеспечивает специализированное поведение для сессионно-чувствительных протоколов, таких как SIP. Это даёт сессионную согласованность на уровне L4 в дополнение к базовому распределению нагрузки.
Автоматическая генерация правил безопасности упрощает доступ к сервисам
Необходимые разрешения на вход для определений L4 и vService могут генерироваться автоматически. Для каждого frontend IP, порта и протокола создаются соответствующие правила приёма, снижая количество ошибок ручной настройки файрвола. Автоматическая генерация правил особенно важна в inline и L4 сценариях. Оператор выбирает топологию; TR7 последовательно генерирует базовые разрешения для соответствующего пути трафика.
Операционная глубина
Режимы топологии работают совместно с настройками L4 по умолчанию, поведением inline-процесса, Route Table TR7, ролью кластера и видимостью ошибок.
Поведение L4 по умолчанию
Алгоритм round-robin, режим NAT и протокол UDP доступны как значения по умолчанию для нового L4 pool. Операторы могут изменить их на TCP, UDP, any protocol, диапазон портов или другой L4-алгоритм в зависимости от требований сервиса. Значения по умолчанию предназначены для быстрого старта; производственное поведение должно быть явно проверено.
Выбор L4-алгоритма
Алгоритмы, такие как round-robin и взвешенный round-robin, могут использоваться для L4-распределения. Взвешенная модель обеспечивает более равномерное распределение трафика между бэкендами с разной ёмкостью. Выбор алгоритма должен планироваться вместе с типом сервиса, ёмкостью и поведением сессий.
Процесс inline takeover
Режим IP-takeover inline работает на основе соответствующего интерфейса, IP бэкенда и информации о шлюзе. Если шлюз явно не указан, подходящий путь может быть получен из существующей информации о сети. Если процесс останавливается неожиданно, может применяться автоматический перезапуск.
Причины ошибок inline
В режиме inline условия, такие как noBackendIp, ipUsed, noZoneId, noMatchingIp, noSpoofingIp, inactiveClusterDevice и inactiveClusterIp, могут отображаться как явные причины ошибок. Это сообщает команде operations точно, почему что-то не работает, а не просто что не работает. Видимость ошибок критична для безопасного управления inline-топологиями.
Cluster-aware inline поведение
В кластерной среде процесс inline takeover должен выполняться только на устройстве, которое несёт активную роль. Когда активное устройство меняется, владение inline-трафиком переходит к соответствующему узлу. Эта модель помогает предотвратить одновременное предъявление двумя узлами прав на один IP.
Независимость от шлюза по умолчанию
Inline transparent mode снижает зависимость от настройки шлюза по умолчанию бэкенда. Если у бэкенда нет шлюза или шлюз нельзя изменить, TR7 может взять на себя соответствующий путь трафика с помощью метода IP-takeover. Эта возможность позволяет контролируемо развёртывать ADC без открытия окон обслуживания или изменения бэкендов.
Кросс-Route-Table пересылка
Route Table TR7, на котором слушает VIP, и Route Table TR7, где находится бэкенд, могут быть разными. TR7 переносит трафик между двумя сетевыми доменами, снижая потребность в изменениях топологии. Это поведение особенно ценно для контролируемого перехода из DMZ во внутреннюю сеть, из сети тенанта в сеть общих сервисов или между старым и новым сетевыми доменами при миграции.
Когда применять
Inline-развёртывание без изменения бэкендов
В крупных организациях изменение IP, маршрута или шлюза сотен бэкендов сопряжено с высоким риском. Режим IP-takeover inline позволяет вставить TR7 ADC в путь трафика при сохранении существующей адресации.
Вставка ADC для сервисов без шлюза
У некоторых устаревших или изолированных бэкендов может не быть настроенного шлюза по умолчанию. В режиме inline transparent TR7 может взять на себя соответствующий трафик без касания настройки шлюза бэкенда.
Контролируемый транзит сервисов между разными Route Table
Организации могут слушать VIP на Route Table DMZ, сохраняя бэкенды на внутреннем Route Table. TR7 обеспечивает контролируемый транзит трафика между двумя доменами без слияния сетей или перенумерации IP сервисов.
Высококонкурентный L4-трафик игр и стриминга
Команды игр или стриминга могут использовать DR mode для отправки ответного трафика напрямую клиенту. Пока TR7 принимает решение о пересылке, нагрузка на путь обратных данных снижается, и высокопроизводительные сценарии становятся более эффективными.
Часто задаваемые вопросы
Какие режимы топологии развёртывания поддерживает TR7?
Как работает режим IP-takeover inline?
В чём разница между режимами L4 NAT, SNAT и DR?
Что обеспечивает кросс-Route-Table пересылка?
Какие причины ошибок можно отслеживать в режиме inline?
Когда следует предпочесть one-arm over two-arm?
Адаптируйте TR7 к вашей существующей сети — без изменения ваших бэкендов
От one-arm до transparent inline, от L4 DR до кросс-Route-Table пересылки — давайте пройдёмся по правильной топологии в живой настройке.