Когда ADC и firewall управляются раздельно, цепочка безопасности ломается.
В классических архитектурах ADC живёт на одном устройстве, firewall — на другом, а правила маршрутизации и NAT существуют ещё в одном операционном слое. Это разделение выглядит аккуратно поначалу, но в production каждое изменение становится проблемой координации. Открывается новый vService, и про правило firewall забывают. DNAT меняется, а маршрут не обновляется. Сегмент бэкенда смещается, а правило FORWARD остаётся устаревшим.
В мультипространственных или мультитенантных средах проблема усугубляется. Когда у каждого тенанта есть своё IP-пространство, свои интерфейсы и свои правила NAT, единой глобальной таблицы firewall недостаточно. Один и тот же CIDR может использоваться в разных пространствах имён; в этом случае firewall также должен быть разделён по пространствам имён.
Использование отдельного устройства firewall — это не только дополнительная нагрузка на управление; аудит и failover тоже фрагментируются. Оператор не может ответить «кто открыл этот трафик?», «какое автоматическое правило пришло от какого vService?» или «в каком пространстве имён активен этот DNAT?» с единой панели. Во время инцидента нужно отдельно изучать журналы ADC, журналы firewall и состояние маршрутизации.
Безопасность применения правил — ещё одна проблема. В традиционных наборах правил firewall единственная неисправная строка может привести к сбою всей операции загрузки. В production последствие тяжёлое: корректные правила тоже не применяются, трафик прерывается или политика безопасности уходит в простой.
TR7 ADC рассматривает firewall как естественную часть ADC: наборы правил по пространствам имён, контроль по интерфейсу, автоматические правила ADC/GTM/NAT, директивы DDoS, конвейер test-apply и изоляция неисправных правил объединяются в единой модели управления.
Наш подход
Подход TR7 к firewall — это не отдельное устройство безопасности, прикреплённое снаружи, а уровень управления L3/L4, встроенный в модель трафика, маршрутизации и пространств имён ADC.
Управление firewall по пространству имён
У каждого пространства имён есть собственный менеджер firewall. Правило внутри одного пространства имён не затрагивает трафик в другом. Эта модель обеспечивает безопасную изоляцию в сценариях с несколькими тенантами, перекрывающимися CIDR и отдельными Route Tables.
Конвейер test → apply
Новое содержимое firewall сначала тестируется, затем применяется. Если строка не проходит, весь набор правил не отменяется — неисправная строка автоматически отключается, а работоспособные правила повторяются. Это предотвращает падение всего набора правил из-за единственной ошибки при изменении в production.
Параллельные наборы правил IPv4 и IPv6
Правила IPv4 и IPv6 управляются в отдельных файлах, с отдельной проверкой, параллельно. Сбой одной семьи IP не влияет на другую. В dual-stack сервисах политика безопасности применяется последовательно для обеих семей.
Автоматические правила firewall из объектов ADC
При настройке пула ADC, L4 NAT, встроенного DNAT, перенаправления DNS GTM, управляющего доступа или маркера бэкенда правила firewall могут генерироваться автоматически. Операторам, открывающим vService, не нужно помнить о стороне безопасности отдельно.
Возможности
Встроенный Firewall сочетает классический контроль L3/L4 с нативной автоматической генерацией правил ADC, защитой от DDoS, карантином, детерминированным CGNAT и изоляцией пространств имён.
Изоляция firewall по пространству имён
Каждое пространство имён работает с независимым набором правил firewall. DNAT, определённый в пространстве имён тенанта A, не влияет на тот же блок CIDR у тенанта B. Эта структура обеспечивает базовое разделение безопасности для мультитенантных сценариев и сценариев с перекрывающимися IP-пространствами.
Детерминированный CGNAT — прослеживаемость абонента без журнала сессий
Каждый абонент получает фиксированный, заранее рассчитанный блок публичных портов, поэтому определение абонента по публичному адресу и порту — арифметика, а не запрос к базе. Пожурнальная запись сессий, которую иначе требует RFC 6888 и которая обычно определяет стоимость внедрения CGNAT, исчезает, а юридическая прослеживаемость сохраняется. Включены ALG для FTP, TFTP, SIP, PPTP и H.323. Endpoint-independent filtering и hairpinning в эту версию не входят.
Раздельное управление IPv4 и IPv6
Правила IPv4 и IPv6 создаются и применяются как отдельные наборы правил. В dual-stack сервисах сторона IPv6 не забывается позднее; для обеих семей IP можно писать правила allow, deny, forward, NAT и ограничения скорости.
Dual-stack NAT, включая NAT66 — одно правило, оба семейства адресов
Один и тот же движок правил формирует наборы правил IPv4 и IPv6 из единой политики, поэтому статический SNAT, DNAT и трансляция «один в один» ведут себя в сети IPv6 точно так же. Трансляция между префиксами IPv6 — NAT66 — входит в комплект, и мы говорим об этом прямо, потому что обычно этот пункт считают отсутствующим. Нет отдельного пути настройки для IPv6 и нет правила, которое незаметно применяется лишь к одному семейству, — именно это не даёт переходу на IPv6 превратиться во второй, наполовину забытый межсетевой экран.
Определение правил по интерфейсу
Правила можно определять не только на уровне пространства имён, но и на уровне интерфейса. К управляющему интерфейсу, интерфейсу синхронизации, тенантному интерфейсу или сервисному интерфейсу можно применять разные политики. Эта модель управляет трафиком в соответствии с реальной точкой входа/выхода.
Правила allow, deny, forward и not-forward
Основные операции firewall управляются в единой модели. Разрешение, блокировка, разрешение транзитного прохода или исключение конкретного трафика из транзита — всё это можно определить в цепочках INPUT и FORWARD.
Поддержка DNAT и SNAT
DNAT можно применять для перенаправления входящего трафика на другой IP назначения; SNAT изменяет IP источника исходящего трафика. Встроенная публикация, перенаправление L4-сервисов и сценарии с несколькими сегментами бэкенда управляются этими правилами.
Сопоставление GeoIP и по стране
Сопоставление IP источника можно выполнять по наборам стран. Можно составлять allowlist определённых стран, блокировать конкретные страны или быстро отбрасывать высокорисковые регионы во время атаки. Работа на основе наборов сохраняет производительность в масштабе.
Сопоставление CIDR, MAC и инвертирование
Поддерживаются IP/CIDR, MAC-адрес и логика «исключить». Например, можно заблокировать целую подсеть, оставив конкретные IP. Эта структура используется как для операционных allowlist, так и для временных правил реагирования на инциденты.
Сопоставление нескольких портов и диапазонов портов
В одном правиле можно определить несколько портов или диапазонов портов. Широкие или узкие политики доступа можно писать для DNS, RADIUS, SIP, API и управляющих портов.
Более 20 директив защиты от DDoS
Отбрасывание некорректных пакетов, ограничение новых TCP-соединений, ограничение общего числа соединений, ограничение UDP flood, ограничение DNS/NTP flood, ограничение TCP reset, отбрасывание фрагментов, подозрительный MSS, обнаружение LAND-атаки и блокировка нулевого UDP — всё это можно включить в рамках единой политики.
Таблицы карантина
Источники, превышающие пороговое значение, добавляются во временные карантинные наборы. По истечении периода карантина запись автоматически удаляется. Наборы whitelist можно исключить из правил карантина, чтобы доверенные источники никогда не пострадали случайно.
Поддержка меток соединений для L4-персистентности
Метки соединений и списки recent можно использовать для привязки конкретного трафика клиента к одному бэкенду в L4-сервисах. Это важно для непрерывности сессий в сценариях с UDP или диапазонами портов.
Автоматические правила ADC/GTM/NAT
Поддерживаются автоматические типы правил: разрешение порта сервиса при открытии пула, генерация L4 SNAT/DNAT, создание встроенного правила DNAT, перенаправление доступа к DNS GTM или добавление локального правила deny.
Изоляция неисправных правил
Когда строка не проходит при применении набора правил, она обнаруживается, комментируется, и оставшиеся правила повторяются. Единственное неисправное правило не может остановить всю синхронизацию firewall.
Поддержка журналирования и аудита
Правила можно настраивать для генерации записей журнала. Поведение drop, allow, DNAT или карантина можно включить в цепочку аудита. После инцидента можно отследить, какое правило затронуло какой трафик.
Автоматическая защита управляющих интерфейсов и интерфейсов синхронизации кластера
Управляющий трафик и трафик синхронизации кластера обрабатываются системой особым образом. Критические интерфейсы защищены автоматическим поведением allow для предотвращения случайной потери операционного доступа.
Операционная глубина
Встроенный уровень firewall — это не просто экран написания правил; он работает совместно с тестированием, синхронизацией, изоляцией ошибок, автоматической генерацией правил и управлением жизненным циклом пространств имён.
Путь конфигурации и разделение наборов правил
Содержимое firewall IPv4 и IPv6 для каждого пространства имён хранится в отдельных конфигурационных файлах. Также сохраняется последняя объединённая конфигурация, что упрощает отслеживание изменений и отладку.
Тайм-аут синхронизации и безопасное применение
Синхронизация firewall работает в пределах определённых лимитов тайм-аута. Процесс сначала достигает состояния готовности; затем выполняются шаги test и apply. Долго выполняющаяся или зависшая операция ограничивается системой.
Параллельная синхронизация пространств имён
При наличии многих пространств имён синхронизация firewall выполняется пакетами параллельно. Это делает операционно управляемым наличие собственного набора правил у каждого пространства имён в мультитенантных средах.
Автоматические типы правил
Автоматические типы правил pool-tcp-udp, ftp-allow, l4-snat, l4-any-dnat, l4-any-snat, inline-dnat, fw-access-allow, fw-access-dnat, gtm-dns-dnat, gtm-access-dnat, local-deny и be-mark могут генерироваться из объектов ADC.
Отслеживание соединений
Обратные потоки для трафика RELATED и ESTABLISHED распознаются автоматически. Это снижает необходимость писать отдельные ручные правила для каждого обратного пакета в stateful-сервисах.
Hashlimit и connlimit
Поддерживаются ограничения скорости на источник и ограничения соединений. Избыточные соединения, пакеты reset, ICMP-пакеты, UDP flood DNS/NTP или новые попытки TCP-соединений с одного IP — всё это можно ограничить.
ICMP и обнаружение соседей IPv6
Полная блокировка ICMP может нарушить основные сетевые функции, такие как IPv6 и Path MTU Discovery. TR7 обрабатывает политики ICMP с детализацией; необходимые сообщения обнаружения и управления можно безопасно настраивать.
Итоговый набор правил после восстановления от ошибок
После комментирования неисправных правил итоговый набор правил записывается обратно на диск. Операторы могут видеть, какая строка была отключена, и исправить её. Система даёт видимый, применимый результат вместо молчаливого сбоя.
Когда применять
Снижение SSH brute-force на управляющем интерфейсе
SSH-соединения к управляющему интерфейсу ограничиваются лимитом на источник. Если один IP превышает заданный порог, он временно помещается в карантин. Поверхность brute-force уменьшается, пока управляющий доступ остаётся открытым.
Политика доступа по стране
Разрешается только трафик из выбранных стран; весь остальной отбрасывается. Это обеспечивает быстрый контроль для снижения рисков на основе страны в финансовых, государственных или медицинских системах.
Разделение DNAT для нескольких тенантов
Пока DNAT 1.2.3.4 → 10.0.0.5 применяется в пространстве имён тенанта A, тенант B может использовать тот же внутренний CIDR с другим правилом. Изоляция пространств имён гарантирует, что NAT-политики двух тенантов не конфликтуют.
Встроенное смягчение DDoS
UDP zero-byte flood, DNS/NTP flood, аномальный TCP, фрагменты и connection flood смягчаются с помощью механизмов hashlimit, connlimit и карантина. Базовая защита L3/L4 применяется без отдельного устройства очистки.
Контролируемый транзит между сегментами через цепочку FORWARD
Когда нужен транзитный трафик между двумя сегментами бэкенда, контролируемый проход устанавливается с помощью правил FORWARD. Точно определяется, какой источник может достичь какого назначения на каком порту.
Встроенная публикация DNAT
IP бэкенда публикуется через TR7, а входящий трафик доставляется на соответствующий бэкенд через встроенный DNAT. Уровень безопасности и маршрутизации TR7 вставляется без изменения приложения или IP-плана бэкенда.
Часто задаваемые вопросы
В чём разница между firewall по пространству имён и глобальным firewall?
Если написано неисправное правило, весь firewall ломается?
Управляются ли правила IPv6 отдельно от правил IPv4?
Нужно ли отдельное устройство для защиты от DDoS?
Могут ли правила firewall генерироваться автоматически из объектов ADC?
Как работает сопоставление GeoIP и влияет ли оно на производительность?
Управляйте сетевой безопасностью с той же консоли, что и вашим ADC
Изоляция пространств имён, директивы DDoS, DNAT/SNAT и автоматическая генерация правил — проведём живое демо настройки в вашей среде.