У меня такой сценарий:
Два Windows Server 2008 обмениваются данными в режиме клиент / сервер, между которыми находится Juniper ISG 1000 (6.3.0r6). Клиент создает около 100 новых TCP-соединений в секунду. Через некоторое время (минуты) брандмауэр, кажется, блокирует новые соединения (пакеты SYN отправляются, но не приходят на сервер). Заблокированы только некоторые новые подключения, например 1-3 / сек. Насколько мы видим, в брандмауэре не включен IDP, и он не регистрирует ничего интересного.
Если мы закроем приложение клиент / сервер, а затем запустим netcps (отправляет случайные данные tcp) на том же порту, время ожидания соединения истечет. На другом порте работает. Это должно исключить ошибки на уровне Ethernet или IP.
Обновление: мы воспроизводим это, используя nping для отправки около 60 рукопожатий TCP в секунду. Для достижения состояния, при котором большинство или все соединения прерываются, требуется несколько минут. Обнюхивание в брандмауэре Juniper с использованием как отладки потока, так и отслеживания не показывает ни одного из неудачных соединений :(. Такое же поведение между серверами без межсетевого экрана работает нормально.
Любые идеи?
Отладка потока и отслеживание ничего не показали, но запуск wirehark с зеркалированием портов показал, что трафик действительно достиг межсетевого экрана. Мы открыли заявку на поддержку Juniper.
Хорошей отправной точкой может быть проверка ваших параметров скрининга на предмет ограничений, существующих между рассматриваемыми зонами. В вашем журнале событий должны быть записи, которые ссылаются на эти блоки, если это так. Глава 3 Концепции и примеры Справочное руководство по ScreenOS: Часть 4, Обнаружение атак и механизмы защиты документ объясняет эти меры защиты.
Вы также можете выполнить отладку потока, чтобы понять причину сбоев. Статья базы знаний KB12208 показывает базовую отладку потока, но вам может потребоваться вход в службу поддержки, чтобы увидеть это.