Azure P2S クライアント認証：Entra、証明書、RADIUS のどれを選ぶか

インストーラーは実行でき、プロファイルもインポートできるのに、サインインの段階で接続が失敗する。こうしたチケットの多くはクライアントの不具合ではない。OpenVPN 互換アプリはトンネルを運べても、Microsoft Entra のサインインを実行する方法を知らないことがある。迷いを避ける順序は、方式、次にクライアント、最後にプロファイルだ。ゲートウェイに設定された認証方式を選び、その方式について Microsoft が文書化しているクライアントを選び、そのうえでそのクライアントが期待するプロファイルを生成する。以下の内容はすべてこの順序に従う。

インストーラーではなく方式から始める

ゲートウェイには一つ以上のトンネルの種類と認証方式が設定されている。デスクトップ上のファイル拡張子ではなく、この組み合わせがどのクライアントをサポートするかを決める。

何かをダウンロードする前にこの組み合わせを書き留める。サポートの対応表は狭く、最初を誤ると半日を失う。

導入メモに残している対応関係は次のとおりだ。

この表はメニューではなく制約として読む。各行は文書化された組み合わせであり、ある行のクライアントを別の行の方式と混ぜることが、この記事が防ごうとしている失敗そのものだ。

Entra ID は OpenVPN と Azure VPN Client の組み合わせを意味する

ポイント対サイトの Entra 認証では、サポートされる構成は OpenVPN トンネルの種類と Azure VPN Client を使う。一般的なユーザー名とパスワードのダイアログはこの統合の代わりにならず、Windows 標準の IKEv2 も同じサインインを行う代替手段ではない。サードパーティのクライアントが Entra や Azure AD のオプションを掲げていても、ラベルではなく現在の Microsoft のドキュメントで確認する。ラベルはマーケティングであり、文書化された組み合わせが契約だ。

macOS でも Azure VPN Client がこの方式の文書化された経路だ。

証明書にはルートだけでなくクライアント資格情報が必要

証明書認証は別個にサポートされるモデルで、Microsoft が文書化している OpenVPN クライアントと、サポート対象プラットフォームの Azure VPN Client で動作する。Windows の Azure VPN Client は Entra 専用ではない。証明書の文書化されたワークフローもある。必要なのは、ゲートウェイが信頼する、使用可能な秘密鍵を持つ目的のクライアント証明書だ。ゲートウェイの信頼されたルートはクライアント資格情報ではなく、発行者の署名鍵がクライアントパッケージに含まれることは決してない。

プロファイルをデバッグする前にチェーンを確認する。ゲートウェイが信頼しないルートから発行された証明書は、プロファイルの不備に見えて実際には信頼の問題である失敗を生む。

プラットフォームが許す場所では秘密鍵をエクスポート不可にし、現在のユーザーに実際にインストールされた証明書でテストする。

RADIUS は独自の組み合わせを持つバックエンドの選択肢

RADIUS は資格情報の判断を自分で運用するサーバーへ移し、特定のトンネルの種類とクライアントについて文書化されている。環境に複数のオペレーティングシステムがあるからといって、自動的に正解になるわけではない。ゲートウェイの認証ポリシーを変える前に、実際のクライアントが何を提示できるかを特定する。ゲートウェイを RADIUS に切り替えても、既存のプロファイルすべてが適合するわけではない。クライアントは依然としてその資格情報を要求または提供できなければならない。

混在環境が理由なら、全員のためにゲートウェイのポリシーを弱めるのではなく、プラットフォームごとに解決する。

2026 年のプレビュー終了後の Linux

Microsoft の Linux 終了に関するガイダンス は、Linux 用 Azure VPN Client プレビューの終了日を 2026 年八月31日としているため、2026 年十一月の時点でそのプレビューは過去のものだ。既存のインストールは動作し続ける可能性があるが、サポート、更新、セキュリティ修正は受けられなくなる。古い Linux インストーラーをサポート対象の新規導入として配布してはならない。これはクライアントの終了であり、Azure VPN Gateway や Windows と macOS のクライアントの終了ではない。

文書化された Linux の代替は、証明書認証を使う OpenVPN クライアント、または IKEv2 と証明書認証または RADIUS 認証を使う strongSwan だ。どちらも組織の承認が必要な別の構成であり、古い Entra プロファイルの名前を変えるだけで得られる変換ではない。

ポリシー上の理由で Entra サインインが必須なら、所有者はサポート対象のプラットフォームか承認済みの代替設計を選ぶ必要がある。それは回避策ではなく判断だ。

プロファイルを生成し四つの確認を行う

組み合わせが決まったら、目的のゲートウェイからクライアント構成を生成し、そのクライアントと方式について文書化された表現をインポートする。汎用の OpenVPN フォルダーと Azure VPN Client の XML プロファイルは互換ではない。ゲートウェイが意図的に複数の認証の種類を有効にしている場合は、一つの接続ですべてを満たそうとせず、対応するプロファイルと資格情報の経路を選ぶ。そのうえで次の順に確認する。

• サポート対象のクライアントが、生成されたプロファイルを編集せずにインポートする。
• 目的の ID が、そのプロファイルの期待する方式で認証される。
• 必要なルートとリゾルバーのポリシーがクライアントに現れる。
• 許可されたアプリケーションがプライベートリソースに到達する。

インポートの成功は認証の互換性もプライベートリソースの承認も証明しない。だからこそこの四つの確認は分けたままにする。