Azure Network Managerってなに？

Azure Virtual Network Managerとも呼ぶようです。

トポロジー、セキュリティ、リージョン感のデプロイを安全に行うための機能だと認識しました。

機能を触ってみたいので、Network Managerを実際にデプロイしてみます。

サブスクリプション、リソースグループ、インスタンス名称、リージョンおよび利用する機能を指定します。

管理する範囲を選択します。

タグはとりあえず空欄のままとします。

概要を確認したら、作成します。

リソースに移動したら、エラーになりました。が気にせずちょっと待ってからリロードしたところ、概要が出ました。

デプロイしましたので、ネットワークグループを開いてみました。まだ何も無いです。

ネットワークグループを作ってみます。

ネットワークグループにメンバーとなる仮想ネットワークを追加します。リージョンは気にせつ仮想ネットワークを追加してみました。

メンバーの削除も可能ですね。

ネットワークグループのポリシーを見てみます。

Azure Policyの定義と割り当てが作成可能です。とりあえず作成しないで、そのままとしました。

構成を見てみます。既定では何も無いです。

「接続構成の作成」を進めてみます。

メッシュかハブアンドスポークを構成するための機能として捉えるのが良さそうですね！

ネットワークグループを追加します。

先ほど削除した別リージョンに対してネットワークグループをここで作成します。

複数のネットワークグループで構成したので、ハブを指定できます。

ハブアンドスポーク構成になりました。

構成の可視化を見てみます。

本環境は、すでにハブアンドスポーク的になっているので、作成は見送りました。

スクラッチから仮想ネットワークを作成する際、Network Managerを使えば容易にハブアンドスポーク構成を作れると感じます。（設計は事前に行なっておく必要ありますけどね）

セキュリティは、機会があれば確認したいな。

Default outbound access for VMs in Azure will be retiredなんですよね

2023年12月01日追記

Azure Monitor SCOM Managed Instance用の仮想ネットワークに別のサブネットを作成する を確認しているのですが、なんとなくだけどNATゲートウェイだけあれば良く、本稿に書いた ロード バランサーの作成 は、不要な気がしてきました。記事の内容を訂正するための確信がまだ持てませんが、可能性はあるかと思います。

2023年12月01日追記終わり
---

2023年9月29日に、Default outbound access for VMs in Azure will be retired— transition to a new method of internet access が公開され、話題になりましたね。現状特段何もしなくてもAzure 仮想マシンからインターネットへ接続できた（いわゆる、既定の送信アクセス）のが、2025年9月30日にリタイヤ/廃止されます。

その後、2023年10月19日に、

Default outbound access for VMs in Azure will be retired— updates and more information

も公開されましたね。

2025年9月30日までに、Azure のアウトバウンド接続方法 に記載されている下記のどれかを採用しなければなりません。

• 送信規則による送信には、ロード バランサーのフロントエンド IP アドレスが使用される
• サブネットへの NAT ゲートウェイの関連付け
  こちらが推奨ということです。
  既定の送信アクセスが提供されるタイミング  にて2番目に提供されることが確認できます。
• 仮想マシンへのパブリック IP の割り当て

今回は、サブネットへの NAT ゲートウェイの関連付け を確認していきます。大きく下記の二つで進めます。なおAzure Portalへのサインインは完了済みとして確認を進めます。

1. ロード バランサーの作成
2. チュートリアル: 送信アクセスを Azure NAT Gateway に移行する

ロード バランサーの作成

実は「クイック スタート:Azure portal を使用して、VM の負荷分散を行うパブリック ロード バランサーを作成する」の一節が、「ロード バランサーの作成」です。基本的にこの一節だけを使う感じです。

ただこの手順ではアウトバウンド規則を作らない点、留意しましょう。次のチュートリアルでは、ロードバランサーにあるアウトバウンド規則のフロントエンドIPを削除する手順になっていますが、それは不要だと認識してます。（あってるよね？！）

移行の手順は、ロード バランサーの作成 から引用します。

1. ポータルの上部にある検索ボックスに、「ロード バランサー」と入力します。 検索結果で [ロード バランサー] を選択します。
2. [ロード バランサー] ページで、 [+ 作成] を選択します。
3. [ロード バランサーの作成] ページの [基本] タブで、次の情報を入力または選択します。ここまでの設定例は下記の通り。
   
4. ページ下部にある [次へ: フロントエンド IP の構成] を選択します。
5. [フロントエンド IP 構成] で、[+ フロントエンド IP 構成の追加] を選択します。
6. [名前] に「lb-frontend」と入力します。
7. [IP バージョン] で [IPv4] を選択します。
8. [IP の種類] として [IP アドレス] を選択します。
9. [パブリック IP アドレス] で [新規作成] を選択します。
10. [パブリック IP アドレスの追加] の [名前] に「lb-frontend-ip」と入力します。
11. [可用性ゾーン] で、 [ゾーン冗長] を選択します。
12. [ルーティングの優先順位] は、既定値の [Microsoft ネットワーク] のままにします。
13. [OK] を選択します。ここまでの設定例は下記の通り。
    
14. [追加] を選択します。ここまでの設定例は下記の通り。
    
