4
OpenVPNネットワークでTCP接続がフリーズするのを防ぐにはどうすればよいですか？
この質問の最後に追加された新しい詳細。私が原因を突き止めている可能性があります。 UDP OpenVPNベースのVPNをtapモードで設定しています（tapマルチキャストパケットを通過させるためにVPNが必要なため、tunネットワークでは不可能と思われるため）、インターネット上の少数のクライアントを使用しています。VPNで頻繁にTCP接続がフリーズすることがあります。つまり、TCP接続（たとえば、SSH接続ですが、他のプロトコルには同様の問題があります）を確立し、セッション中のある時点で、そのTCPセッションを介したトラフィックの送信が停止するようです。 これはls、SSHセッションでコマンドを実行する場合やcat、長いログファイルを使用する場合など、大量のデータ転送が発生するポイントに関連しているようです。一部のGoogle検索では、Server Faultで次のような多数の回答が表示されます。原因はMTUの問題である可能性が高いことを示しています。トラフィックが多い期間中、VPNは、 VPNエンドポイント。上記のリンクの回答は、次のOpenVPN構成設定を使用して問題を軽減することを提案しています。 fragment 1400 mssfix これにより、VPNで使用されるMTUが1400バイトに制限され、TCPの最大セグメントサイズが修正され、それより大きいパケットが生成されなくなります。これは問題を少し緩和するようですが、それでもフリーズが頻繁に発生します。fragmentディレクティブの引数として、1200、1000、576のサイズをいくつか試しましたが、すべて同様の結果が得られました。このような問題を引き起こす可能性のある、両端間の奇妙なネットワークトポロジは考えられません。VPNサーバーは、インターネットに直接接続されているpfSenseマシンで実行されており、クライアントも別の場所でインターネットに直接接続されています。 パズルのもう1つの奇妙なピース：tracepathユーティリティを実行すると、問題を解決できるようです。サンプルの実行は次のようになります。 [~]$ tracepath -n 192.168.100.91 1: 192.168.100.90 0.039ms pmtu 1500 1: 192.168.100.91 40.823ms reached 1: 192.168.100.91 19.846ms reached Resume: pmtu 1500 hops 1 back 64 上記の実行は、VPN上の2つのクライアント間で行われます：192.168.100.90からの宛先へのトレースを開始しました192.168.100.91。fragment 1200; mssfix;リンクで使用されるMTUを制限しようとして、両方のクライアントが構成されました。上記の結果はtracepath、2つのクライアント間で1500バイトのパスMTUを検出できたことを示唆しているようです。OpenVPN構成で指定されたフラグメンテーション設定のために、それはいくらか小さくなると思います。その結果はやや奇妙だと思いました。 さらに奇妙なことですが、ストール状態のTCP接続（たとえば、途中でフリーズするディレクトリリストを含むSSHセッション）がある場合、上記のtracepathコマンドを実行すると、接続が再び開始されます。なぜそうなるのかについての合理的な説明はわかりませんが、これは最終的に問題を根絶するための解決策を指しているのではないかと感じています。 誰か他のことを試してみるための推奨事項はありますか？ 編集：私は戻ってきて、これをもう少し見てみましたが、もっと混乱する情報しか見つかりませんでした： 上記のように、OpenVPN接続を1400バイトでフラグメント化するように設定しました。次に、インターネット経由でVPNに接続し、Wiresharkを使用して、ストールの発生中にVPNサーバーに送信されたUDPパケットを調べました。指定された1400バイトカウントを超えるものはなかったため、断片化は適切に機能しているようです。 1400バイトのMTUでも十分であることを確認するために、次の（Linux）コマンドを使用してVPNサーバーにpingを実行しました。 ping <host> -s 1450 -M do これは（断片化を無効にした）1450バイトのパケットを送信します（少なくとも1600バイトのような明らかに大きすぎる値に設定すると動作しないことを確認しました）。これらはうまく機能するようです。私は問題なくホストから返信を受け取ります。 …