送信パケットのドロップ/タイムアウト-Azureのみ
米国フロリダ州のサードパーティのデータセンターにパケットがドロップする問題があります。この問題は、VMがどのデータセンターにあるかに関係なく、Azure Virtual Machinesでのみ発生します。Azure以外のネットワークから同じテストを同時に実行しましたが、パケット損失はありません。 Azure Virtual Machinesは、「バニラ」であり、ソフトウェアをロードしたり、その他のカスタマイズや変更を加えたりしていない状態でした。
私はすでにデータセンターのネットワーク管理者に話しましたが、彼らが見ている唯一のパケットはタイムアウトしないものです。タイムアウトしたパケットはファイアウォールに到達しないため、Azure側で何かのように聞こえます（特に、複数のAzureデータセンター/リージョンからパケットが一貫してドロップ/タイムアウトするため）。誰かがこれをどのように解決するか知っていますか？
私が実行していたテストは、ポート80への連続的なTCP ping（ tcping.exe を使用）です（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を実行してパケットをドロップしないことです。トンネルVPNもセットアップしています。 AzureからVM to a VM at azure以外のデータセンターで、パケットはドロップされません。パケットがドロップされるのは、トラフィックが出たときだけです。 Azureを介してインターネット/ WANに直接。
次のステップはいくつかのトレースルートテストになることはわかっていますが、AzureがICMPをブロックするため、 nmapを使用してTCP trace route を実行する必要がありました。以下に貼り付けます。これらのテストのスクリーンショット。
nmap -sS -p 80 -Pn --traceroute 216.155.111.149
私のコメントで述べたように、あなたは この記事 で説明されているのと同じようなシナリオに効果的に達しています。
私はあなたの行動を簡単に再現できました：
そして、VMに インスタンスレベルのパブリックIP を追加することで、問題を簡単に回避できます。
同時キャプチャがないため、正確に何が起こっているかを言うのは困難ですが、私の理解では、リモートサイト（www.oandp.com）のエッジデバイス（ファイアウォールである可能性があります）は、その接続で閉じた接続を維持します。テーブルはAzureよりも長いため、Azureが解放された（つまり、既に使用されている）ポートの1つを使用していても、リモート側で接続が完全に閉じていないと見なされた場合、SYNパケットはドロップされます。
ILPIPは静的なNATまたは「1対1のNAT」を適用するため、（OSがそれを行わない限り）ポート変換もポート再利用も行わないため、問題は回避されます。