Слишком жёсткое правило трафика не справляется с современными сценариями; слишком сырое превращает эксплуатацию в разработку ПО.
Решения по маршрутизации в трафике корпоративных приложений больше не зависят только от хоста, пути или порта. Исправление заголовков, совместимость с устаревшими приложениями, CORS-политика, безопасность cookie, ограничение полосы пропускания, запуск captcha, карантин, пользовательские страницы ошибок и трансформация ответов — всё это встречается на одном и том же пути трафика. Простых правил балансировки нагрузки недостаточно для этого разнообразия.
Большинство традиционных подходов склоняются к одному из двух крайностей. Либо операторам предоставляется лишь несколько предустановленных действий, и современные случаи использования становятся неразрешимыми, либо полная гибкость требует написания сырых скриптов или низкоуровневой конфигурации. Во второй модели каждое изменение правила привязывается к тяжёлым процессам — разработка ПО, тестирование, code review и аудит безопасности.
Риск возрастает ещё больше, когда нет чёткого контроля над тем, к какому типу сервиса или фазе трафика применяется действие. Написание действия HTTP-заголовка для TCP-сервиса, ожидание поведения запроса на стороне ответа или добавление ограниченного по пулу действия более одного раза — всё это может вызвать проблемы во время выполнения.
Правильная модель сочетает визуальный редактор правил со скомпилированным поведением во время выполнения. GUI должен показывать только допустимые комбинации; метаданные действий должны управлять типом сервиса и фазой запроса/ответа; а контролируемый аварийный выход для ручных правил должен оставаться доступным для граничных случаев.
TR7 Traffic Rules Engine достигает этого баланса: предоставляет операторам 56 готовых действий, скрывает недопустимые комбинации и переводит правильные правила в продакшн-трафик как проверенную конфигурацию.
Наш подход
TR7 применяет правила трафика через таксономию действий, осведомлённость о фазе, скомпилированную конфигурацию и модель валидированного продвижения.
Метаданные действия определяют допустимые комбинации заранее
Каждое действие несёт метаданные о типе сервиса, фазе запроса/ответа, поддержке условий, требованиях к контенту, поведении кода ошибки и ограничении использования на пул. GUI читает эти метаданные и показывает только допустимые параметры правил для текущего контекста.
Правила компилируются в конфигурацию среды выполнения в правильном порядке
Действия, составленные в визуальном редакторе, выдаются в рабочую конфигурацию в определённой последовательности приоритетов. Присвоение переменных, маршрутизация, операции с заголовками, поведение при ошибках и выбор backend — всё выполняется в предсказуемом порядке.
Продвинутые действия при необходимости направляются через путь выполнения на основе Lua
Некоторые продвинутые действия, которые нельзя выразить как статические директивы, преобразуются в вызываемые функции во время выполнения. Операторы могут управлять сложными моделями поведения трафика через движок правил без написания какого-либо кода самостоятельно.
Новый набор правил не может достичь активного трафика до прохождения проверки
Новая конфигурация генерируется и затем проходит этап проверки. Если проверка не проходит, текущая работающая конфигурация сохраняется, и ошибочное правило никогда не достигает продакшн-трафика.
Возможности
Движок правил трафика сочетает готовые действия с FX-условиями для обеспечения контролируемого применения политики по всему пути запросов и ответов.
56 готовых действий определяют поведение трафика без скриптинга
TR7 предоставляет более 30 действий, включая add_header, del_header, set_header, replace_header, redirect_scheme, req_redirect_location, set_path, normalize_uri, req_auth, cors, ipMask, cookieEncryption, bandwidthRule, advancedCaptcha, modifyResponse, silentLog, securityHeaders, cookieSecurity, deny, quarantine_table, manualRule и prometheusService. Операторы выбирают действия в визуальном редакторе, заполняют параметры и прикрепляют условия. Это убирает обычные задачи манипуляции трафиком из области скриптинга. Операционные команды создают правила быстрее и снижают зависимость от команд разработки.
Группы действий разделяют сценарии запросов, ответов и ошибок
Действия представлены под семантическими группами, такими как atRequest, atResponse, errorRules, cookieBased и tcpRules. Это разделение немедленно даёт понять, в какой фазе трафика будет выполняться правило. Операции с заголовками и путями на стороне запроса не смешиваются с заголовками безопасности и поведением страниц ошибок на стороне ответа. GUI снижает техническую сложность и организует создание правил по намерению.
Осведомлённость о типе сервиса предотвращает появление недопустимых действий
Каждое действие несёт информацию о совместимости для HTTP, TCP или обоих типов сервисов. HTTP-специфичные действия, такие как CORS, манипуляция заголовками, безопасность cookie и перезапись пути, не отображаются для TCP-сервисов. TCP-специфичные действия, такие как параметры управления соединением, не представляются как варианты выбора в HTTP-сервисе. Этот подход предотвращает выбор операторами правила, которое не может работать, ещё до попытки сохранить его.
Контроль фазы запроса и ответа снижает ошибки во время выполнения
Метаданные точно определяют, в какой фазе действительно каждое действие. Действия, которые должны выполняться в фазе запроса, не могут случайно быть прикреплены к стороне ответа, а действия, ориентированные на ответ, не могут быть ошибочно привязаны к пути запроса. Когда действие допустимо в обеих фазах, это управляется явно. Недопустимые комбинации выявляются во время проверки конфигурации до достижения продакшн-трафика.
FX-условия привязывают действия к богатому контексту трафика
Действия могут выполняться безусловно или быть привязаны к условиям, написанным на FX-языке выражений. IP источника, страна, ASN, путь, заголовок, cookie, поле тела, роль пользователя, WAAP-оценка и значения таймера — всё это может использоваться в одной модели условий. Несколько условий объединяются с логикой ACL, чтобы определить, когда срабатывает действие. Это делает движок правил контекстно-осведомлённым и контентно-осведомлённым лицом, принимающим решения, а не просто статической таблицей маршрутизации.
Ограничения на пул снижают риск дублирования и конфликтующего использования
Некоторые действия должны присутствовать только один раз в данном пуле. Добавление второго экземпляра шифрования cookie, коррекции IP или сохранения имени заголовка может давать неожиданные результаты. TR7 хранит максимальное количество использований на пул в метаданных каждого действия и не позволяет GUI добавлять второй экземпляр. Эта защита снижает операционные несоответствия до достижения продакшна.
Аварийный выход через ручное правило обеспечивает контролируемую гибкость для граничных случаев
Когда предустановленное действие не охватывает конкретный сценарий, manualRule позволяет вставить сырое правило трафика. Эта функция служит аварийным выходом для продвинутых сценариев вне стандартного каталога движка. Ручные правила всё равно проходят этап проверки конфигурации и должны использоваться с осторожностью, поскольку напрямую влияют на поведение сервиса. Таким образом, платформа предлагает как удобство визуальных правил, так и гибкость продвинутого уровня в одной модели.
Действия для cookie, CORS, заголовков безопасности и карантина готовы к использованию
Действие cookieSecurity может применять атрибуты cookie Secure, HttpOnly и SameSite; cookieEncryption может шифровать выбранные значения cookie при передаче. Действие cors консолидирует список разрешённых источников, методы, заголовки и настройки кэша preflight под одной политикой. securityHeaders централизованно применяет базовый набор заголовков безопасности. quarantine_table помещает конкретный IP или клиентскую подпись в карантин на определённый период, сдерживая повторное плохое поведение на границе.
Операционная глубина
Правила трафика эксплуатируются с атомарным продвижением, версионированием, синхронизацией кластера, управлением конфликтами, мониторингом и обработкой граничных случаев.
Атомарное продвижение конфигурации
Новый набор правил генерируется отдельно и проверяется перед вступлением в силу. Если проверка проходит успешно, активная конфигурация заменяется; если нет — текущая работающая конфигурация сохраняется. Эта модель помогает предотвратить прерывание продакшн-трафика ошибочным правилом.
Записи версий и аудита
Каждое изменение правила должно записываться с идентификатором и меткой времени. Операционная команда может видеть, кто изменил какое правило, какой пул был затронут и к какой версии нужно откатиться при необходимости. Эти записи имеют особое значение при проверках безопасности и соответствия требованиям.
Синхронизация кластера
В высокодоступных развёртываниях один и тот же набор правил должен быть распределён на все узлы-пиры. Без этого разные узлы за одним VIP могут демонстрировать различное поведение трафика. TR7 рассматривает поддержание согласованности наборов правил в кластере как часть своей операционной модели.
Поведение конфликтующих действий
Когда более одного действия нацелено на один и тот же заголовок или поле трафика, решающим фактором становится порядок приоритета. Система выдаёт действия в определённой последовательности; конечное поведение зависит от этой последовательности. Операторы должны оценивать потенциальные конфликты в критических правилах с помощью записей аудита и логики приоритетов.
Мониторинг выполнения действий
Выполняются ли действия, можно отслеживать через silentLog и перенаправлять в SIEM как выделенное поле. Это показывает, сколько запросов фактически совпало с правилом, при каких условиях оно срабатывало и дало ли ожидаемый эффект. Наблюдаемость не позволяет движку правил вести себя как чёрный ящик.
Поведение заголовков HTTP/2
Некоторые устаревшие backend-сервисы чувствительны к регистру имён заголовков. Действие keepHeaderNames помогает сохранить исходный регистр имён заголовков в таких сценариях совместимости. Эта настройка должна использоваться только для сервисов, которые действительно этого требуют, и должна тестироваться совместно с поведением приложения.
Когда применять
Трансформация ожиданий по заголовкам для устаревших приложений
Команды по модернизации могут использовать replace_header или set_header для перевода имени заголовка, ожидаемого устаревшим backend, в форму, требуемую приложением. Уровень совместимости создаётся на входной точке трафика без изменения кода приложения.
Централизованное применение заголовков безопасности для всех сервисов
SaaS-команды могут использовать действие securityHeaders для централизованного добавления часто требуемых заголовков безопасности перед сервисами. Базовый уровень безопасности укрепляется без необходимости каждой команде приложения самостоятельно настраивать одни и те же параметры.
Ограничение скорости и запуск captcha в процессах входа
Финансовые приложения могут комбинировать действия bandwidthRule и advancedCaptcha для запуска captcha-задачи после повторных неудачных попыток входа. Подозрительное повторное поведение направляется в более строгий процесс верификации без полного прерывания пользовательского опыта.
Защита сессионных cookie на стороне клиента
Электронная коммерция и финансовые сервисы могут использовать cookieEncryption для доставки сессионных cookie клиенту в зашифрованном виде. Backend продолжает видеть ожидаемое значение, тогда как содержимое cookie нечитаемо в значимом смысле на стороне клиента.
Часто задаваемые вопросы
Какие группы действий чаще всего используются среди 56?
Что происходит, если действие прикреплено к неправильной фазе — запроса или ответа?
Какие действия доступны для TCP-сервисов?
Когда следует предпочесть действие manualRule?
Какие источники данных поддерживают FX-условия?
Как обновить правило, не влияя негативно на продакшн-трафик?
Возьмите под контроль поток трафика с помощью движка правил
Полный контроль по всему пути запросов и ответов с 56 готовыми действиями, FX-условиями и атомарным продвижением конфигурации. Позвольте нам провести вас через живую настройку на ваших собственных сервисах.