現在、IPv4とIPv6をサポートするLinuxベースのバックエンドと連携するようにAzure Load Balancerを構成しています。設定の一環として、ロードバランサーはTCP接続の確立を試み、定期的なヘルスチェックを実行します。ただし、IPv6 パケット転送の問題によりバックエンドのヘルスチェックが失敗し続けました。
コンテキスト
- ロードバランサは NAT64 をサポートせず、両端で IPv6 のサポートが必要です。
- バックエンドはIPv6で構成されており、Webサービスは必要なポートで積極的にリッスンしています。
- あるバックエンドから別のバックエンドにサービスを照会し、構成が正しいことを確認して接続を確認します。
質問:
この問題は、Azure Load Balancerがリンクローカルアドレスからリンクされていないローカルアドレスに送信されたIPv6パケットを使用してヘルスチェックを開始して失敗する場合に発生します。
必要:
バックエンドがリンクローカルアドレスから通常のIPv6アドレスに送信されたIPv6パケットに応答できるようにする方法についてのガイドラインを探しています。 Azure Load Balancer 環境でこの状況に対応するために、構成または設定を調整する必要がありますか?
追加の詳細:
バックエンド VM の 1 つに対する以下のネットワーク キャプチャは、状況をよく説明します。 Azure Load Balancerはリンクローカルアドレスでステータスプローブを実行しますfe80::1234:5678:9abc
。パケットは、仮想マシンインターフェイスに割り当てられた通常のIPv6アドレスに送信されます。ただし、バックエンドはパケットを拒否し、直ちに ICMPv6 を介してリンクローカルアドレスが送信元アドレス範囲外であることを通知するエラーで応答します。 Azure Load Balancer の動作を変更できないため、このパケットが応答できるようにバックエンドに回避策を適用できるかどうか疑問に思います。
源泉 | 目的地 | 規約 | 長さ | 情報 |
---|---|---|---|---|
fe80::1234:5678:9abc | 2404:f800:8000:122::4 | 伝送制御プロトコル | 86 | 58675 → 80 [SYN] Seq=0 Win=64800 Len=0 MSS=1440 WS=256 SACK_PERM |
2404:f800:8000:122::4 | fe80::1234:5678:9abc | ICMPv6 | 134 | 宛先に接続できません(ソースアドレスの範囲外)。 |
答え1
レイヤ3ではローカルリンクをルーティングできません。ロードバランサーがそのローカルリンクからのみパケットを送信できると仮定すると、宛先が同じレイヤ2ネットワークにある場合にのみ機能します。
両端にグローバルユニキャストIPv6が必要です。これは、Azureロードバランサーの構成が間違っているようです。