Как я могу убедиться, что брандмауэр закрывает соединения порта X с сервером после N минут бездействия?
Предыстория: я работаю над приложением Java EE, развернутым на сервере приложений Glassfish. Клиенты общаются с приложением, используя RMI-IIOP (TCP). Я вижу, что соединение прерывается после 60 минут бездействия. Я подозреваю, что истекло время ожидания брандмауэра, поэтому операционная группа изменила тайм-аут на 90 минут, чтобы проверить, повлияло ли это на поведение, но я все еще вижу, что соединения прерываются после 60 минут бездействия. Я хотел бы убедиться, что тайм-аут межсетевого экрана работает правильно, используя более простой механизм, чем Java EE и RMI-IIOP.
Если он доступен или может быть установлен, взгляните на netcat. Вы могли бы сделать что-то подобное.
На сервере запустить:
nc -l 31415
На клиенте запускаем:
nc -w 5400 <server> 31415
Вы можете изменить номер порта на любой другой, просто убедитесь, что вы можете получить к нему доступ с того места, где вы проводите тестирование.
Тайм-аут 90 минут (-w 5400) установлен в примере выше. При необходимости измените это.
Вы можете проверить это из нескольких мест: на самом сервере, на другом сервере / устройстве в той же сети, на клиентах с другой стороны любой VPN, маршрутизаторов или межсетевых экранов.
Дополнительная полезная информация о netcat:
Во-первых, начните с подтверждения, что это не какая-либо сторона приложения, закрывающая соединение после некоторого периода бездействия. Это можно сделать, перехватывая трафик (в Windows используйте Wireshark и tcpdump в Linux) с обеих сторон, а затем проверяя его на предмет наличия пакетов, связанных с закрытием (например, FIN или RST).
Теперь, если вы подтверждаете, что ни одна из сторон приложения не закрывает соединение, но когда вы пытаетесь отправить новый пакет по истечении заданного тайм-аута, соединение больше не действует (вы увидите несколько попыток повторной передачи в журнале трафика), скорее всего, что это вызвано тем, что межсетевой экран с отслеживанием состояния удаляет соединения из своей таблицы состояний после заданного тайм-аута сеанса простоя, например, тайм-аут отслеживания простоя Linux Netfilter по умолчанию равен 5 дням, как указано в https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt, nf_conntrack_tcp_timeout_established.
Теперь, чтобы устранить предыдущее состояние, начните с сокращения сетевого пути между клиентом и сервером (например, используя VPN, чтобы поместить клиент и сервер в одну подсеть) и убедитесь, что время ожидания соединения больше не истекает, просто чтобы быть уверенным.
Затем, используя обычный сетевой путь (или постепенно добавляя к нему узлы), откройте новое соединение, дождитесь времени X и попытайтесь отправить новый пакет, если он прибудет, затем удвойте значение X и снова отправьте пакет и продолжайте делать это до тех пор, пока пакет не перестанет отправляться, что даст вам хорошее представление о настроенном тайм-ауте. Теперь, конечно, предыдущее можно автоматизировать с помощью простого многопоточного клиентского приложения, иначе это просто ужасный опыт тестирования.