※2024/06 時点の情報 / 環境で確認をしているため、今後動作は変わっている可能性があります。
2023/09/29 に Default outbound access for VMs in Azure will be retired? transition to a new method of internet access というアナウンスがありました。(2023/10/19 に Default outbound access for VMs in Azure will be retired? updates and more information 追加情報のアナウンスが行われています)
現状は、既定の送信アクセス が有効となっているため、明示的なインターネット送信接続の設定が行われていない場合、「既定の送信パブリック IP アドレス」が割り当てられ、インターネットへの送信接続が可能となっています。
2025/09/30 以降に新しくデプロイされたリソースについてはこの既定の送信アクセスが廃止され、これ以降にデプロイした VM については、既定の送信アクセス以外の方法 (パブリック IP アドレスの付与 / NAT ゲートウェイをサブネットに割り当て / パブリック IP アドレスを持つロードバランサーに割り当て) でインターネット送信接続の経路を確保する必要があります。
(期限日以降に展開した VM と VNET のどちらが対象となるのかが判断できていないため「リソース」という記載をしています)
今まで既定の送信アクセスを使用して、Windows のライセンス認証のための KMS にアクセスしていた VM について、既定の送信アクセスが廃止された後はどのような挙動になるのかが気になり試してみました。
Contents
既定の送信アクセスが廃止されたと想定した環境の検証方法
プライベート サブネットの利用
既定の送信アクセスが廃止されるのは 2025/09/30 ですが、それより前に既定の送信アクセスが廃止されたと想定した環境を構築して検証することが可能となっています。
2023/11/16 に Public preview: Private subnet でアナウンスがありましたが、新しく作成するサブネットについては「プライベート サブネットを有効にする (既定の送信アクセスなし)」という設定を有効にすることができます。
プライベート サブネットの設定については プライベート サブネット パラメーターを使用する で解説されていますが、この設定を有効にすると既定の送信アクセスが無効となり、2025/09/30 以降にデプロイした環境と同等のネットワーク構成とすることができます。
Windows VM の KMS 認証については、Azure Windows 仮想マシンのライセンス認証に関する問題のトラブルシューティング に記載されていますが、ネットワーク要件については、Azure での既定の送信アクセス / 強制トンネリングを使用したライセンス認証の問題 から確認することができます。
KMS の通信要件としては 20.118.99.224, 40.83.235.53, 23.102.135.246 の TCP 1688 へのアクセスが必要となりますが、既定の送信アクセスのドキュメントの次の記載のとおり、パブリックアクセスが必要となります。
特定のサービスは、明示的なエグレスのメソッドがないプライベート サブネット内の仮想マシンでは機能しません (Windows ライセンス認証や Windows 更新プログラムなど)。
Windows ライセンス認証と Windows 更新にはパブリック接続が必要です。 明示的な形式のパブリック送信接続を設定することをお勧めします。
そのため、プライベートサブネットに展開した Windows VM については、既定の送信アクセスができなくなるため、KMS を使用したライセンス認証ができない状態となります。
2025/09/30 以降にデプロイした環境では、明示的なインターネット送信接続の経路を持たない場合、KMS の認証がこのようにブロックされることになるのではないでしょうか。
NSG を使用して KMS へのアクセスをブロックすることができない理由
今回、プライベート サブネットをを使用して、インターネットへの送信接続ができない状態にしました。
簡易的にインターネットへの送信接続をブロックする場合、サービスタグに Internet を指定して拒否をするという方法を思い浮かべる方もいるのではないでしょうか。
残念ながら NSG では KMS へのアクセスをブロックすることができません。
この挙動については、Azure プラットフォームに関する考慮事項 に記載されています。
ライセンス (キー管理サービス) :仮想マシンで実行されている Windows イメージのライセンスを取得する必要があります。 ライセンスを適用するために、そのような問い合わせを処理するキー管理サービスのホスト サーバーには要求が送信されます。 この要求は、ポート 1688 を通じて送信されます。 default route 0.0.0.0/0 構成を使用したデプロイに関しては、このプラットフォーム ルールは無効となります。
KMS へのアクセスについては、内部的に設定されている「PlatformRule (プラットフォームルール)」で許可がされているため、ユーザー定義の NSG のルールではオーバーライドすることができません。
プラットフォームルールについては、0.0.0.0/0 に対してのルーティングを設定することで無効にすることができますが、強制トンネリングを使用したライセンス認証の問題 の解決のように、KMS へのアクセスは Azure から実施する必要があるため、ルーティングを使用した方法では想定した動作にならないのではないでしょうか。
Microsoft グローバルネットワーク経由でアクセスするサービスへの影響
Azure では、一部のサービスについては、マイクロソフトのグローバル ネットワーク 経由でアクセスが行われます。
私が関係するサービスとしては Azure ストレージと SQL Database があり、これらのサービスのネットワークについては以下に記載されています。
これらのサービスについては、Public IP が有効になっていない環境からもアクセスを行うことができます。
SQL Database への接続については、VM に SSMS をインストールし、Entra ID を使用した認証をしようとした場合にインターネットアクセスが必要となるため、アクセス方法によってはインターネット接続が必要となるケースもあります。
RedHat を使用した場合の影響
Azure で RHEL を使用した場合、Azure RHUI (Azure Red Hat Update Infrastructure) により提供されているリポジトリを使用することができます。
- 第1章 Red Hat Update Infrastructure の概要
- Azure のオンデマンド Red Hat Enterprise Linux VM 用 Red Hat Update Infrastructure
既定の送信が無効になっている場合、RHUI への接続についてもブロックされるようでした。
Azure RHUI に対してアクセスする際の IP アドレスについては RHUI コンテンツ配信サーバーの IP アドレス に記載されています。
これらアクセスについてはインターネット経由のアクセスとなるため、既定の送信が無効になっている場合は、KMS へのアクセスと同様にインターネットアクセスをするための接続経路の確保を検討する必要があります。
まとめ
今回はプライベート サブネットに対して NAT ゲートウェイを接続したのですが、先ほどまでは KMS で認証できなかった VM についても NAT ゲートウェイをサブネットに接続した後は、ライセンス認証が期待通り実行できています。
既定の送信アクセスの廃止は来年となるので、直近で影響を受けることはない / 期限より前に展開しているリソースについては影響を受けませんが、期限以降に展開したリソースがどのような挙動になるのかについては、今のうちに確認をしておいてもよいのではないでしょうか。
本挙動に関係するフィードバックが無いかを探してみたところ、5 年前に KMS / RHUI service endpoint というフィードバックが提案されていました。
このフィードバックの実装は 2025/09/30 以降のネットワーク構成に影響を与えるものとなるかと思いますので、このフィードバックへ賛同いただける方は今からフィードバックへの投票をお願いいたします。