企業でのリモートワークが増える中、VPNの導入を検討する方は多いでしょう。しかし、Windows Server 2022上のRRASを用いたVPN接続で、ドメイン参加がうまくいかないトラブルに直面するケースがあります。ここでは、原因の洗い出しから具体的な設定例までを分かりやすく解説します。
RRASを用いたVPNのメリットと課題
企業が社内リソースへの安全なアクセスを確保するために、VPNはもはや欠かせない存在になりました。RRAS（Routing and Remote Access Service）はWindows Serverの機能として提供され、ユーザーが簡単にVPNサーバーをセットアップできるメリットがあります。しかし、RRAS経由でドメイン参加を行おうとすると、DNS解決やルーティング、ファイアウォールなど複数の要因が絡み合い、問題が発生することがあります。
RRASとは
RRASはMicrosoft Windows Serverに搭載されている機能で、以下のような役割を担います。
- VPNサーバーの構築（PPTP、L2TP、SSTPなど各種プロトコルに対応）
- LANやWAN間のルーティング
- NAT（ネットワークアドレス変換）やリモートアクセスの管理
RRASを利用すれば、Windows ServerをVPNサーバーとして立て、外部から社内ネットワークへアクセスする仕組みを比較的スムーズに整備できます。
しかし、一部の設定を見落とすと「VPN接続はできるがドメイン コントローラーが見つからない」といった問題に直面することがあります。
VPNクライアントがドメインに参加できない理由
RRAS経由でVPN接続をすると、クライアントPCには“PPPアダプタ”と呼ばれる仮想ネットワークインターフェイスが割り当てられます。このPPPアダプタを介して社内ネットワークと通信しますが、以下のような設定の不備があるとドメインに参加できません。
- DNSサーバーのIPアドレスが正しく設定されていない
- VPNトンネル経由で必要な名前解決やポートが遮断されている
- 静的ルートの不足や誤ったゲートウェイ設定によってドメイン コントローラーへ到達できない
- ファイアウォールの設定でKerberosやLDAPなどドメイン参加に必須のポートが閉じている
DNS設定の見直しが最重要
ドメイン参加時に最も重要となるのがDNSの設定です。ドメイン コントローラーに到達する以前の段階で、クライアントはドメイン名を解決して正しいIPアドレスを取得しなければなりません。
DNSサーバーの指定
VPNクライアントのPPPアダプタが取得するDNSサーバーとして、必ずドメインを管理しているDNSサーバー（通常はドメイン コントローラーと同じマシン）を指定してください。RRASの構成では、以下の2パターンがあります。
- DHCPリレーエージェント等を設定し、DHCPサーバーからDNS設定を自動的に配布するパターン
- RRASサーバーの「IPv4 アドレスの割り当て」の静的アドレスプール機能を使い、RRASのプロパティでDNSサーバーを手動設定するパターン
いずれの方法でも、「VPNクライアントにはドメイン管理DNSサーバーのIPが割り当てられること」が最重要です。もし「8.8.8.8（Google DNS）」などのインターネット向けDNSサーバーを指定していると、社内ドメイン名の解決に失敗します。
nslookupによる検証
VPNクライアントで接続後に、以下のようにnslookupコマンドを実行してみてください。
nslookup <ドメイン名>正しくドメイン コントローラーのホスト名やIPアドレスが返ってくればDNS設定に問題がない可能性が高いです。しかしエラーになったり、外部DNSのアドレスが返る場合は設定ミスを疑う必要があります。DNSが解決できない限り、ドメイン参加は成功しません。
RRAS側での転送とサブネット設計
VPN接続をスムーズに行うには、RRASサーバー側のルーティングやアドレス プールの設計も見逃せません。クライアントが255.255.255.255のサブネットマスクを受け取っている場合でも、適切なルーティングが設定されていれば問題なく通信できますが、場合によっては追加の静的ルートが必要になります。
IPv4の転送とブロードキャスト名解決
RRASの管理画面にある「IPv4の一般設定」や「IPv4 ルーティングとリモートアクセス」の項目で、パケット転送が有効になっているか確認してください。加えて、NetBIOS名解決などが必要な場面では、「ブロードキャストの名前解決を有効にする」にチェックを入れることで、一部の古いアプリケーションなどが機能する場合があります。
アドレス割り当ての確認
RRASの構成ウィザードを使ってVPNを設定した場合、デフォルトで「DHCPサーバーから割り当て」になっていることがあります。しかし、DHCPサーバーが存在しない環境や、DHCPリース範囲に余裕がない場合には「静的アドレスプール」を指定します。
静的アドレスプールを設定する場合のポイントは以下のとおりです。
| 項目 | 設定例 | 説明 |
|---|---|---|
| アドレス範囲開始 | 192.168.10.100 | VPNクライアントに割り当てる開始IPアドレス |
| アドレス範囲終了 | 192.168.10.200 | VPNクライアントに割り当てる終了IPアドレス |
| サブネットマスク | 255.255.255.0 | クライアント側のVPNインターフェイスのサブネットマスク |
| DNSサーバー | 192.168.10.10 | ドメイン コントローラー兼DNSサーバーのIPアドレス |
| WINS | 必要に応じて設定 | NetBIOS名解決が必要な場合 |
これによりクライアントがVPN接続した際、「192.168.10.100～200」内のIPと「255.255.255.0」のマスク、そして「192.168.10.10」のDNSサーバーを取得するようになります。
静的ルートの設定とルーティングの確認
VPNクライアントがドメイン コントローラーへ到達できない原因の一つとして、ルーティングの不備があります。例えば、ドメイン コントローラーがRRASサーバーと異なるサブネット上にある場合、RRASサーバー自身に静的ルートを設定するか、あるいはコアスイッチやルータにルートを追加しなければ通信が片方向で止まる可能性があります。
クライアント側のルート追加
Windowsクライアント側で「既定のゲートウェイをリモートネットワークに使用する」にチェックを入れている場合、基本的に社内ネットワーク宛の通信はVPN経由になります。しかし、セキュリティポリシーで「スプリットトンネル」を構成している場合は、ドメイン コントローラー宛の通信を明示的にVPN側へ回すルートを追加する必要があるかもしれません。
例として、手動でルートを追加する場合は以下のようにroute addコマンドを使用します。
route add 192.168.10.0 mask 255.255.255.0 192.168.10.1 -pここで「192.168.10.0/24」は社内ネットワーク、「192.168.10.1」はVPN側のゲートウェイを指します。環境に合わせて調整してください。
RRASサーバー側の静的ルート設定
ドメイン コントローラーが別のサブネット（例：192.168.20.0/24）にあるとき、RRASサーバーに静的ルートを追加しておかないと、クライアントからの通信が正しく転送されません。RRASの管理コンソールで「IPv4 → 静的ルート」を開き、必要な経路情報を追加しておきます。
また、ドメイン コントローラーからクライアント側へ戻る返信ルートも必要です。多くの場合、ドメイン コントローラーや既存ルータの静的ルートか、もしくはデフォルトゲートウェイ設定を確認し、「返りパケット」がRRASサーバーへ戻るようにします。
ファイアウォールと使用ポートのチェック
VPN接続そのものは確立していても、ドメインに参加するための通信がファイアウォールでブロックされている可能性もあります。ドメイン参加には以下の主要ポートが必要です。
| ポート | プロトコル | 用途 |
|---|---|---|
| 53 | UDP/TCP | DNS (名前解決) |
| 88 | UDP/TCP | Kerberos 認証 |
| 389 | TCP/UDP | LDAP (ディレクトリ) |
| 445 | TCP | SMB (ファイル共有) |
| 135 | TCP | RPC (Remote Procedure Call) |
これらのポートがクライアントとドメイン コントローラー間で通っていなければなりません。特にVPN経由の場合、オンプレミスのファイアウォールやWindows ServerのWindows Defender ファイアウォールの「受信規則」に着目することが重要です。netsh advfirewall firewallコマンドを用いて規則を確認したり、「Windows Defender ファイアウォールの詳細設定」画面から必要な規則が有効かをチェックしてください。
グループポリシー適用の影響
会社のポリシーでGPO（グループポリシーオブジェクト）を利用して厳密なファイアウォールルールを適用している場合、VPN利用時のトラフィックを許可する設定が不足している可能性があります。特定のサブネット間通信やKerberos認証に関わるポートに対して、適切な許可ルールを追加することで問題が解消します。
VPNクライアント設定を最適化する
RRASサーバー側の設定が正しくても、クライアントPCのVPN接続設定が不十分だとドメイン コントローラーに接続できません。特に以下の項目を確認しましょう。
「既定のゲートウェイをリモートネットワークに使用する」設定
VPN接続のプロパティから「IPv4 のプロパティ」を開き、「詳細設定」ボタンをクリックすると表示されるオプションです。これを有効にしておくと、クライアントはVPN側を優先して社内ネットワークを探しに行きます。スプリットトンネルを採用している場合は、別途ルート追加が必要になるため注意が必要です。
DNSサフィックスとDNSサーバーの確認
VPNアダプタに割り当てられるDNSサフィックス（例えば「corp.local」など）が正しく設定されているかを確認してください。Windows 10 Proのネットワーク接続詳細情報を見ると、以下のように表示されます。
接続特性： PPP アダプタ
DNSサフィックス： corp.local
IPv4 アドレス： 192.168.10.101
サブネットマスク： 255.255.255.255
DNSサーバー： 192.168.10.10もしここが空欄だったり、DNSサーバーが外部のアドレスになっている場合はRRASかDHCPの構成を見直す必要があります。
ドメイン参加に必要な権限とイベントログの監視
物理的にドメイン コントローラーへ到達でき、DNS名前解決も問題ないのにドメイン参加エラーが出る場合は、権限や認証周りのトラブルが考えられます。
ドメイン参加に必要な権限
通常、「Domain Admin」ロール、あるいは「ドメインへコンピューターを追加する権限」があるユーザーアカウントを使ってドメイン参加を行います。万が一権限が不足していると、「ドメイン コントローラーが見つかりません」あるいは「アクセスが拒否されました」のエラーが出る可能性があります。
運用方針によってはオーガニゼーションユニット（OU）やコンピューターアカウントを事前に作成しておくこともありますが、いずれにせよドメイン参加を行う権限が正しく設定されているかを確認してください。
イベントビューアでのトラブルシューティング
クライアントPC、RRASサーバー、ドメイン コントローラーのそれぞれのイベントビューア（特に「Windows ログ → システム」「アプリケーションとサービス ログ → Microsoft → Windows → DNS-Client」「Directory Services ログ」など）を確認すると、DNSエラーや認証エラーの詳細が記録されている場合があります。
例えば、下記のようなイベントが見つかるかもしれません。
- Event ID 1055：Group PolicyのDNS名解決エラー
- Event ID 5719：NETLOGONサーバーへの接続エラー
- Event ID 40960：LsaSrv (セキュリティパッケージ) の失敗
これらのログが出ている場合は、DNSやNetlogon、Kerberos認証周りの設定を一段深く調べる必要があります。
まとめ
RRASを使ったVPNでドメイン参加できない問題は、多くの場合DNS設定の不備が根本原因となります。加えて、静的ルートの設定漏れやファイアウォールポートの未開放、クライアント側のVPN設定の不備など複合的に要因が絡み合います。
以下のポイントを押さえることで、トラブルシュートが格段にスムーズになります。
- VPNクライアントが正しいDNSサーバーを取得しているか
- RRASサーバーやルーターに必要な静的ルートが設定されているか
- ドメイン参加に必須なポートやプロトコルがファイアウォールで許可されているか
- クライアント側の権限やドメイン参加手順が正しいか
- イベントビューアのログを確認し、原因を特定する
こうした手順を踏むことで、VPN経由のドメイン参加は円滑に行えるはずです。特にDNS周りとルーティングの設定をしっかり押さえることが、問題解決の鍵となります。
社内のネットワーク設計やセキュリティポリシーに合わせて設定を見直し、トラブルなくリモートワークを続けられるよう最適化していきましょう。
コメント