MENU

Azure StandardV2 NAT GatewayのNAT64条件｜DNS64でIPv6からIPv4へ接続する方法

Azure

Azure StandardV2 NAT GatewayのNAT64でIPv6からIPv4へ接続するには、NAT64を有効にするだけでは不十分です。最も重要なのは、IPv4アドレスを64:ff9b::/96へ埋め込んだAAAAレコードを生成する、DNS64対応リゾルバーを用意することです。

さらに、StandardV2 NAT Gatewayには、変換後のIPv4通信で使用するStandardV2 IPv4パブリックIPアドレスが必要です。対象サブネットへの関連付け、IPv6通信経路、NSGやルートの確認も欠かせません。

StandardV2 NAT GatewayのNAT64は2026年7月に一般提供されました。IPv6ワークロードからIPv4専用インターネットサービスへ接続できますが、DNS64、NAT64、アプリケーションの名前解決が正しく連携して初めて機能します。

目次

Azure StandardV2 NAT GatewayでNAT64接続が成立する条件

NAT64によるIPv6からIPv4への接続には、次の条件をすべて満たす必要があります。

条件必要な設定満たさない場合
NAT GatewayのSKUStandardV2Standard SKUではNAT64を利用できない
NAT64設定NAT64をEnabledにする64:ff9b::/96宛ての通信がIPv4へ変換されない
送信元ネットワークワークロードからIPv6通信が可能合成されたAAAAアドレスへ接続できない
サブネットStandardV2 NAT Gatewayを対象サブネットに関連付けるワークロードの通信がNAT Gatewayを通らない
IPv4パブリックIPStandardV2 IPv4パブリックIPを1個以上関連付ける変換後のIPv4送信元アドレスを確保できない
DNSリゾルバーDNS64対応リゾルバーを用意するIPv4専用ホストのAAAAレコードを取得できない
DNS64プレフィックス64:ff9b::/96を使用するAzure NAT GatewayがNAT64対象通信として認識できない
接続先IPv4専用のインターネット宛先IPv6対応先は通常のIPv6通信になる
通信制御NSG、DNS、ルートで必要な通信を許可する名前解決またはデータ通信が途中で遮断される

Microsoftのドキュメントでは、NAT64はStandardV2専用機能であり、少なくとも1つのStandardV2 IPv4パブリックIPアドレスと、サードパーティ製のDNS64ソリューションが必要とされています。(Microsoft Learn)

NAT64とDNS64の役割は異なる

NAT64とDNS64は、似た名称ですが役割が異なります。

機能役割処理するもの
DNS64IPv4アドレスを埋め込んだAAAAレコードを生成するDNS応答
NAT64IPv6パケットをIPv4パケットへ変換する実際の通信パケット

DNS64は接続先のIPv6アドレスを作り、NAT64はそのアドレス宛てに送られたパケットをIPv4へ変換します。

NAT Gatewayには、ホスト名からIPv4アドレスを検索する機能はありません。DNS64を用意せずにNAT64だけを有効化しても、IPv6クライアントはIPv4専用ホストの接続先IPv6アドレスを取得できません。(Microsoft Learn)

DNS64によるアドレス合成の例

IPv4専用サーバーのAレコードが、次のアドレスだったとします。

203.0.113.10

DNS64は、このIPv4アドレスを64:ff9b::/96の後半32ビットへ埋め込みます。

64:ff9b::cb00:710a

IPv4を埋め込んだ形式では、次のようにも表せます。

64:ff9b::203.0.113.10

64:ff9b::/96は、IPv4とIPv6の変換用としてRFC 6052で定義されたWell-Known Prefixです。プレフィックス長が96ビットであるため、残りの32ビットにIPv4アドレスがそのまま格納されます。(RFCエディタ)

IPv6からIPv4専用インターネットへ接続する流れ

Azure StandardV2 NAT GatewayのNAT64通信は、次の順序で処理されます。

DNS64がAAAAレコードを合成する

IPv6ワークロードがIPv4専用ホストのAAAAレコードを問い合わせます。

app.example

DNS64リゾルバーは、最初に通常のAAAAレコードを確認します。接続先にAAAAレコードがなく、Aレコードだけが存在する場合、そのIPv4アドレスを使って合成AAAAレコードを生成します。

app.example.  AAAA  64:ff9b::cb00:710a

ワークロードがIPv6パケットを送信する

クライアントは、返された合成AAAAレコードを通常のIPv6アドレスとして扱います。

送信元IPv6アドレス
        ↓
64:ff9b::cb00:710a

この時点では、クライアントはIPv4パケットを送っていません。送信されるのは、宛先が64:ff9b::/96に含まれるIPv6パケットです。

