私は Ubuntu 18.04.3 LTS サーバーで Netcat を実行して、ポート 469 をリッスンしています。このサーバーは、他のマシンからポート 469 への TCP 要求を頻繁に受信します。これを使用して、サーバーの稼働時間を監視します。Netcat を次のように起動します。
nc -kl 469
そして、プロセスが稼働中であることがわかります:
$ ps -aux | grep 469次のような出力が生成されます:
ルート 11041 0.0 0.1 13596 1060 ? S 8月31日 0:21 nc -kl 469`
このシステムは約 24 ～ 28 時間正常に動作しますが、その後 Netcat は応答を停止します。調査した結果、問題は Recv-Q バッファが「いっぱいになる」ことだと考えています。通常、Recv-Q バッファは Netcat が応答を停止するまで 0 です。応答が停止した後は、Recv-Q バッファは定数 2 (通常の 0 ではなく) になります。次のように「ss」を使用してこれを確認できます。
$ ss -tnlそして、異常な Recv-Q 2 が表示されていることがわかります。
$ ss -tnl
状態 Recv-Q Send-Q ローカルアドレス:ポート ピアアドレス:ポート
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 64 0.0.0.0:42587 0.0.0.0:*
LISTEN 0 128 0.0.0.0:46663 0.0.0.0:*
LISTEN 0 128 0.0.0.0:111 0.0.0.0:*
聞く 2 1 0.0.0.0:469 0.0.0.0:*
LISTEN 0 128 127.0.0.53%lo:53 0.0.0.0:*
LISTEN 0 128 [::]:22 [::]:*
LISTEN 0 64 [::]:44057 [::]:*
LISTEN 0 128 [::]:55085 [::]:*
LISTEN 0 128 [::]:111 [::]:*
他にも、まったく同じ方法でポート 469 でリッスンしている Netcat を実行している Ubuntu サーバーがいくつかあります。これらのサーバーは失敗しません。数週間稼働しています。しかし、このサーバーは再起動後も何度も失敗し、常に約 24 時間以上後に失敗します。このサーバーと他のサーバーとの唯一の違い (私が考えられる限り) は、このサーバーにも nfs ボリュームがマウントされていることです (上記のポート 111 でリッスンしていることからわかるように)。
これは何が原因でしょうか? 何らかの方法で (bash から) Recv-Q をクリアして、一定の間隔で (一時的な修正として) クリアすることはできますか? どのような助言でも大歓迎です。
答え1
私はこの質問に対する答えを見つけたので、他の人の役に立つかもしれないと思い、ここに投稿しました。
問題は、サーバーに Strongswan もインストールされており、ポート 469 への着信 TCP 要求が別のサーバーからの IPSec 接続を介して送信されていたことです。IPSec 接続が再キー化されている間 (約 24 時間ごと)、IPSEC 接続がごく短時間中断されることがありました。ポート 469 への TCP Syn/Ack が進行中の途中でこれが発生すると、中断状態になります。そのため、「nc -kl」は Recv-Q バッファー内のパケットで停止します。
解決策は、再キー化が中断されることなく行われるように Strongswan を構成することでした。学んだことは、Recv-Q バッファまたは Netcat の問題を探すのではなく、根本的な原因を理解する必要があるということでした。この場合、それは TCP Syn/Ack が完了できなかった理由を理解することでした。