送信パケットのドロップ/タイムアウト - Azure のみ

送信パケットのドロップ/タイムアウト - Azure のみ

米国フロリダ州のサードパーティ データ センターへのパケットがドロップされる問題が発生しています。この問題は、VM がどのデータ センターにあるかに関係なく、Azure Virtual Machines でのみ発生します。他の非 Azure ネットワークから同時に同じテストを実行しましたが、パケットの損失はありません。Azure Virtual Machines は、ソフトウェアがロードされておらず、その他のカスタマイズや変更も行われていない「標準」/箱から出した状態です。

すでにデータ センターのネットワーク管理者と話をしましたが、彼らが見ているのはタイムアウトしないパケットだけです。タイムアウトするパケットはファイアウォールに到達しないので、Azure 側に問題があるように思えます (特に、複数の Azure データ センター / リージョンからのパケットが一貫してドロップ/タイムアウトするため)。これを解決する方法を誰か知っていますか?

私が実行していたテストは、連続TCP ping(tcping.exe は、) をポート 80 に接続します (Azure では ICMP がブロックされているため)。

tcping -t 216.155.111.149 80
tcping -t 216.155.111.151 80
tcping -t 216.155.111.146 80

サードパーティのデータ センターではないことを裏付ける他の証拠として、自宅のコンピューターや職場のコンピューターから同じ TCP ping を継続的に実行してもパケットがドロップされないことが挙げられます。また、Azure VM から Azure 以外のデータ センターの VM へのトンネル VPN もセットアップしましたが、パケットはドロップされませんでした。パケットがドロップされるのは、トラフィックが Azure 経由で直接インターネット/WAN に送信されるときだけです。

次のステップはトレースルートテストだとわかっていますが、AzureがICMPをブロックしているので、TCP トレースルートを実行するための nmap; 以下に、それらのテストのスクリーンショットを貼り付けます。

nmap -sS -p 80 -Pn --traceroute 216.155.111.149

テスト1

テスト2

テスト3

テスト4

答え1

私のコメントで述べたように、あなたは事実上、この記事

あなたの行動は簡単に再現できました:

問題を再現

そして、私は簡単にこの問題を回避することができました。インスタンスレベルのパブリック IPVMに:

問題は解決しました

同時キャプチャがないため、正確に何が起こっているのかを言うのは難しいですが、私の理解では、リモート サイト (www.oandp.com) のエッジ デバイス (ファイアウォールの可能性があります) は、閉じた接続を Azure よりも長く接続テーブルに保持するため、Azure が解放された (つまり、すでに使用されている) ポートの 1 つを使用し、リモート側が接続が完全に閉じられていないと判断すると、SYN パケットがドロップされます。

ILPIP は静的 NAT または「1 対 1 NAT」を適用するため、ポート変換やポート再利用は行われず (OS が実行しない限り)、問題を回避できます。

関連情報