Windows Server 2016 の Server Core で Always On VPN を動かしたいのに、GUI 前提の情報ばかりで手順が見つからない──そんな状況でも構築自体は可能です。ポイントは「Always On VPN はサーバーに追加する単体機能ではなく、RRAS を中核にした展開シナリオ」であること。Server Core はローカル GUI で完結しないため、最初からリモート管理前提で組み立てるのが近道です。
Server Core でも Always On VPN は実現できる（ただし“考え方”が重要）
結論から言うと、Windows Server 2016 の Server Core でも VPN サーバー（RRAS） は構築できます。そして Always On VPN は、その RRAS を使って「クライアントを常時接続前提で運用できるようにする」ための 構成（設計＋設定＋配布） です。
つまり、探していた「Always On VPN を Server Core にインストールする手順」が見つからないのは自然で、以下のように捉えると情報が整理できます。
- サーバー側：RRAS（Remote Access）で VPN を提供できる状態を作る
- 認証側：NPS（RADIUS）や証明書（PKI）で安全に認証できる状態を作る
- クライアント側：Windows 10/11 の VPN プロファイルを “Always On” の方針で配布・運用する
Always On VPN の構成要素を俯瞰して、作業の迷子を防ぐ
Server Core でつまずきやすいのは「どこまでが VPN サーバーで、どこからが Always On VPN の領域なのか」が曖昧になりやすい点です。まずは全体像を表で押さえると、実装の順番が見えます。
| 要素 | 役割 | 置き場所の例 | Server Core との相性 |
|---|---|---|---|
| RRAS（Remote Access / VPN） | VPN 接続の終端（SSTP / IKEv2 など） | Windows Server 2016（Core 可） | ◎（ただし設定はリモート前提） |
| NPS（RADIUS） | EAP-TLS などの認証/認可、ポリシー | 別サーバー推奨（同居も可） | ○（運用は分離が楽） |
| AD DS | ユーザー/端末の管理、グループ、証明書自動登録 | 既存のドメイン | 既存運用に依存 |
| AD CS（社内 CA） | サーバー証明書、端末/ユーザー証明書の発行 | 別サーバー推奨 | ○（CRL 公開が肝） |
| クライアント配布（Intune/MDM/GPO/PS） | Always On 設定の VPN プロファイル配布 | 管理基盤側 | サーバーとは別領域 |
Server Core で詰まりがちなのは「RRAS を入れたのに Always On VPN にならない」という認識違いです。RRAS はあくまで土台で、Always On 化はクライアント側のプロファイル設計と配布が主役になります。
先に決めておくべき設計ポイント（後戻りが高い部分）
構築手順に入る前に、最低限ここだけは決めておくと、設定のブレが減ります。
| 項目 | 判断基準 | おすすめ（一般的） | 注意点 |
|---|---|---|---|
| VPN プロトコル | 到達性/セキュリティ/運用 | IKEv2（推奨）＋必要なら SSTP 併用 | IKEv2 は UDP 500/4500 が通る必要あり |
| 認証方式 | 安全性/運用負荷 | EAP-TLS（証明書） | CRL 到達性が最重要。外部公開の設計必須 |
| トンネル種別 | 要件（ログオン前/端末管理） | まず User Tunnel で検証 → 必要なら Device Tunnel | Device Tunnel は端末要件・配布要件が厳しめ |
| アドレス割当 | 既存ネットワーク設計 | DHCP または静的プール | 名前解決（DNS）とルート設計とセットで考える |
| Split/Force Tunnel | セキュリティ/帯域/運用 | 基本は Split（必要な宛先だけ VPN 経由） | 社内リソースの名前解決（DNS/NRPT）が鍵 |
Server Core 側の事前準備（ここが弱いとリモート設定で止まる）
Server Core は「現地で MMC を開いて設定」ができません。だからこそ、最初にリモート管理の土台を固めます。
- サーバー名（ホスト名）を確定し、FQDN（例：vpn.example.local / vpn.example.com）を整備
- 固定 IP、既定ゲートウェイ、DNS サーバーを設定
- 時刻同期（ドメイン参加なら基本は揃うが、ズレると証明書系が地獄）
- Windows Update を適用（RRAS/NPS 周りは更新が効く）
- リモート管理を有効化（環境により既定が異なるため、明示的に確認）
Server Core の基本操作は sconfig が便利です（ドメイン参加、更新、リモート管理の有効化などをメニューで実施）。「Server Core は触りにくい」印象が強い場合でも、ここを押さえると一気に運用しやすくなります。
Server Core に RRAS（Remote Access）役割を追加する（PowerShell）
Always On VPN のサーバー側の中心は Remote Access（RRAS） です。Server Core では PowerShell で役割を入れます。役割名（Feature 名）が環境で揺れることがあるため、最初に Get-WindowsFeature で候補を確認してから入れるのが安全です。
役割の確認（例）
Get-WindowsFeature *Remote*
Get-WindowsFeature RemoteAccess
Get-WindowsFeature *VPN*
Get-WindowsFeature *Routing*代表的な追加例（検証環境向けのイメージ）
# Remote Access（RRAS）本体
Install-WindowsFeature -Name RemoteAccess -IncludeManagementTools
# VPN（RAS）系の役割サービス（環境により名称が異なる場合あり）
Install-WindowsFeature -Name DirectAccess-VPN -IncludeManagementTools
# ルーティングが必要な場合
Install-WindowsFeature -Name Routing -IncludeManagementTools
Restart-Computerポイントは -IncludeManagementTools を付けておくことです。Server Core 自体に GUI コンソールが載るわけではありませんが、モジュールや管理コンポーネントが揃っていると、後の切り分けや PowerShell 操作がやりやすくなります。
Server Core で GUI が使えない問題は「リモート管理」で解決する
RRAS の設定は Server Core 上で完結させようとすると苦しくなります。現実解は以下のどちらか（または併用）です。
| 管理方法 | 使う端末 | できること | 向いている場面 |
|---|---|---|---|
| Routing and Remote Access（RRAS MMC）でリモート接続 | 管理用 PC（Windows 10/11）または管理サーバー | RRAS の構成ウィザード、VPN 有効化、ポート/認証の設定 | 初期構築・設定作業の中心 |
| Remote Access Management Console（リモート アクセス管理） | 管理用 PC / 管理サーバー | Remote Access 関連の管理（構成による） | DirectAccess と並行運用など |
| PowerShell（RemoteAccess モジュール等） | Server Core / 管理端末 | 状態確認、部分的な設定、ログ確認 | 運用・自動化・切り分け |
管理用 PC 側は RSAT（管理ツール）を入れ、MMC から「ルーティングとリモート アクセス」を起動し、対象サーバーへ接続します。Server Core 側で必要なファイアウォールや WinRM が閉じているとここで止まるため、事前準備が効いてきます。
RRAS を VPN サーバーとして構成する（リモート MMC での実務手順）
Server Core にはローカル GUI がないため、以下は「管理端末から RRAS コンソールで Server Core に接続して行う」前提の流れです。
- 管理端末で「ルーティングとリモート アクセス」を起動し、対象サーバーへ接続
- サーバー名を右クリックし、「ルーティングとリモート アクセスの構成と有効化」
- ウィザードで「VPN アクセス」を有効化（必要なら NAT/ルーティングも）
- VPN クライアントに割り当てる IP の方式（DHCP / 静的アドレスプール）を選択
- 認証方式を決定（Windows 認証か、RADIUS（NPS）か）
- 利用するプロトコル（IKEv2 / SSTP など）と証明書の準備状況を確認
Always On VPN の本番運用では、認証/認可を NPS に寄せる構成が多く、RRAS は「接続終端」に寄せてシンプルに保つと運用が安定します。検証段階ではまず Windows 認証で疎通を取り、その後 NPS/EAP-TLS へ移行する段階分けが現場では失敗しにくいです。
プロトコル選びの現実解：IKEv2 を主軸に、SSTP を保険にする
Always On VPN でよく使われるのは IKEv2 と SSTP です。それぞれの性格を表で押さえておくと設計ミスが減ります。
| 方式 | 通信 | 長所 | 落とし穴 | おすすめ度 |
|---|---|---|---|---|
| IKEv2 | UDP 500/4500（IPsec） | 高速・安定・モバイル回線でも復帰が強い | ネットワークによって UDP が塞がれるとつながらない | 高 |
| SSTP | TCP 443（HTTPS） | 通りやすい（プロキシ/ファイアウォール環境で強い） | 証明書（サーバー証明書）に起因するトラブルが多い | 中（保険） |
| L2TP/IPsec | UDP 1701 ほか | 互換性はある | 前提が増えがちで、常時接続の運用では選びにくい | 要件次第 |
| PPTP | TCP 1723 ほか | 設定は簡単 | セキュリティ上の理由で基本的に推奨されない | 低 |
Server Core で構築するからこそ、「あとから方式を切り替える」より「最初から IKEv2 を主に、SSTP を必要に応じて併用」という形で組むと、手戻りが少なくなります。
証明書（PKI）設計が Always On VPN の成否を決める
Always On VPN を “Always On” らしく、安全に運用するなら、証明書認証（EAP-TLS）を軸にした設計が王道です。ここが曖昧だと「つながるが不安定」「特定ユーザーだけ失敗」「社外だと認証で落ちる」などの事故に直結します。
最低限おさえるべき証明書の種類
| 証明書 | 入れる場所 | 用途 | よくあるミス |
|---|---|---|---|
| VPN サーバー証明書（サーバー認証） | RRAS サーバー | SSTP の TLS、IKEv2 のサーバー認証（構成次第） | CN/SAN が接続先名と不一致、秘密鍵なし、期限切れ |
| ユーザー証明書 | クライアント（ユーザー） | User Tunnel の EAP-TLS | テンプレート EKU 不足、失効、配布漏れ |
| デバイス証明書（端末証明書） | クライアント（端末） | Device Tunnel の EAP-TLS（端末として認証） | 端末に自動配布されていない、秘密鍵利用不可 |
| ルート/中間 CA 証明書 | クライアント | 信頼の起点 | クライアントが CA を信頼しておらず認証失敗 |
| CRL（失効リスト）の公開 | HTTP などで外部から到達可能に | 失効確認 | 社外から CRL に到達できず EAP-TLS が失敗 |
特に重要なのが CRL（証明書失効リスト） です。社外のクライアントが VPN に入る前に失効確認をしようとして、CRL 配布ポイントに到達できず失敗するケースは非常に多いです。Always On VPN の「手順が合っているのに繋がらない」原因の上位がここになります。
Server Core での証明書取り回し（現場で使う実用パターン）
- サーバー証明書は PFX で受け取り、Server Core に Import-PfxCertificate で投入
- 証明書ストアの確認は PowerShell で行い、必要なら管理端末から MMC（証明書スナップイン）でリモート確認
- 更新手順（有効期限・更新タイミング）を運用手順書に先に書く（期限切れは障害として発覚しがち）
PFX の取り込み例
$pfxPath = "C:\Temp\vpnserver.pfx"
$pwd = Read-Host -AsSecureString "PFX Password"
Import-PfxCertificate -FilePath $pfxPath -CertStoreLocation Cert:\LocalMachine\My -Password $pwdNPS（RADIUS）を使うと “Always On らしい運用” に近づく
Always On VPN は「常時接続」であるほど、認証・認可の運用が重要になります。RRAS 側で完結させるより、NPS を併用してポリシーを集約したほうが以下のメリットが出やすいです。
- アクセス許可の条件（ユーザー/端末グループ、時間帯、認証方式）を集中管理できる
- ログが追いやすい（成功/失敗理由の切り分けがしやすい）
- 将来的な拡張（MFA、条件付きアクセス相当の考え方）を設計に載せやすい
NPS を入れる構成にする場合、RRAS は NPS を RADIUS サーバーとして参照し、NPS 側で接続要求ポリシー/ネットワークポリシーを組みます。ここでの現場感としては、「まず疎通、次に認証を強化」の順が失敗しにくいです。
クライアント側が本番：Always On VPN プロファイル設計と配布
RRAS を立てただけでは Always On VPN にはなりません。最後に “Always On” の挙動を作るのは Windows 10/11 側の VPN プロファイルです。ここを丁寧に作ると、Server Core でも安定した運用になります。
User Tunnel と Device Tunnel をどう使い分けるか
| 項目 | User Tunnel | Device Tunnel |
|---|---|---|
| 接続タイミング | ユーザー ログオン後 | ログオン前（端末として接続） |
| 主な用途 | 社内アプリ、ファイルサーバー、業務システム | ドメイン到達が必要な端末管理、ログオン前リソース |
| 認証主体 | ユーザー（ユーザー証明書など） | 端末（デバイス証明書など） |
| 導入難易度 | 低〜中 | 中〜高（端末要件・配布手段・設計が増える） |
「まず動かしたい」「検証したい」という段階では User Tunnel から開始し、端末管理やログオン前の要件が明確になってから Device Tunnel を検討するのが、結果的に最短ルートになりやすいです。
配布手段の選択（Intune/MDM があるかで難易度が変わる）
| 配布方法 | 特徴 | 向いている環境 | 注意点 |
|---|---|---|---|
| Intune / MDM（VPNv2 CSP） | 端末へ一貫配布、更新も容易 | クラウド管理をしている/したい | 設計自由度は高いが項目が多い |
| PowerShell | 検証が速い、スクリプト化しやすい | ラボ・PoC・小規模 | 本番の更新運用をどう回すか要設計 |
| GPO（構成による） | ドメイン管理で一括 | オンプレ中心 | 要件によっては表現できる範囲に限界がある |
配布の本命は Intune/MDM ですが、検証は PowerShell で「設定項目が正しいか」を短時間で確認し、その後 MDM に落とし込む進め方が現場では効率的です。
（例）PowerShell で User Tunnel を作って挙動確認する
以下はあくまで “検証用のたたき台” です。認証方式、ルート、DNS、AlwaysOn、Trusted Network Detection などは要件に合わせて調整してください。
# 例：IKEv2 の VPN 接続（User Tunnel のたたき台）
Add-VpnConnection `
-Name "AOVPN-User" `
-ServerAddress "vpn.example.com" `
-TunnelType IKEv2 `
-AuthenticationMethod Eap `
-EncryptionLevel Required `
-RememberCredential:$false `
-SplitTunneling $true
# Always On 化（可能な範囲で）
Set-VpnConnection -Name "AOVPN-User" -AlwaysOn $true
# 例：社内ネットワーク宛てのルート（Split Tunnel の場合）
Add-VpnConnectionRoute -ConnectionName "AOVPN-User" -DestinationPrefix "10.0.0.0/8"
Add-VpnConnectionRoute -ConnectionName "AOVPN-User" -DestinationPrefix "192.168.0.0/16"Always On VPN の“らしさ”は、次のような設定が揃って初めて出ます。
- Trusted Network Detection（社内にいるときは VPN を張らない/張っても意味がない状態を避ける）
- 社内名前解決（DNS サフィックス、必要なら NRPT 相当の設計）
- Split/Force の方針に合わせたルート・DNS の整合
- 証明書の自動更新（期限切れで突然落ちるのを防ぐ）
Server Core 運用で効く “実務のコツ”
Server Core にする目的は、軽量化や攻撃面の縮小、保守性の向上であることが多いはずです。そのメリットを潰さずに運用するには、次の考え方が効きます。
- 踏み台（管理端末）を固定化：RRAS 管理ツール、証明書 MMC、イベントログ参照ができる端末を決める
- 変更は「スクリプト化」：役割追加、証明書更新、設定バックアップを PowerShell で残す
- 証明書更新の予定表を先に作る：切れる前に更新できる運用が最重要
- ログを追える状態を最初から作る：RRAS/NPS のログ採取場所、保管期間、調査手順を決める
状態確認でよく使うコマンド例
# RRAS サービス状態の確認
Get-Service RemoteAccess
# 主要なイベントログを確認（例）
Get-WinEvent -LogName "System" -MaxEvents 50 | Select-Object TimeCreated,Id,LevelDisplayName,Message
# ファイアウォール規則の確認（キーワード検索）
Get-NetFirewallRule | Where-Object {$*.DisplayName -like "*Remote*" -or $*.DisplayName -like "*RRAS*"}よくある “無理なのでは？” になるポイントと、切り分け表
Server Core＋Always On VPN の現場で発生しやすい「ハマりどころ」を、症状ベースで整理します。
| 症状 | まず疑うポイント | 確認の切り口 | 対処の方向性 |
|---|---|---|---|
| 管理端末から RRAS コンソールで接続できない | リモート管理/ファイアウォール/権限 | WinRM、管理共有、FW、管理者権限 | Server Core のリモート管理有効化、FW 例外の見直し |
| SSTP は繋がらないが 443 は開いている | 証明書不一致/秘密鍵なし/TLS | CN/SAN、証明書ストア、期限、鍵 | 正しいサーバー証明書を LocalMachine\My に投入 |
| IKEv2 が外部ネットワークで繋がらない | UDP 500/4500 が塞がれている | 拠点FW、ISP、ホテル/公衆 Wi-Fi | SSTP 併用、またはネットワーク要件を明確化 |
| EAP-TLS で認証が通らない | 証明書/CRL/NPS ポリシー | クライアント証明書、CA 信頼、CRL 到達性、NPS ログ | CRL 公開の見直し、テンプレート/EKU、ポリシー順序 |
| 一部ユーザーだけ失敗する | NPS 条件/グループ/証明書配布漏れ | グループ所属、証明書発行状況、ポリシー条件 | 対象グループ・テンプレート・自動登録の整合 |
「情報が少ない＝無理」と感じやすいのは、Server Core で GUI がなく、確認手段が途切れがちなためです。逆に言えば、ログの取り方と、リモート管理の導線さえ最初に作れば、GUI サーバーと同じように運用できます。
最小構成での検証ロードマップ（失敗しにくい進め方）
一気に“理想の Always On VPN”を作ろうとすると、どこで壊れたか分からなくなります。以下のように段階を分けると、Server Core でも安全に前進できます。
| 段階 | ゴール | やること | この段階で確認する観点 |
|---|---|---|---|
| Phase 1 | VPN サーバーとして疎通 | RRAS を入れて VPN を有効化 | 外部から到達できるか、アドレス割当、基本ルーティング |
| Phase 2 | 認証を整備 | 証明書（EAP-TLS）、NPS（必要なら） | 証明書配布、CRL 到達性、NPS ポリシー |
| Phase 3 | Always On の挙動を作る | VPN プロファイル配布、AlwaysOn/TND、DNS/ルート | 社内/社外での挙動差、切断復帰、名前解決 |
| Phase 4 | 要件拡張 | Device Tunnel、MFA、監視、冗長化 | 運用負荷、障害時の切り分け、更新手順 |
まとめ：Server Core でも Always On VPN は“作れる”、ただし“展開”が主役
- Server Core でも RRAS（VPN サーバー）は構築でき、Always On VPN の土台になる
- Always On VPN は「機能のインストール」ではなく、RRAS＋認証（NPS/証明書）＋クライアント配布の展開シナリオ
- Server Core は GUI 前提の手順が使えないため、リモート管理を前提に設計するとスムーズ
- 成功の鍵は 証明書（特に CRL 到達性）と、クライアントプロファイル（AlwaysOn/TND/DNS/ルート）の整合
「手順が見つからない＝できない」ではなく、「Server Core ではローカルで完結しない＝リモートで完結させる」へ発想を切り替えると、Always On VPN の構築は現実的な作業になります。まずは RRAS の疎通（Phase 1）を小さく作り、認証とクライアントを段階的に積み上げるところから始めてみてください。
コメント