Windows Pro のデバイス トンネル？エディション マトリックスを確認する

プロファイルはノート PC に配信され、VPN 設定ページにも表示されるのに、デバイス トンネルはサインイン画面で決して接続しません。Windows Pro では、これは多くの場合構成エラーではありません。ネイティブのデバイス トンネルはエディションごとにライセンスされ、サインイン後に機能するユーザー トンネルは別の能力を証明しているにすぎません。証明書をデバッグする前に要件を読んでください。

症状は誰かがサインインする前に現れる

ユーザー トンネルはサインイン後にユーザーのコンテキストで接続するため、Pro でも通常どおり機能します。デバイス トンネルは、どのユーザーもログオンする前に、マシン証明書と IKEv2 を使ってマシンの接続を確立するものです。これらはライフサイクルの異なる段階であり、同じプロファイルの二つの名前ではありません。

適格でないエディションでもプロファイルは配信され一覧に表示されますが、サインイン前の接続は現れません。サインイン後はユーザー トンネルが完全に機能することがあり、そのためアカウント所有者が行うどの確認でも展開は正常に見えます。この失敗は、サインイン済みのセッションの内側からは見えません。

プロファイルをすべてのユーザーが利用できるようにしても、使える人が変わるだけです。認証コンテキストがユーザーからマシンに変わるわけではないため、ユーザー トンネルをデバイス トンネルに変えることはできません。違いはプロファイルの可視性ではなく、認証コンテキストにあります。

マトリックスを読む。CSP ノードだけでは不十分

Microsoft の Windows 11 機能マトリックス には、Enterprise と Education 向けのネイティブ Always On VPN デバイス トンネルが記載されています。VPNv2 構成サービス プロバイダーは DeviceTunnel ノードを別途文書化しており、その適用範囲には Pro が含まれます。この行は機能が動く証拠としてよく引用されます。構成面と機能のライセンスは別の問いに答えます。一方は設定を表現できると言い、もう一方はエディションにその能力の権利があると言います。

購入記録を信じるのではなく、実際のエディションとビルドを確認してください。管理されたライセンス認証、進行中のアップグレード、再構築されたイメージは、資産一覧の記載と異なるエディションにマシンを残すことがあります:

winver
DISM /online /get-currentedition
Get-ComputerInfo | Select-Object WindowsProductName, WindowsEditionId, OsBuildNumber

出力が Pro なら、そのマシンに文書化された機能セットにネイティブのデバイス トンネルは含まれません。この結論にプロファイルの変更は不要で、変更しても修正されません。他の何かを変える前に、この所見を記録してください。

機能フラグの背後にある四つの前提条件

エディションが関門であり、残りの要件は適格なエディションのマシンがそれでも失敗する理由を説明します。順番に確認してください。どれも同じ静かな結果を生み得ます。一行を飛ばすと、その下の行に費やした労力が無駄になります。エディションが最初に来るのには理由があります。

証明書の確認は人々が飛ばしがちな項目です。秘密キーはマシン ストアに存在し、サインイン前にシステム コンテキストから使用可能でなければなりません。これはユーザーが自分の証明書ダイアログで見るストアとは別のストアです:

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.HasPrivateKey } | Select-Object Subject, NotAfter

ユーザーのストアで正しく見える証明書が、マシン ストアには完全に存在しないことがあります。その場合、ログオン画面が現れる前にデバイス トンネルは認証に失敗し、プロファイルを再インポートしても変わりません。サービスが使うストアを確認し、ユーザーが見るストアを確認しないでください。

SYSTEM として実行するスケジュール タスクはこの機能ではない

SYSTEM として実行するスケジュール タスクから VPN プロファイルを起動し、起動直後にトンネルが現れるようにする回避策が出回っています。それはネイティブのデバイス トンネルではありません。タスク エンジンは別の時点で起動し、接続はサービス アカウントが開始するユーザー モードのプロファイルであり、ライフサイクルはサインイン画面に存在すべきマシン認証のトンネルと一致しません。

誰かがサインインして確認する頃にはトンネルが上がっているため、簡単なテストは通るかもしれません。その成功は起動とタスクの間の遅延を測っているのであって、サインイン前の接続性を測っているのではなく、機能がカバーすべき時間帯にマシンをトンネルなしのままにします。

この回避策は実運用ではサポート対象外として扱ってください。設計がそれに依存しているなら、要件はおそらくログオン前の接続であり、議論はエディションの適格性に戻ります。

技術より先に要件を選ぶ

要件を一文で書いてください。どのユーザーもサインインする前にデバイスが名前付きリソースへ到達できる必要がある、またはユーザーがサインイン後にアクセスを必要とする、のどちらかです。後者が真なら、Pro の Always On ユーザー トンネルはサポートされた設計であり、デバイス トンネルは不要な複雑さです。

前者が真なら、エディションは厳しい関門です。適格なエディション、または組織がサポートする文書化されたログオン前アーキテクチャを選び、マシンが実行できない能力の周りにプロファイルと証明書を構築する前に、ライセンス変更を計画してください。

展開ノートにエディション、参加状態、証明書の場所、プロビジョニング チャネルを記録してください。そうすれば次のエンジニアは、決して接続しないマシンで同じプロファイルのトラブルシューティングを繰り返す代わりに、数分で適格性を確認できます。