Azure VMアウトバウンドTCP接続が数分後に中断する

Question

Azureクラウド内でWindows Server 2012 R2を実行している仮想マシンがあります。このマシンは、プライベートIPアドレスとパブリックIPアドレスが静的に割り当てられています。そのマシンでは、クライアントアプリケーション（具体的にはJenkins Agent）を実行しています。このクライアントは、サーバ（Jenkins Master）へのTCP接続を開きます。これはAzureクラウドの外で実行されています（一部のパブリックIPアドレスの背後にあります）。 TCP接続は正常に確立されています。

この接続を有効にするために、クライアントとサーバーの両方が4〜5分おきに「ping」しています。この「ping」は、開かれたTCP接続を介して複数のTCPパッケージを交換することによって行われます。

ランダムな時間間隔が経過すると、クライアントはサーバーにアクセスできなくなり、サーバーはクライアントにアクセスできなくなります。したがって、クライアントとサーバーの両方のエンドで接続タイムアウト例外がスローされます。

この問題を分析するために、Azureクラウド（クライアントアプリケーションが実行されている場所）のWindowsサーバーでを実行しているWiresharkとこの通信を追跡していました。コミュニケーションがうまく動作しますが、Wiresharkのは、TCPトラフィックが間で交換されて示しています - クライアントのプライベート IPアドレス/ ローカルポート - サーバーのパブリックIPアドレス/ポート

Azureのマシン（クライアント）があるので、これは完全に論理的なようですパブリックIPアドレスと公開されているポート（NATが適用された後）を認識しません。

問題が発生すると、クライアントとサーバの両方がTCP再送信パケットを送信していることがわかります。これは、どちらも以前に送信されたTCP：PSHパケットのTCP：ACKパケットを受信して​​いないことを意味します。クライアントマシンがサーバからこれらのTCP再送信を受信して​​いたのですが、問題はクライアントのプライベートIP /ローカルポストに送信されないということです。これらのパッケージは、クライアントの公開IPで公開されているのに送信されるとWiresharkに表示されます。明らかに、クライアントのアプリケーションは、マシンのNIC /ドライバがそれらを破棄するため、これらのパッケージを受信しません（これも期待されます）。

質問：Azureマシンの（クライアントの）パブリックIPアドレスに送信されたTCP応答が、NAT変換がそのコンテンツに適用されていないと、公開されているポートがマシン自体に到達することはありませんか？

Answer 1

ステータスを追跡してから3日後には、問題の再発は認識されませんでした。だから私は結論としてこの問題を解決しています：より頻繁なクライアント/サーバのping（つまり、接続を維持する）は、このAzureの問題の周りで確実に機能します。