我们有一个产品，其中本地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秒到几个小时之后的某个时间再次出现。
我们正在寻找可能解决问题的任何输入，无论是与我们的应用程序还是防火墙本身（我们已根据需要获得修改权限）。随意提出任何澄清问题。
提前致谢！
答案 0 :(得分：0)
Check Point防火墙有很多高级威胁防护，根据获得的刀片，设备可以阻止数据库和应用程序之间的通信。尝试使用Check Point日志工具（Tracker，SmartEvent或NGSE）过滤防火墙日志。过滤源或目标是扫描程序或数据库服务器IP地址的所有事件。如果你的TCP包中有一些丢失，那么日志就会显示出来。
如果您的防火墙拓扑使用群集配置尝试检查您的配置，则可能是配置错误，数据库TCP会话处于活动状态，但数据包正在使用其他网络路径。
如果您使用的是Check Point VPN客户端，请尝试将其更新为上一版本，并使用上次更新包更新防火墙设备（Take）。
如果问题仍然存在，请获取证据证明您没有Check Point硬件的通信没有停止，并且您的问题有一些证据，并要求Check Point解决方案提供商打开Check Point案例。
答案 1 :(得分：0)
我们解决了这个问题。从技术上讲，我们从来没有弄清楚它究竟发生的原因，但是VPN服务器收到的UDP数据包顺序不正确，有时根本没有。防火墙没有给我们任何迹象表明它正在这样做，所以我们可以认为它是CheckPoint多层威胁防护的未记录的副作用。
我们切换到通过TCP而不是UDP使用OpenVPN，这似乎解决了这个问题。希望我们不会受到长期的任何不利影响！