postgresql 查詢在 VPN 上無限期掛起 - 新防火牆
我們有一個產品，其中本地 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 秒到幾個小時後的某個時間再次出現。
我們正在尋找任何可能解決問題的輸入，無論是與我們的應用程序還是防火牆本身（我們已獲得根據需要進行修改的權限）相關。隨時提出任何澄清問題。
提前致謝！
我們解決了這個問題。從技術上講，我們從來沒有弄清楚它發生的確切原因，但是 VPN 伺服器以錯誤的順序接收 UDP 數據包，或者有時根本沒有。防火牆沒有給我們任何跡象表明它正在這樣做，所以我們可以認為這是 CheckPoint 多層威脅保護的未記錄副作用。
我們轉而使用基於 TCP 的 OpenVPN 而不是 UDP，這似乎解決了問題。希望從長遠來看，我們不會受到任何不利影響！