Azure

Application Gatewayのバックエンドはデュアルスタック（IPv4、IPv6）にしてはいけない。

はじめに

前回はApplication GatewayでAWS側をバックエンドにした場合に問題が発生したことを紹介しました。

Application Gatewayの正常性とIPv6でハマりました - 技術的な何か。
Application Gatewayの正常性とIPv6でハマりました - 技術的な何か。

はじめに Application GatewayのバックエンドをAWS ELBに指定したときに起きた問題です。 正常性プローブでは正常と判断されるが、バックエンド正常性では異常と判断れる現象が発生しま

level69.net

今回はさらに詳細を確認するため下記のようなデュアルスタック（IPv4とIPv6で待ち受ける）構成で検証した結果です。

AWS EC2をデュアルスタックの環境で構築し、テスト用のドメイン1つに対しＡレコードとAAAAレコードを設定しています。

;; ANSWER SECTION:
ip.server01.pw.         300     IN      A       3.114.160.165
ip.server01.pw.         300     IN      AAAA    2406:da14:6c6:c801:1895:6a51:c267:da71

問題

Application Gatewayでは下記の用な問題が発生します。

  • 正常性プローブでは正常を示す

  • バックエンドの正常性では異常を示す

The backend health status could not be retrieved. This happens when an NSG/UDR/Firewall on the application gateway subnet is blocking traffic on ports 65503-65534 in case of v1 SKU, and ports 65200-65535 in case of the v2 SKU or if the FQDN configured in the backend pool could not be resolved to an IP address. To learn more visit - https://aka.ms/UnknownBackendHealth.

このように正常性に対して矛盾が発生します。

構築、変更する場合の流れとしては正常性プローブのテストを行い、プローブを切り替えるという段取りを行うと思います。

その場合、切り替えてから初めてバックエンドが正常ではないということを認識するという問題が発生します。

想像するに、内部の仕様なのは明らかです。正常性プローブがテストのために正引きする場合にIPv4が優先され、バックエンドの正常性ではIPv6が優先されるためだと考えられます。

Application GatewayはIPv4に対応していないのに不思議な感じがします。

まとめ

Application Gatewayのバックエンドはデュアルスタックにしてはいけないという話でした。検証環境では再現しましたが、デュアルスタック環境でも起きない場合もあります。そのため現状はデュアルスタックにしないのが得策と考えています。参考になればよいと思います。

-Azure
-,