NAT Gatewayが埋め込まれたIPv4アドレスを取り出す

StandardV2 NAT Gatewayは、宛先が64:ff9b::/96であることを認識します。

続いて、IPv6アドレスの最後の32ビットからIPv4アドレスを取り出します。

64:ff9b::cb00:710a
             ↓
       203.0.113.10

IPv4パケットへ変換して送信する

NAT GatewayはIPv6パケットをIPv4へ変換し、関連付けられたStandardV2 IPv4パブリックIPアドレスを送信元としてSNATします。

IPv6ワークロード
   ↓ IPv6
StandardV2 NAT Gateway
   ↓ NAT64・SNAT
IPv4専用インターネットサーバー

応答をIPv6へ戻す

IPv4サーバーから返された応答は、StandardV2 NAT Gatewayによって再びIPv6へ変換され、元のワークロードに返されます。

この変換は送信元から開始した接続に対して行われます。NAT Gatewayは、インターネット側から開始される任意の受信接続を公開するサービスではありません。(Microsoft Learn)

Azure NAT GatewayのNAT64を構成する方法

StandardV2のIPv4パブリックIPを作成する

最初に、NAT64変換後のIPv4送信元として使用するパブリックIPアドレスを作成します。

Azureポータルで「パブリックIPアドレス」を開き、次のように設定します。

項目設定例
IPバージョンIPv4
SKUStandard V2
層Regional
割り当て静的
リージョンNAT Gatewayと同じリージョン

StandardのパブリックIPではなく、StandardV2のパブリックIPを選択する点に注意してください。

StandardV2 NAT GatewayはStandardV2パブリックIPまたは対応するプレフィックスを前提としており、従来のStandardパブリックIPとは互換性がありません。(Microsoft Learn)

StandardV2 NAT Gatewayを作成する

Azureポータルで「NATゲートウェイ」を開き、「作成」を選択します。

主な設定は次のとおりです。

項目設定
SKUStandard V2
リージョンパブリックIP、VNetと同じリージョン
送信IP作成したStandardV2 IPv4パブリックIP
TCPアイドルタイムアウト特別な要件がなければ既定値
サブネットNAT64を利用するワークロードのサブネット

NAT Gatewayは、パブリックIPとサブネットの両方が関連付けられて初めて送信通信に使用できます。複数のサブネットを同じNAT Gatewayへ関連付けることはできますが、1つのサブネットへ複数のNAT Gatewayを関連付けることはできません。(Microsoft Learn)

NAT64を有効にする

StandardV2 NAT Gatewayを作成したら、Azureポータルで対象リソースを開きます。

  1. StandardV2 NAT Gatewayを開く
  2. 「構成」を開く
  3. NAT64をEnabledに変更する
  4. 保存する

ARMまたはREST APIで自動化する場合は、NAT Gatewayリソースのnat64プロパティをEnabledに設定します。

nat64: Enabled

Microsoft.Network/natGatewaysでは、APIバージョン2025-07-01からnat64プロパティが定義されています。既存のARMテンプレートやBicepへ追加する場合は、ほかのパブリックIPやサブネット設定を失わないよう、リソース全体の定義を確認してから変更してください。(Microsoft Learn)

DNS64対応リゾルバーを用意する

Azure StandardV2 NAT Gatewayには、DNS64機能が内蔵されていません。Microsoftは、NAT64を使用するためにサードパーティのDNS64ソリューションを配置するよう案内しています。(Microsoft Learn)

DNS64リゾルバーでは、少なくとも次の設定が必要です。

  • IPv4専用ホストに対してAレコードを取得できる
  • AAAAレコードが存在しない場合に合成AAAAレコードを返す
  • 合成プレフィックスとして64:ff9b::/96を使用する
  • 対象ワークロードから到達できる
  • 必要な内部DNSゾーンや条件付きフォワーダーを処理できる
  • 障害を考慮して複数台または冗長構成にする

DNS64側で別のプレフィックスを設定してはいけません。例えば、DNS64が2001:db8:64::/96を使ってAAAAレコードを作っても、Azure StandardV2 NAT Gatewayが認識するNAT64プレフィックスは64:ff9b::/96です。

DNS64とNAT64でプレフィックスが一致していなければ、クライアントはIPv6パケットを送信できても、期待するIPv4変換は行われません。(Microsoft Learn)

ワークロードの参照先DNSを変更する

DNS64リゾルバーを配置しただけでは、ワークロードは使用しません。

次のいずれかの方法で、対象ワークロードがDNS64リゾルバーを参照するように設定します。

  • Azure Virtual NetworkのDNSサーバー設定に登録する
  • NICやOSのDNS設定へ登録する
  • DHCPや構成管理ツールを利用して配布する
  • 既存の社内DNSからDNS64リゾルバーへ転送する

