☰

如何验证防火墙是否关闭了非活动连接？

tag-icon • tag-icon firewall connection timeout glassfish
如何验证防火墙是否关闭了非活动连接？

如何验证防火墙是否在 N 分钟不活动之后关闭了端口 X 与服务器的连接？

背景：我正在开发一个部署到 Glassfish 应用服务器的 Java EE 应用程序。客户端使用以下方式与应用程序通信远程管理信息系统（TCP）。我发现 60 分钟不活动后连接断开。我怀疑是防火墙超时，因此运营团队将超时时间改为 90 分钟，以查看是否影响行为，但我仍然发现 60 分钟不活动后连接断开。我想使用比 Java EE 和 RMI-IIOP 更简单的机制来验证防火墙超时是否正常工作。

答案1

如果可用或可以安装，请查看 netcat。您可以执行类似这样的操作。

在服务器运行：

nc -l 31415

在客户端运行：

nc -w 5400 <server> 31415

您可以将端口号更改为任何您喜欢的号码，只要确保您可以从测试位置访问它即可。

-w 5400上例中设置的超时时间为 90 分钟 ( )。请根据需要进行更改。

您可以从多个位置进行测试：在服务器本身上、在同一网络上的另一台服务器/设备上、在任何 VPN、路由器或防火墙另一端的客户端上。

有关 netcat 的更多有用信息：

http://www.thegeekstuff.com/2012/04/nc-command-examples/

答案2

首先，确认应用程序的任何一方都不会在空闲一段时间后关闭连接。这可以通过捕获双方的流量（在 Windows 中使用 Wireshark，在 Linux 中使用 tcpdump）然后检查它以查找与关闭相关的数据包（例如 FIN 或 RST）来实现。

现在，如果你确认应用程序端都没有关闭连接，但是当你在给定的超时后尝试发送新数据包时，连接不再有效（你会在流量日志中观察到几次重新传输尝试），很可能是由于状态防火墙在给定的空闲会话超时后从其状态表中删除了连接，例如，Linux Netfilter 空闲连接跟踪超时默认为 5 天，如https://www.kernel.org/doc/Documentation/networking/nf_conntrack-sysctl.txt，nf_conntrack_tcp_timeout_established。

现在，为了解决前面的情况，首先缩短客户端和服务器之间的网络路径（例如，使用 VPN 将客户端和服务器放在同一子网中），并检查连接是否不再超时，以确保万无一失。

然后，从常规网络路径（或逐步向其中添加节点）打开一个新连接，等待 X 时间并尝试发送新数据包，如果到达，则将 X 值加倍并再次发送数据包，并继续执行此操作，直到不再发送数据包，这将为您提供配置超时的好主意。现在，当然，前面的步骤可以通过一个简单的多线程客户端应用程序自动完成，否则这只是一次糟糕的测试体验。

相关内容