0

我们有一个产品，其中本地 linux 机器“SCANNER”在本地网络上进行一些轮询，然后使用 pg_query（服务器运行 PostgreSQL 9.5.5）通过 OpenVPN 连接将信息填充到我们云服务器中的数据库中。

SCANNER 上有一个 PHP (5.5.9) 守护程序，它在“while”循环中检查数据库以完成工作。这一直很有效，并且继续在我们所有的客户网络上运行良好，除了一个最近出现了一个奇怪的问题。

在他们升级了防火墙（一个 Checkpoint 5200，据我们所知，所有规则都是正确的，允许通过 VPN 从 SCANNER 到我们的云服务器的流量），一个脚本中的一个查询无限期挂起。以下是我们注意到的症状：

大多数情况下，查询工作正常，脚本继续。每隔一段时间，pg_query() 调用就会阻塞并且永远不会返回。并不是说有错误；该调用实际上会永远阻塞（或者在我们手动重新启动之前的几个小时）。

这个查询很长一段时间都是一样的，在我们的任何其他客户端上，我们从来没有遇到过这个问题，也没有在这个客户端上遇到过这个问题，直到他们改变了他们的防火墙。

我们可以通过查看云服务器上的 pg_stat_activity 表来判断该查询确实到达了云，然后永远位于该表中。在每种情况下，pg_stat_activity.state='idle' 和 pg_stat_activity.waiting=false

在此期间，我们仍然可以通过 VPN 从 SCANNER ping 云服务器，并且可以继续从 SCANNER 上的其他脚本和 SCANNER 的命令行成功查询其远程数据库。

这个客户端碰巧有两台不同的 SCANNER 机器，在不同的子网上但在同一个防火墙后面。此问题可能随时出现在任何一个上，但不一定同时出现在两个上（至少没​​有任何统计意义）。

如果我们重新启动守护进程，问题就暂时解决了。但它通常会在 2 秒到几个小时后的某个时间再次出现。

我们正在寻找任何可能解决问题的输入，无论是与我们的应用程序还是防火墙本身（我们已获得根据需要进行修改的权限）相关。随时提出任何澄清问题。

提前致谢！

4

2 回答 2

0

Check Point 防火墙具有许多高级威胁防护，根据购买的刀片，该设备可能会阻止您的数据库和应用程序之间的通信。尝试使用 Check Point 日志工具（Tracker、SmartEvent 或 NGSE）过滤防火墙日志。过滤源或目标是扫描仪或数据库服务器 IP 地址的所有事件。如果您的 TCP 数据包中有一些丢弃块，日志将显示这一点。

如果您的防火墙拓扑使用集群配置尝试检查您的配置，它可能配置错误并且数据库 TCP 会话处于活动状态但数据包正在使用另一个网络路径。

如果您使用 Check Point VPN 客户端，请尝试将其更新到最新版本并使用最新更新包（Take）更新您的防火墙设备。

如果问题仍然存在，请获取证据以证明您在没有 Check Point 硬件的情况下无法停止通信以及您的问题的一些证据，并要求您的 Check Point 解决方案提供商与 Check Point 开立案例。

于 2017-02-03T10:38:42.813 回答
0

我们解决了这个问题。从技术上讲，我们从来没有弄清楚它发生的确切原因，但是 VPN 服务器以错误的顺序接收 UDP 数据包，或者有时根本没有。防火墙没有给我们任何迹象表明它正在这样做，所以我们可以认为这是 CheckPoint 多层威胁保护的未记录副作用。

我们转而使用基于 TCP 的 OpenVPN 而不是 UDP，这似乎解决了问题。希望从长远来看，我们不会受到任何不利影响！

于 2017-02-06T20:34:17.973 回答