SSH 連線在 4G 熱點上凍結,但在任何 Wifi 上都不會凍結

SSH 連線在 4G 熱點上凍結,但在任何 Wifi 上都不會凍結

簡短的介紹

多年來我一直在 SSH 連接上看到奇怪的行為,但直到今天才想到提出問題。我嘗試對此進行了很多搜索,但找不到任何原因。

環境

  1. 基本上,我在不同區域(如愛爾蘭、孟買等)運行各種 AWS EC2 執行個體。
  2. 我有一台Mac。
  3. 我位於印度(以防有人出於某種原因感到震驚)。

問題陳述1

當我的 Mac 透過 4G 網路連接到個人熱點(從三星裝置或 iPhone)時,如果我不進行 SSH 會話(基本上, SSH 連線非常理想)。所以我必須一直按箭頭鍵才能讓它保持活力。

問題陳述2(這不是問題)

但當我的Mac連接到Wifi寬頻連線時,這個問題就不會出現。即使我將 Mac 從睡眠狀態中喚醒(打開蓋子),我的 SSH 連線仍會保持連線數小時。

今天再次根據我的谷歌搜索,我發現了各種文章,這些文章提供了使用諸如TCPKeepAlive或 之類的選項的解決方案ServerAliveInterval

  1. sshd_config 中的 `ServerAliveInterval` 和 `ClientAliveInterval` 選項到底有什麼作用?
  2. tcp-keepalive 在 ssh 中如何運作?
  3. https://raspberrypi.stackexchange.com/questions/8311/ssh-connection-timeout-when-connecting
  4. https://patrickmn.com/aside/how-to-keep-alive-ssh-sessions/

但我找不到任何說明這個問題的帖子。你們有人對這種行為有任何想法嗎?我很樂意向您提供有關我的 4G 熱點連接的任何可能的詳細資訊。

答案1

我猜測是系統追蹤(並忘記)連接狀態導致了這種情況。當使用 NAT 時(不使用 IPv6 時經常出現這種情況),執行 NAT 的系統通常需要一個記憶體來記住要向何處發回回應。對於您的 Wifi 寬頻,執行 NAT 的系統可能有更長的記憶體來記住活動連線(例如,Linux網路過濾器連線預設情況下,它會記住 TCP 連線 5 天,而它會記住 UDP 流 2 或 3 分鐘)。在 4G 路徑上執行 NAT 的等效系統的記憶體可能較短,略小於 300 萬。

要解決此問題,正如您在問題中找到並連結的那樣,您可以設定特定的 ssh 參數ServerAliveInterval 當沒有活動時,會定期發送空資料(如 SSH 協定),類似於TCP 保活。這將使執行 NAT 的系統始終將連接視為活動的,並且不會忘記它。所以在你的~/.ssh/config文件中你可以加入:

ServerAliveInterval 115

115 的值選擇略小於 2mn 以保持保守:該值低於路徑中不可見 NAT 設備上活動連接的估計追蹤持續時間,但也不會太低(見下文)。因此,更糟的是,當追蹤狀態距離即將被刪除還有 5 秒時,它會回到假設的 120 秒壽命。

缺點是(無論如何在你的 Wifi 寬頻存取上)如果你失去連線一段時間然後恢復它,這可能會讓客戶端認為遠端伺服器已關閉並且它會關閉連線。您也可以調整ServerAliveCountMax為此,但無論如何,如果預設值為 3,則需要 3*115=345 秒的連線遺失,超過 500 萬,才有機會出現此問題。

伺服器端有一個等效的ClientAliveIntervalsshd_config您可以出於相同的目的在其文件中進行設定。這樣做的另一個好處是,當客戶端無論如何都失去連接時,不會在一段時間內保留 Ghost ssh 客戶端連接,這些連接被視為仍然連接。

相關內容