設定変更後は、VMやコンテナ、アプリケーションが古いDNS情報をキャッシュしている可能性があります。必要に応じてDNSキャッシュを消去し、新しい接続で検証してください。

DNS64が正しく動作しているか確認する方法

ipv4only.arpaで合成結果を確認する

DNS64の確認には、ipv4only.arpaを利用できます。これはNAT64プレフィックスの検出用として定義されたIPv4専用ドメインです。(RFCエディタ)

Linuxでは、次のように確認します。

dig AAAA ipv4only.arpa @<DNS64リゾルバーのIPアドレス>

Windows PowerShellでは、次のように確認できます。

Resolve-DnsName `
  -Name ipv4only.arpa `
  -Type AAAA `
  -Server <DNS64リゾルバーのIPアドレス>

正常にDNS64合成されていれば、回答されたAAAAレコードが次の範囲に含まれます。

64:ff9b::/96

AAAAレコードが返されない場合は、次の項目を確認します。

  • 問い合わせ先が本当にDNS64リゾルバーになっているか
  • DNS64機能が有効になっているか
  • Aレコードの再帰問い合わせが成功しているか
  • ファイアウォールやNSGでDNS通信が遮断されていないか
  • 合成対象から除外するポリシーが設定されていないか

実際のIPv4専用ホストを確認する

接続予定のホストについて、AレコードとAAAAレコードを個別に確認します。

dig A app.example @<DNS64リゾルバーのIPアドレス>
dig AAAA app.example @<DNS64リゾルバーのIPアドレス>

DNS64の動作確認では、次の結果になることを確認します。

Aレコード    ：実際のIPv4アドレス
AAAAレコード：64:ff9b::/96から始まる合成アドレス

接続先がもともとAAAAレコードを持っている場合、通常はその実在するAAAAレコードが返されます。この場合、通信はNAT64ではなく、ネイティブIPv6経路を使用します。(IETF Datatracker)

IPv6通信を強制して接続を確認する

LinuxやWindowsのcurlでは、-6を指定してIPv6接続を強制できます。

curl -6 -v https://app.example/

Windowsでは、必要に応じて実行ファイル名を明示します。

curl.exe -6 -v https://app.example/

検証には、自組織で管理しているIPv4専用テストサーバーを使用するのが確実です。

サーバー側のアクセスログやファイアウォールログでは、接続元としてStandardV2 NAT Gatewayに設定したIPv4パブリックIPアドレスが記録されます。

よくある接続失敗と確認ポイント

症状主な原因確認方法
Aレコードは取得できるがAAAAが返らないDNS64が無効、または通常のDNSを参照しているipv4only.arpaのAAAAを問い合わせる
AAAAは返るが接続できないDNS64プレフィックスが64:ff9b::/96ではない合成AAAAの先頭96ビットを確認する
NAT64を有効化しても変化がない対象サブネットにNAT Gatewayが関連付けられていないサブネット設定を確認する
IPv4送信元を確保できないStandardV2 IPv4パブリックIPがないNAT Gatewayの送信IP設定を確認する
リソース作成時に互換性エラーになるStandardパブリックIPを使用しているパブリックIPのSKUを確認する
IPv6接続だけ失敗するNSG、OSファイアウォール、ルートでIPv6が遮断されている有効なルートとセキュリティ規則を確認する
想定外の送信元IPになる既存接続が以前の送信経路を再利用している新しいTCP接続で再試験する
一部のドメインだけ合成されない実在するAAAAレコード、DNSSEC、DNS64除外設定権威DNSのA・AAAA・DNSSEC状態を確認する
ホスト名では接続できるがIPv4アドレス直指定では失敗するIPv4リテラルではDNS64が動作しないFQDNを使用するかアプリ設計を見直す
ping以外のICMP処理が期待どおりでないStandardV2が対応するのはICMP Echo Request／ReplyTCP・UDPでも接続確認する

DNS不良、NSGによる遮断、NVAやVPN、ExpressRouteへの強制転送は、NAT Gatewayの代表的な接続失敗原因です。既存のLoad Balancer、Azure Firewall、VMレベルのパブリックIPからStandardV2 NAT Gatewayへ切り替える場合は、既存接続が中断される可能性もあります。(Microsoft Learn)

IPv4アドレスの直指定ではDNS64が動作しない

DNS64が処理するのはDNS問い合わせです。

アプリケーションが次のようにIPv4アドレスを直接指定している場合、DNS問い合わせ自体が発生しません。

https://203.0.113.10/

そのため、DNS64は64:ff9b::/96を使ったAAAAアドレスを合成できません。

次のようなアプリケーションは、事前検証が必要です。

  • 設定ファイルにIPv4アドレスを直接記述している
  • APIレスポンス内でIPv4アドレスを受け取る
  • FTPやSIPなど、アプリケーションデータ内でIPアドレスを通知する
  • 接続先を独自方式で名前解決する
  • OS標準のDNSリゾルバーを使用しない

Azure NAT GatewayはIPヘッダーとTCP・UDPなどのトランスポート情報を扱いますが、アプリケーションのペイロードを書き換える機能ではありません。IPv4アドレスが通信内容に埋め込まれるプロトコルでは、NAT64だけで互換性を確保できない場合があります。(Microsoft Learn)

プライベートIPv4宛て通信にはそのまま使えない

Azure StandardV2 NAT GatewayのNAT64が想定するのは、IPv4専用のインターネット宛先です。

64:ff9b::/96は、グローバルIPv4アドレスをIPv6で表現するためのWell-Known Prefixです。RFC 6052では、次のような非グローバルIPv4アドレスをこのプレフィックスへ埋め込んで使用しないよう定めています。

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

そのため、IPv6ワークロードからオンプレミスや別VNetのプライベートIPv4サーバーへ接続する用途を、StandardV2 NAT GatewayのNAT64だけで実現する設計にはしないでください。

プライベートIPv4宛てでは、VNetピアリング、VPN、ExpressRoute、NVA、アプリケーションプロキシなど、要件に合ったプライベート接続方式を別途検討します。(RFCエディタ)

IPv6専用という表現に注意する

MicrosoftはNAT64の用途を「IPv6-only workloadsからIPv4-only destinationsへの通信」と説明していますが、NAT64を有効にしただけで、すべてのAzureリソースをIPv6専用構成にできるわけではありません。

例えば、Azure VMとVirtual Machine Scale Setsについては、現在のMicrosoft LearnでIPv6専用NIC構成はサポートされず、少なくとも1つのIPv4 IP構成が必要とされています。(Microsoft Learn)

したがって、実務では次の2点を分けて考える必要があります。

  • アプリケーションがIPv6通信を使ってIPv4専用サービスへ接続できるか
  • Azureリソース自体をIPv4構成なしでデプロイできるか

NAT64は前者を実現する機能です。後者はVM、AKS、コンテナ、PaaSなど、使用するAzureサービスごとのIPv6対応状況を確認してください。

StandardV2 NAT GatewayのNAT64が向いているケース

NAT64は、次のようなケースに適しています。

  • IPv6通信を基本とするワークロードからIPv4専用APIへ接続したい
  • IPv4専用のパッケージリポジトリや外部サービスを利用したい
  • アプリケーション側の接続先をFQDNで統一できる
  • DNS64対応リゾルバーを自組織で管理できる
  • IPv4の送信元アドレスを固定したい
  • IPv6移行中もIPv4専用インターネットサービスとの互換性を維持したい

一方、次の用途には適していません。

  • インターネット側からIPv6ワークロードへ受信接続させる
  • プライベートIPv4ネットワークへ接続する
  • 接続先がIPv4アドレスでハードコードされている
  • DNS64を導入または管理できない
  • アプリケーション層のIPアドレス書き換えが必要
  • NAT Gatewayを通さず、Azure FirewallやNVAへ強制転送する必要がある

導入前に確認するチェックリスト

本番環境へ導入する前に、次の順序で確認すると切り分けやすくなります。

  • 展開先リージョンでStandardV2 NAT Gatewayを利用できる
  • StandardV2 IPv4パブリックIPを作成している
  • StandardV2 NAT Gatewayを対象サブネットへ関連付けている
  • NAT64をEnabledにしている
  • DNS64が64:ff9b::/96でAAAAレコードを合成している
  • ワークロードがDNS64リゾルバーを参照している
  • ipv4only.arpaで合成AAAAを取得できる
  • IPv4専用テストサーバーへcurl -6で接続できる
  • 接続先ログにNAT GatewayのIPv4パブリックIPが記録される
  • NSG、ルート、Firewall、DNSSECの影響を確認している
  • IPv4リテラルを使用するアプリケーションがない
  • 既存のLoad BalancerやFirewallとの送信経路競合を確認している

最初に確認すべきなのは、NAT Gatewayの設定画面ではなくDNS64の応答です。ipv4only.arpaのAAAAレコードが64:ff9b::/96で返らなければ、その後のNAT64変換には到達しません。

DNS64の合成、IPv6パケットの送信、NAT GatewayによるIPv4変換という3段階を分けて検証することで、Azure StandardV2 NAT GatewayのNAT64を確実に導入できます。

Azure
IPv6 IPv4 Azure NAT Gateway DNS64 NAT64

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次