Управление отдельным IP и отдельным listener для каждого домена не масштабируется.
В традиционных ADC и архитектурах reverse-proxy каждый новый домен обычно означает новый listener, новый виртуальный сервис, новый IP-адрес или сложный набор правил маршрутизации. При небольших масштабах это управляемо, но когда число доменов достигает десятков, тенантов — сотен или требуется разделение по нескольким средам, операционная поверхность быстро рассыпается.
На стороне TLS проблема острее. Заголовок HTTP Host невидим до завершения TLS, поэтому маршрутизация TLS-трафика к правильному сервису требует принятия решения на уровне SNI — до завершения handshake. Без надлежащего разделения SNI домены, использующие один IP, пересекаются, подаётся неправильный сертификат или трафик попадает на неверный бэкенд.
Управление wildcard-доменами создаёт дополнительную нагрузку. Шаблоны вида `*.tenant.app` распространены в SaaS и MSP-сценариях, однако ручное определение каждого поддомена неустойчиво. Wildcard необходимо преобразовать в правильный regex, корректно экранировать и ограничить, чтобы он не совпадал с нежелательными доменами.
HTTP/2 и современная семантика TLS делают обработку несовпадающих доменов ещё более чувствительной. Когда SNI и заголовок Host расходятся, клиент ожидает чётко определённого поведения; если платформа не может его обеспечить, соединения либо попадают в неверный пул, либо обходятся средства безопасности.
TR7 ADC рассматривает виртуальные хосты как отношение домен + сопоставитель + пул. Он разделяет домены на одном IP и порту через SNI или Host header, автоматически обрабатывает wildcard-домены и привязывает каждый домен к своей политике сервиса.
Наш подход
TR7 исключает ручное дублирование listener из управления виртуальными хостами и обрабатывает маршрутизацию на основе доменов через объектную модель, автоматическую генерацию сопоставителей и процесс reload без простоя.
Два режима сопоставления: SNI и Host header
Для TLS-трафика решение принимается по значению SNI; для HTTP-трафика используется заголовок Host. Как сценарии раннего разделения TLS, так и классические сценарии HTTP reverse-proxy обрабатываются в рамках одной модели виртуальных хостов.
Wildcard-домены автоматически преобразуются в правила сопоставления
Записи wildcard типа `*.example.com` автоматически преобразуются в безопасные шаблоны сопоставления. Операторам не нужно писать regex вручную. Одно определение wildcard маршрутизирует неограниченное число поддоменов в нужный пул.
Каждый домен привязан к своему пулу и цепочке политик
Каждый домен, использующий VIP, может целиться в другой пул. Это означает, что один домен может нести профиль WAAP, другой — mTLS, третий — кэш или пользовательский профиль журнала. Разделение доменов — это не только маршрутизация, но и разделение политик.
Детерминированная конфигурация и идемпотентный reload
TR7 генерирует конфигурацию виртуальных хостов в отсортированном, детерминированном порядке. Поскольку один и тот же вход всегда даёт одинаковый выход, излишние reload исключены. Мягкий reload применяется только при обнаружении реального изменения, сохраняя действующие соединения.
Возможности
Виртуальные хосты обеспечивают разделение по доменам, управление wildcard, привязку сертификатов, изоляцию тенантов и обновления без простоя на одном IP и порту.
Маршрутизация виртуальных хостов на основе SNI
В TLS-трафике считывается значение SNI, которое клиент предоставляет, и соответствующий домен направляется в нужный пул. Это позволяет разделять домены на самом раннем этапе TLS-соединения. Является основным механизмом для работы нескольких TLS-сервисов на одном порту 443.
Маршрутизация HTTP на основе Host header
В режиме HTTP TR7 использует значение заголовка `Host` для сопоставления виртуальных хостов. Классическое поведение vhost достигается для обычного HTTP и для HTTP-трафика после завершения TLS. Разные домены на одном IP и порту перенаправляются в отдельные пулы сервисов.
Поддержка wildcard-доменов
Имена wildcard типа `*.example.com` автоматически преобразуются в правила сопоставления. Операторам не нужно писать отдельное правило для каждого поддомена. Это особенно мощно для доменов SaaS-тенантов, поддоменов клиентов и разделения по нескольким средам.
Привязка пула для каждого домена
Каждый виртуальный домен привязан к идентификатору пула. `shop.example.com`, `api.example.com` и `admin.example.com` на одном VIP могут целиться в разные бэкенды. Каждый пул управляет своим списком бэкендов, health check, WAAP и правилами трафика независимо.
Профиль WAAP, кэша и журнала для каждого домена
Виртуальный хост — это не просто решение о маршрутизации; политики безопасности и операционные политики также расходятся через пул, к которому привязан каждый домен. Один домен может применять строгий профиль WAAP, а другой ускоряться с профилем кэша. Формат журнала и отчётность можно настраивать по домену и пулу.
Выравнивание сертификата и SNI
Когда на одном IP и порту используется несколько сертификатов, TR7 запускает правильную цепочку сертификат+пул на основе значения SNI. Wildcard-сертификаты и wildcard vhost можно использовать вместе, упрощая мультидоменные TLS-операции.
Цепочка метаданных proxy сохраняется
Слой виртуальных хостов поддерживает пересылку контекста клиента и географического контекста нижестоящим слоям во время маршрутизации трафика. Бэкенд-пулы, журналирование, решения на основе геолокации и цепочки политик могут продолжать использовать необходимый контекст после разделения доменов.
Архитектура tunnel socket пула
Слой виртуальных хостов перенаправляет трафик в соответствующий пул через изолированное внутреннее соединение. Эта архитектура выполняет разделение доменов в центральной точке, сохраняя при этом изоляцию рабочего пространства каждого пула. Трафик из портала, AAM или другого пула можно обрабатывать по той же модели.
Управление vhost с учётом зоны и мультитенантности
В мультитенантных развёртываниях каждая зона управляет своим списком виртуальных хостов. Список доменов одного тенанта не смешивается с доменами другого. Конфликты доменов, границы разрешений и видимость поддерживаются в пределах границ тенанта.
Модель работы, подходящая для большого числа соединений
Группы виртуальных хостов хранятся в отдельных рабочих пространствах для большого числа соединений. Мультидоменным трафиком управляют централизованно без ограничения ёмкости соединений. Операционные изменения в одной группе доменов не затрагивают излишне другие группы.
Обновления без простоя с мягким reload
При изменении домена, пула или сертификата TR7 обнаруживает разницу в конфигурации. Только затронутый компонент обновляется через мягкий reload. Существующие соединения дренируются, пока новый трафик принимается по обновлённой конфигурации.
Поведение для неопределённых доменов управляемо
Неопределённые значения Host или SNI можно направить на дефолтный бэкенд, ответ с ошибкой или политику безопасности. Это обеспечивает контролируемое поведение в сценариях захвата поддомена и неожиданного доступа к домену.
Операционная глубина
Функция виртуальных хостов решает не только сопоставление доменов, но и стратегию reload, разделение тенантов, нормализацию wildcard и высоконагрузочные операции соединений.
Логика группировки
Виртуальные хосты, использующие одни IP, порт и тип работы, рассматриваются как группа. Сопоставления доменов внутри группы генерируются в отсортированном, детерминированном порядке. Эта структура предотвращает случайные расхождения конфигурации.
Генерация сопоставителей
Точные значения доменов обрабатываются прямым строковым сопоставлением; wildcard-домены — автоматическим сопоставлением по шаблону. Поскольку операторы не пишут regex вручную, риск ошибок снижается. Символы доменов безопасно экранируются.
Разделение SNI / Host
В режиме TLS решение принимается по значению SNI; в режиме HTTP — по заголовку Host. Это разделение выполняется автоматически. Операторам не нужно писать разную логику маршрутизации для каждого сценария.
Анализ разности конфигурации
TR7 сравнивает текущую конфигурацию с конфигурацией, которая должна быть сгенерирована. Решение о reload или restart принимается только при наличии реального отличия. Если ничего не изменилось, никаких действий не предпринимается.
Поведение мягкого reload
Мягкий reload применяется только при изменении конфигурации работающего proxy. Это предотвращает излишнее прерывание активных соединений. Если требуется более глубокое изменение рабочего пространства, выполняется контролируемый перезапуск.
Видимость тенантов
Каждая зона видит свою конфигурацию доменов и vhost. Управление доменами разделяется в мультиклиентских или многодепартаментных развёртываниях. Этот подход повышает как операционную безопасность, так и простоту управления.
Зависимость от пула
Маршрутизация виртуальных хостов имеет смысл только при активном и работоспособном соответствующем пуле. Health check пула, статус бэкенда, сертификаты и профиль WAAP определяют конечную цепочку принятия решений для трафика домена.
HTTP/2 и поведение при некорректной маршрутизации
В современных клиентах несоответствие между SNI и заголовком Host может привести к тому, что трафик попадёт на неверный бэкенд. TR7 делает такие ситуации управляемыми через цепочку виртуальных хостов и профиля безопасности.
Когда применять
Управление поддоменами мультитенантного SaaS
`tenant1.app.com`, `tenant2.app.com` и `tenant3.app.com` используют один VIP. Правило wildcard-домена захватывает все поддомены тенантов в одной записи; каждый тенант маршрутизируется в свой пул и профиль WAAP.
Разделение e-commerce и панели администратора на одном IP
`shop.example.com` идёт в публичный пул магазина; `admin.example.com` — в управленческий пул с mTLS и более строгой политикой доступа. Используется единый порт 443, политики безопасности разделяются на уровне домена.
Разделение версий API по доменам
`api.example.com` маршрутизируется в новый пул API, а `api-v2.example.com` — в устаревший пул. Во время перехода оба сервиса используют один IP; архитектура DNS и firewall остаётся неизменной.
Работа с цепочкой географических политик
Слой виртуальных хостов разделяет домен; нижестоящий слой пула применяет разные правила трафика или профили безопасности на основе географической информации. Цепочка принятия решений по домену и местоположению работает сквозным образом.
Снижение риска захвата поддомена
Неопределённые или неожиданные запросы к поддоменам переводятся под дефолтное поведение безопасности. Даже при использовании wildcard-сертификата неожиданные поддомены не могут обращаться к неконтролируемым бэкендам.
Публичный портал и приватный API на одном VIP
`portal.example.com` открыт для пользователей интернета, а `partner-api.example.com` доступен только с mTLS и IP allowlist. Оба сервиса используют один IP и порт, каждый со своим уровнем безопасности.
Часто задаваемые вопросы
В чём разница между маршрутизацией на основе SNI и Host header?
Как обрабатываются wildcard-домены?
Сколько доменов может работать на одном VIP?
Обрываются ли соединения при изменении домена?
Можно ли использовать отдельный профиль WAAP или кэша для каждого домена?
Что происходит при получении запроса к неопределённому домену?
Управляйте всеми вашими доменами через единый VIP
Разделение SNI и Host header, поддержка wildcard-доменов, WAAP на домен и reload без простоя. Проведём живое демо настройки на вашей инфраструктуре.