В настройках NGFW режимы Fail Open и Fail Close отвечают за поведение устройства в момент, когда защита или инспекция перестают укладываться в нормальный режим работы. Проще говоря, система должна выбрать одно из двух. Либо пропустить трафик дальше, чтобы сеть не встала, либо закрыть доступ, чтобы непроверенный поток не прошел через периметр.
Проблема начинается там, где эту тему превращают в красивую галочку в таблице. На портале строка «Fail Close / Fail Open» выглядит простой и понятной, но на практике говорит не о «качестве выживания под нагрузкой», а в первую очередь о наличии механизма и возможности настроить поведение при срабатывании условий высокой нагрузки. В методике логика описана прямо: в режиме Fail Close система должна закрывать доступ, а в режиме Fail Open оставлять доступ открытым. Формулировка полезная, но очень базовая.
Что на самом деле означают Fail Open и Fail Close
Fail Open обычно выбирают там, где простой связи опаснее, чем временное ослабление контроля. Такой подход встречается на узлах, где нельзя просто взять и остановить бизнес-процесс, доступ к сервисам или внешние интеграции. Цена решения понятна: в аварийном режиме часть трафика может пройти без той глубины проверки, на которую рассчитывали в штатной работе.
Fail Close используют там, где пропуск непроверенного трафика опаснее простоя. Такой режим ближе к консервативной модели безопасности. Если модуль проверки перестал справляться, доступ закрывается. С точки зрения защиты логика жесткая, но честная. С точки зрения эксплуатации такой выбор легко превращает перегрузку, сбой модуля или кривое обновление в реальный отказ сервиса.
Fail Open отвечает на вопрос «что важнее, чтобы сеть жила». Fail Close отвечает на вопрос «что важнее, чтобы непроверенный трафик не прошел». Универсально правильного варианта здесь нет.
Как читать таблицу ngfw.jet.su без лишних иллюзий
На портале смешаны карточки с разными поколениями методики, от v1.0 до v3.0, а последний апдейт датирован 25 марта 2026 года. Поэтому горизонтальное сравнение остается полезным, но идеальной симметрии условий тут лучше не воображать. Рядом с одной и той же строкой могут стоять одинаковые значки, а реальная инженерная зрелость решений при этом будет заметно отличаться.
Самая частая ошибка выглядит так: читатель видит в строке «Fail Close / Fail Open» отметку «Да» и мысленно дорисовывает красивую картину, где устройство мягко деградирует, аккуратно держит сессии, предсказуемо отрабатывает пороги и не ломает соседние функции. Таблица такого обещания не дает. Таблица сообщает лишь, что механизм в тестовом объеме заявлен или найден.
| Элемент таблицы на ngfw.jet.su | Что показывает | Чего не показывает | Какой вывод делать |
|---|---|---|---|
| «Да» в строке Fail Close / Fail Open | В продукте есть настраиваемое поведение при срабатывании условий высокой нагрузки | Не доказывает мягкую деградацию, правильные пороги, сохранение сессий и одинаковую работу всех модулей | Считать базовым допуском к дальнейшему разговору, а не победой в сравнении |
| «±» | Поддержка есть, но с оговорками, частично, только для части модулей или в ограниченном сценарии | Не равно полноценной двусторонней логике «и Fail Open, и Fail Close везде, где нужно» | Сразу искать ограничения, комментарии и соседние строки |
| «Нет» | Явного механизма в рамках методики не нашли | Не означает, что устройство совсем беспомощно в аварии, но осознанно выбрать поведение может быть нельзя | Для нагруженного периметра уже повод задавать неприятные вопросы вендору |
| Нагрузочное тестирование EMIX | Показывает, где устройство достигает предела на смешанном профиле трафика | Не равно паспортной скорости из буклета | Сопоставлять с ростом числа правил и смотреть, не прячется ли за красивой строкой Fail Open банальная просадка производительности |
| Поведение при обновлении правил | Показывает, рвутся ли сессии и как продукт переживает изменения политики | Не заменяет тест перегрузки | Хорошо помогает понять зрелость контрольной плоскости |
| Поведение при асимметричной маршрутизации | Показывает, насколько МСЭ терпим к реальной сетевой грязи | Не равно качеству IPS или SSL Inspection | Если здесь хрупко, красивая история про перегрузку уже не выглядит убедительно |
Отдельный нюанс из методики часто пропускают. Документ допускает настройку поведения «целиком или для отдельных модулей». Для покупателя это не мелкая оговорка, а центральный вопрос. Если продукт умеет Fail Open только в одном участке цепочки, а критичный модуль ведет себя по другой логике, формальная поддержка режима мало что говорит о реальном риске.
Хороший пример того, как нужно читать такую строку аккуратно, дает карточка PT NGFW 1.7.2, где напротив кейса стоит «±». Такой знак полезнее слишком уверенного «Да», потому что сразу заставляет искать границы реализации. Частичная поддержка с честной пометкой лучше, чем широкое обещание без расшифровки, которое покупатель потом сам достраивает в голове.
Где начинается маркетинговый туман
Маркетинговый туман появляется в момент, когда строку Fail Open / Fail Close подают как доказательство общей отказоустойчивости. Отказоустойчивость на периметре нельзя свести к одному переключателю. Нужно смотреть, что происходит с уже открытыми сессиями, как ведут себя IPS, SSL Inspection, контроль приложений, журналы, маршрутизация, кластеры и переключение линков. Даже идеальная логика «открыть или закрыть» не спасает продукт, который резко проседает при росте числа правил, рвет соединения при обновлении политики или ведет себя нервно в нетипичной топологии.
Поэтому строку про Fail Open / Fail Close всегда стоит читать рядом с нагрузочным разделом. На ngfw.jet.su предел в нагрузочных тестах фиксируют там, где потери пакетов или сессий становятся больше 1%. Вот где заканчивается теория и начинается реальная цена архитектурных решений. Если режим перегрузки формально есть, а производительность под ростом правил сыпется слишком рано, для эксплуатации такая комбинация может оказаться хуже, чем скромная, но предсказуемая реализация.
Есть и еще одна ловушка. Fail Open не всегда означает «безопасность выключилась полностью», а Fail Close не всегда означает «все умерло мгновенно». У разных вендоров логика может срабатывать на разных этапах цепочки, по разным порогам и с разным объемом обхода. Поэтому прямой вопрос вендору должен звучать не «поддерживаете ли вы Fail Open», а «какие именно модули и в каких условиях переходят в Fail Open, что происходит с новыми и существующими сессиями, и где остаются журналы событий».
Что спрашивать у вендора до пилота
Перед пилотом лучше не спорить о терминах, а быстро снять конкретику. Какие модули могут перейти в Fail Open, какие всегда останутся в Fail Close, кто задает порог срабатывания, сохраняются ли текущие сессии, меняется ли логирование, как ведет себя кластер, и можно ли воспроизвести сценарий на стенде под вашей нагрузкой. После такого разговора половина красивых презентаций резко теряет вес.
Fail Open всегда хуже с точки зрения безопасности?
Не всегда. Для некоторых сервисов отказ связи дороже временного ослабления контроля. В таких сегментах Fail Open может быть осознанным компромиссом, если команда понимает пределы риска и умеет их мониторить.
Fail Close всегда правильный выбор для периметра?
Тоже не всегда. Fail Close хорошо звучит до первого реального инцидента, где перегрузка превращает защиту в самодельный отказ сервиса. Для критичных бизнес-сервисов такая жесткость бывает слишком дорогой.
Можно ли сравнивать решения по одной строке из таблицы?
Нет. Строка дает только первичный сигнал. Сравнение начинает работать, когда рядом лежат данные по нагрузке, обновлению правил, асимметричной маршрутизации, отказу линков и кластерному поведению.
Что означает знак «±»?
Обычно частичную поддержку, ограничения реализации или зависимость от конкретного модуля и сценария. Такой знак не надо читать как «почти да». Его надо читать как «идем смотреть примечания».
Где чаще всего ошибаются при чтении ngfw.jet.su?
Чаще всего путают наличие функции с качеством реализации. Наличие механизма еще не означает, что продукт красиво и предсказуемо переживает реальную перегрузку.
Практический вывод простой. Хороший NGFW не тот, у которого в строке Fail Open / Fail Close стоит «Да», а тот, у которого логика аварийного поведения совпадает с задачами периметра, соседние тесты не показывают хрупкость, а нагрузочная часть не превращается в резкий обрыв при росте правил и включенных модулей.
