フランス拠点の障害対応で使うSSH踏み台、タイムアウトより先に疑うべき設定

パリ郊外の小規模拠点で、監視アラートから踏み台経由で対象ホストに入る運用をしていた。構成は ClientAliveInterval 60 / ClientAliveCountMax 3 のまま、踏み台は踏み台で別のセッションを張る二段構成。障害時、一次対応の担当が「接続が切れる」と言い、復旧に毎回10分以上かかっていた。切り分けのため、まず踏み台側の sshd_config とクライアント側の ~/.ssh/config を突き合わせた。

Host bastion-paris
  HostName 10.x.x.10
  ServerAliveInterval 30
  ServerAliveCountMax 2
  TCPKeepAlive no

Host target-*
  ProxyJump bastion-paris
  ServerAliveInterval 30
  ServerAliveCountMax 2

ポイントは TCPKeepAlive no にしたこと。NAT やクラウドの LB がアイドル接続を落とす環境では、TCP の keepalive はアプリ層の生存確認より遅い。ServerAliveInterval でアプリ層から定期的にパケットを出す方が、切断の検知も早いし、切断そのものを起こしにくい。代わりに、回線が不安定な現場では無駄な再送が増える。踏み台のログを見ると、そもそも 60 秒の間隔で切れていたわけではなく、LB 側の 45 秒のアイドルタイムアウトに引っかかっていた。

ただ、この設定は ProxyJump を使わずに多段 SSH を手で張る運用だと効かない。各段で別々に config を読むので、踏み台側の設定が抜ける。あと、ServerAliveInterval を短くしすぎると、障害で対象ホストが高負荷のときにセッションが切れやすくなる。実際、私の環境では 15 秒まで縮めたら復旧作業中に切られた。30 秒前後が落としどころだった。

同じ構成で、踏み台の先だけ Timeout が効かずに詰まるケースに遭遇した人はいますか。ProxyJump と ProxyCommand のどちらで運用しているかも聞いてみたい。