15. ページ下部で [次へ: バックエンド プール] を選択します。ここまでの設定例は下記の通り。
    
16. [バックエンド プール] タブで、 [+ バックエンド プールの追加] を選択します。
17. [バックエンド プールの追加] の [名前] に「lb-backend-pool」と入力します。
18. [仮想ネットワーク] で [lb-vnet] を選択します。
19. [バックエンド プールの構成] には [IP アドレス] を選択します。
20. [保存] を選択します。ここまでの設定例は下記の通り。
    
21. ページ下部にある [次へ: インバウンド規則] を選択します。ここまでの設定例は下記の通り。
    
22. [インバウンド規則] タブの [負荷分散規則] で、[+ 負荷分散規則の追加] を選択します。
23. [負荷分散規則の追加] で、次の情報を入力または選択します。ここまでの設定例は下記の通り。
    
24. [保存] を選択します。ここまでの設定例は下記の通り。
    
25. ページ下部にある青色の [確認と作成] ボタンを選択します。送信規則（アウトバウンド規則）がスキップされたことにご留意ください。ここまでの設定例は下記の通り。
    
26. ［作成］ を選択します。ここまでの設定例は下記の通り。
    
27. 以上で外部ロードバランサーの作成は完了です。

チュートリアル: 送信アクセスを Azure NAT Gateway に移行する

移行の手順は、チュートリアル: 送信アクセスを Azure NAT Gateway に移行する の「既定の送信アクセスを移行する」から引用します。

1. ポータルの上部にある検索ボックスに、「NAT ゲートウェイ」と入力します。 [NAT ゲートウェイ] を選択します。
2. [NAT ゲートウェイ] で、 [+ 作成] を選択します。
3. [ネットワーク アドレス変換 (NAT) ゲートウェイを作成します] の [基本] タブで、次の情報を入力または選択します。
4. [送信 IP] タブを選択するか、ページの下部にある [次へ: 送信 IP] を選択します。ここまでの設定例は下記の通り。
   
5. [送信 IP] タブの [パブリック IP アドレス] で、[新しいパブリック IP アドレスの作成] を選択します。
6. [パブリック IP アドレスの追加] で、[名前] に「myNATGatewayIP」と入力します。 [OK] を選択します。ここまでの設定例は下記の通り。
   
7. [サブネット] タブを選択するか、ページ下部にある [次へ: サブネット] を選択します。ここまでの設定例は下記の通り。
   
8. [仮想ネットワーク] のプルダウン ボックスで、お使いの仮想ネットワークを選択します。
9. [サブネット名] で、目的のサブネットの横にあるチェック ボックスをオンにします。
10. [確認と作成] タブを選択するか、ページの下部にある [確認と作成] を選択します。ここまでの設定例は下記の通り。
    
11. ［作成］ を選択します。
    
12. 以上でNAT ゲートウェイの作成は完了です。

既定の送信アクセスが提供されるタイミング  にて2番目に提供されるのがNATゲートウェイですから、既定の送信アクセスを介さずにインターネットアクセスが可能になっているはず。やり方が間違っていないと良いのですが。

MS Ignite近辺でAzure Stack HCIのトピックを振り返る

Ignite 2022のセッションというより、

Microsoft Ignite BOOK OF NEWS

からたどった

What's new for Azure Stack HCI at Microsoft Ignite 2022

にまとめられています。内容はいろいろなところで聞いています。
が、自分で確認する意味も込めて、リストアップします/引用します/意訳します/文面を読んでざっくりまとめます。

1. New benefit for Software Assurance customers
   Software Assuranceを締結されているEnterprise Agreementを締結済みの企業様は、Azure Stack HCIのライセンスコア費用を追加で支払う必要がなくなり、AKSとWindows Serverの仮想マシンを無制限に実行できるということです。
2. Azure Arc-enabled VM management: Public Preview 2
   
• Azure Marketplaceから仮想マシンイメージをダウンロードできるようになった。なので、AVD for Azure Stack HCI向けにWindows 11 Enterpriseマルチセッションをダウンロードできます。Azure Stack HCIへWindows Server 2022 Azure Editionも簡単にダウンロードできます。
  ※仮想マシンイメージを手動ダウンロードしなくてよくなるのでうれしい。
  ※これらの仮想マシンイメージは、Azure Arcエージェントが同梱されているということで、こちらももうれしいですね。
• Azure ArcからVMをデプロイすると、ゲストOSは自動的にArcに対応します。その際、ADドメイン参加のようなVMエクステンションを使ってOSを設定したり、カスタムスクリプトを使ってアプリケーションを展開・設定したりできます。
  ※これもうれしいですね。
  これの一例として、AVDセッションホストプールを自動参加させるARMテンプレートが使える旨も記載があります。
3. 22H2 feature update
• 製品品質の改善が図られた。
• Network ATCがクラスタ内ストレージネットワークにIPアドレスを自動的に割り当て、使用目的に応じてクラスタネットワークに自動的に命名できます。また、最適なネットワークの選択、最適なトランスポート、最適な帯域幅の割り当てなど、ライブマイグレーション設定を管理できます。
• ストレージ管理はより柔軟で、既存のストレージボリュームを変更して耐障害性を高めたり（例：2ウェイミラーから3ウェイミラー）、固定プロビジョニングからシンプロビジョニングに変換できます。
  ※検証用途だからシンプロビジョニングにしたい場合に良いですかね。
