Azure VM 上の RRAS はサポート対象外：設計前に確認を

ポータルを開き、Windows Server 2022 をサブネットに展開すると、Remote Access ロールは問題なくインストールされます。この手順が証明するのはインストーラーが動くことであり、Microsoft がその構成をサポートすることではありません。Azure 仮想マシン向けに公開されているサーバー ソフトウェアのサポート ガイダンスは、RRAS を Azure VM 上でサポートされない Windows Server 機能に含めており、これはトラブルシューティングの細部ではなくアーキテクチャの判断です。トンネルが上がっても、展開がサポート境界の内側に移るわけではありません。

以下の手順はサポート ページから始まり、そこから要件と代替案へと外側に進みます。

ラボではなく、サポート ページから始める

何かをサイジングする前に Azure VM のサポート ガイダンス を読み、これは Windows Server を一つの未分化なブロックとして扱うのではなく、サポートされる製品、ロール、機能を分けています。意図するワークロードが実際にどの行に該当するかに注意してください。コンソールで関連して見える二つのコンポーネントが、異なる行にあることがあります。

ページを開いているうちに、引用を設計文書に書き込んでください。サポート状況は出典のある事実であり、それを引用できない設計レビューは、デモを持つ相手に論破されます。

OS のサポートと、ロールおよび機能のサポートを分ける

同じガイダンスは Network Policy and Access Services をサポート対象のロールに挙げる一方、RRAS は別個にサポート対象外として挙げています。この二つの項目は別のものを説明しており、それらを「リモート アクセスはサポートされている」と一つにまとめるのが、誤読に基づいてプロジェクトが承認される道です。OS がサポートされていることは、独自の行を持つ機能について何も語りません。

この制限は、ときに引用されるより狭いものでもあります。Azure VM の内部で動作するその機能に関するものであり、プライベート ネットワークが Azure に接続できないという意味でも、RRAS がどこでもサポートされないという意味でもありません。パケットを正しく転送する古いラボは、パケットについての証拠であり、サポート声明についての証拠ではありません。

プロジェクトの残りを通じて、この二つの問い、つまり動くのか、サポートされているのかを分けておいてください。それぞれに別の答え、ときに別の担当者が必要になります。

設計が実際に何をすべきかを書き出す

代替案を選ぶ前に、サイト一覧を、製品を測定できる要件に変えてください：

• ブランチ機器がすでに話すトンネル プロトコル、および動的ルーティングが必要なサイトがあるかどうか。
• ルーティングではなく変換を必要とする重複したアドレス空間を含むリモート プレフィックス。
• Azure とのルート交換、およびルート テーブルの各エントリの所有者。
• 最も混雑する時間に耐える必要があるスループットと接続数。
• サイト所有者が合意したフェイルオーバー動作であり、あなたが構築できるものだけではありません。

NAT は飛ばされがちな項目であり、その後で設計全体を決めます。IPsec を確立できる機器でも、置き換える RRAS 展開とは異なる方法でアドレスを変換することがあり、それによってブランチが見る送信元アドレスと、ログに記録される内容が変わります。

その一覧をネットワークの所有者に持って行き、製品の議論の前に確認してください。曖昧な要件は、あらゆるベンダー比較を好みの議論に変えます。

その要件に対して代替案を評価する

Azure のマネージド接続サービスと、ベンダーがサポートするネットワーク仮想アプライアンスは、どちらも同じ一覧に対して採点する必要があります。IPsec を終端できるというだけで、どちらかが RRAS VM の直接の同等物だと決めつけず、NAT モデルとルートの所有権、そして高可用性の設計が、既存サイトの接続方法と応答の戻り先を決めます。各候補を紙の上で一覧に対して採点し、どの要件を満たさないかを書き留めておくと、そのメモが後で選択をレビュー可能にします。

二つのアプライアンス VM の前にあるロード バランサーは、それ自体では高可用性ではありません。フロントエンドを提供するのであって、同期されたトンネル状態ではなく、すべてのセッションを落とすフェイルオーバーは、誰かが意図的に選ぶ設計判断です。アプライアンスのベンダーに、サポートされる HA パターンは何か、それがサイトに約束された可用性と一致するかを尋ねてください。サイトがそれに依存する前にフェイルオーバーをテストし、失われたセッションはすべて驚きではなく所見として扱ってください。

要件が本当に単純な場合 — サイトが一つ、プレフィックスが一つ、重複なし — マネージド サービスが運用コストで勝つのが通常です。変換と動的ルーティングの両方が関わる場合、アプライアンスの道が唯一の適切な選択肢になることがあり、それがサポート対象外の VM を保持するのではなく、より長い移行を計画する理由です。

RRAS VM がすでに稼働している場合

発見は削除の理由にはなりません。その VM が蓄積した依存関係、つまり他のサブネットが依存するルート、送信元アドレスを隠す NAT ルール、監視がそのアドレスから期待することを学んだすべてを中心に変更を計画してください。サポートされる目標を並行して設計・検証する間、必要なルートとテスト済みの復旧経路を維持してください。

サポート可能性と技術的診断は、一貫して別々の所見として保ってください。サポート対象外の構成にも通常のルーティング エラーがあることがあり、そのエラーを修正してもサポート状況は変わりません。どちらの記述も報告書に属し、一方が他方を打ち消すことはありません。

サポートの引用、要件一覧、選んだ代替案、切り替え順序を記録して、この手順を締めくくってください。監査担当者や新しいチーム メンバーが最初に求めるのは、この四項目です。