☰

經過幾次嘗試後，連線請求會因 SYN_SENT 而掛起

tag-icon • tag-icon networking ssh
經過幾次嘗試後，連線請求會因 SYN_SENT 而掛起

我們搬遷了辦公室，並在新地點設置了 LAN/WAN 基礎設施。

當我啟動與我的伺服器（位於雲端中，而不是LAN 中）的SSH 連線時，對於短時間間隔的前3 或4 個請求（例如5 秒內的4 個呼叫），它可以正常工作，後續連線將掛起在SYN_SENT 狀態。稍後的請求都會因 SYN_SENT 而掛起，直到看起來逾時。之後它會再次工作幾次。

沒有對伺服器進行任何更改，不同的本機客戶端也以這種方式運作。所以我猜差異在於 IT 基礎設施，而不是兩個端點。

對於這種行為有哪些可能的解釋？我應該去哪裡尋找修復方法？

我們使用必須重置的 Zyxel ZyWall 防火牆 - 這是否有一些過濾器可以解釋這種行為？

答案1

伺服器上的 iptables 規則有一個「反 ssh 暴力破解」規則鏈，該規則鏈使用「最近」模組在 1 分鐘內進行 4 次嘗試後斷開連接。這條規則在鏈中有一個例外INPUT，允許來自我們的臉部 IP 的所有 ssh。隨著我們的移動，臉部 IP 發生了變化，規則也必須進行調整。作為參考，我就是這樣做的

列出所有 iptables 規則

# iptables -L --line-numbers

請注意鏈中的接受規則INPUT，該規則設置為接受來自我們（之前的）人臉 IP 位址的所有 ssh 連接，以及反暴力破解規則，該規則在鏈中多次嘗試後會刪除 ssh 連接SSH_CHECK：

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
...
14   ACCEPT     tcp  --  old.myISP.com      anywhere tcp dpt:ssh
...
Chain SSH_CHECK (1 references)
num  target     prot opt source               destination
...
3    DROP       all  --  anywhere             anywhere            recent: UPDATE seconds: 60 hit_count: 4 TTL-Match name: RECENT_SSH side: source

編輯規則/etc/iptables.rules

改變

-A INPUT -s 123.45.67.8/32 -p tcp -m tcp --dport 22 -j ACCEPT

到

-A INPUT -s 111.222.33.44 -p tcp -m tcp --dport 22 -j ACCEPT

其中 111.222.33.44 是新的面孔 IP。並閱讀改編後的規則：

 # iptables-restore < /etc/iptables.rules

相關內容