• ストレッチクラスタ内のサイト間のストレージレプリケーションは、新しいオプションの圧縮機能により、より高速化。
• Hyper-Vライブマイグレーションは、スイッチレス2ノードおよび3ノードクラスタにおいて、より信頼性が高くなったとのこと。
• 新しいタグベースのネットワークセグメンテーションにより、選択したカスタムタグに基づく横方向の脅威から仮想化ワークロードを保護できます。
• 管理ツールによる22H2のサポート
• 現状のWindows Admin Centerを使ってバージョン22H2を管理できるようです。
  ※2110.2 GAふくめ、急ぎ確認してみます。
• 11月中旬に次のWindows Admin Centerのリリースされ、変更可能なボリューム設定、改良されたクラスタ設定のデザインなど、新機能をライトアップする機能拡張が行われる予定とのこと。
• 11月中旬には、System Center 2022の最初のUpdate Rollup（UR1）により、Azure Stack HCI、バージョン22H2の正式サポートが追加されるとのこと。
  ※SCVMM 2022は、Hyper-VホストにVMMエージェントをプッシュインストールできない問題があるので、UR1が近日中にリリースされるのはうれしいです。
4. Hybrid Azure Kubernetes Service
• AKS on Azure Stack HCI上の2022年9月のアップデートは現在提供されており、いくつかの重要な機能強化があるそうです。
• LinuxコンテナのベースイメージがMariner 2.0に更新され、Mariner 1.0の半分以下のサイズになったとのこと。より安全で、より高速にアップグレードされ、約3,000の追加・更新されたパッケージが含まれているとのこと。
• Software-Defined Networking (SDN) の統合が一般的に利用可能になり、実稼働環境での利用可能。
• GPUをコンテナにアタッチする手順が簡素化。
• 皆様からのフィードバックに基づいて、システム管理者グループのどのアカウントでもAKSの管理に使用可能とのこと。
• Azureから直接ハイブリッドAKSクラスタをプロビジョニングするパブリックプレビューも発表されているとのこと。
• AADのIDを使用して、Arc Resource Bridgeを通じて、Arc対応のVM管理と非常によく似た、全く新しいKubernetesクラスタをオンプレミス環境にプロビジョニングできます。
  ※これは助かりますねー
• ポータルGUIの一貫性に加え、ハイブリッドAKSは、GitOpsを通じてより一貫性のある構成管理機能を提供します。GitOpsは、GitやHelmリポジトリなどの一般的なファイルソースや、YAMLやKustomizeなどのテンプレートタイプをサポートする、人気のオープンソースツールセットであるFluxを使用しています。
  ※引き続き確認しなければいけないな。
5. One more thing… hardware!
   また聞きですけど、Azure Stack Edgeの代替になるようです。

やっぱり自分でも理解するよう、ちゃんと読み込まないとダメと痛感。。。

Windows Admin Center on Azure で生成される Network Security Group

Windows Admin Center on Azure を有効化/インストールする際に二つのオプションを選択できます。

一つ目のオプションは、「このポートを開く（テスト目的のみが推奨）」です。これは、パブリック IP アドレスにおいて 6516/TCP を開くことを意味します。なので、"テスト目的のみが推奨"なわけです！
実際のネットワークセキュリティグループ（NSG）だと下記のようになります。
※当該 Azure 仮想マシンは、パブリック IP アドレスを付与していません。安全な状態で画面キャプチャーしてます。

ということで、NSG を削除してしまえば、うっかりポートを開けてしまっても大丈夫かも。

二つ目のオプションは、「Windows Admin Center をインストールするために送信ポートを開く」です。対象の仮想マシンがすべての送信トラフィックをブロックしている場合には、必須で選択します。

実際のネットワークセキュリティグループ（NSG）だと下記のようになります。

Azure IaaS で NAT 仮想スイッチを構成 その2

Azure IaaS で NAT 仮想スイッチを構成 その1からの続き

作ってみて、動きを理解するために、tracert を実行してみます。

NAT ネットワークのセットアップ
入れ子になった仮想化による仮想マシンでの Hyper-V の実行

のコマンドを入力していきます。（一部アレンジしてます）

New-VMSwitch -SwitchName "SwitchName" -SwitchType Internal

Get-NetAdapter
New-NetIPAddress -IPAddress <NAT Gateway IP> -PrefixLength <NAT Subnet Prefix Length> -InterfaceIndex <ifIndex>

New-NetNat -Name <NATOutsideName> -InternalIPInterfaceAddressPrefix <NAT subnet prefix>

NATネットワークができたので、仮想マシン側の設定をしました。

NATのGateway、Azure IaaS上にいる仮想マシンに ping を実行。問題なし。

Azure IaaS上にいる仮想マシンに tracert を実行。問題なし。

Windows Update も実行できました。