同僚と一緒に、Azure のプライベート ネットワーク内のロード バランサーへの UDP 転送構成を設定しています。試みた設定は次のようになります。
- 実際のターゲットUDPサーバーは
172.16.2.2:5075 - UDPロードバランサは
172.16.1.1:5050
そこで、このようなマッピングを使用して、ロード バランサーからの単純な転送ルールを作成しました。
しかし、ターゲットサーバーはトラフィックを記録していませんでした。そこで、問題のトラブルシューティングを試みました。同じネットワークで実行されているUbuntu VMを使用して、ロードバランサーがUDPトラフィックに応答することを確認しました。
nc -zvu 172.16.1.1 5050
成功したと報告されました。しかし、172.16.2.2何も受け取っていないようです。
そこで、ターゲット マシンを直接 ( を使用nc -zvu 172.16.2.2 5075) テストしたところ、着信がログに記録されました。
eg では UDP 転送/リダイレクトなどに従うオプションが見つかりませんでしたnc。そこで、トラフィックがドロップされた場所を確認するために、eg も実行してみましたtracepath -4 -p 5050 172.16.1.1が、「応答なし」の行のリストしか表示されませんでした。
私の同僚は実際にこの特定の問題を解決しました (転送ルールを Azure の負荷分散ルールから受信 NAT ルールに変更することによって)。そのため、これ以上の支援は必要ありません。
しかし、学習目的と将来の問題解決のために、このような問題のトラブルシューティング方法をぜひ教えてください。このようなロード バランサーの転送ルールで何がどこで失敗するかを確認するためのコマンド (Ubuntu ディストリビューションなどにデフォルトで用意されているものが望ましい) またはコマンドの組み合わせはありますか?
今回の問題がAzure特有のものであったとしても、私はもっとクラウドに依存しない方法で、少なくともUDPトラフィック転送チェーンがどこまで機能するかを確認できる最終目的地に到達できない理由について、より詳しい情報を提供できればできるほど良いでしょう。
編集：
タイトルとテキストを少し変更して、私が探しているのは、たとえば独自のソフトウェアではなく、使用する (組み込み) コマンドであることを明確にしました。