組織内外を問わず柔軟に安全な接続を確立できるAlways On VPNは非常に便利ですが、DNSまわりの設定が適切でない場合、社内リソースへの名前解決がうまくいかずアクセスが滞ってしまいます。本記事では、Windows ServerでAlways On VPNを構築した際に起こりやすい「DNSサーバーの優先順位が逆になり、ドメインコントローラーのDNSが参照されない」問題を取り上げ、原因や具体的な解決策、トラブルシューティングのポイントを解説していきます。
Windows Server環境でのAlways On VPN構築概要
Windows Serverを利用してAlways On VPNを構築すると、リモートワーク時でもオンプレミスの社内リソースに簡単かつ安全にアクセスができます。従来のVPN接続と異なり、ユーザーがログオンしていない状態や端末が起動して間もない状態でも接続を確立できる点が魅力です。一方で、DNSサーバーの優先順位やDHCPオプション、IPv4アドレスプールの割り当て方法などをきちんと設定していない場合、クライアントが意図しないDNSサーバーを利用しようとしてしまうため、接続そのものは確立できてもドメイン名による社内リソースへのアクセスが失敗するケースがあります。
Always On VPNとは
Always On VPNは、Windows Server 2016以降とWindows 10以降(EnterpriseエディションやEducationエディションが中心)で利用できるVPN機能です。以下のような特徴があります。
- ユーザーがログインしていない状態でも、デバイスVPN機能を使えば接続が自動で行われる
- 従来のDirectAccessを置き換えるより柔軟なVPN実装
- ユーザー単位でのVPN構成とデバイス単位でのVPN構成を選択可能
- NPS(ネットワークポリシーサーバー)やRADIUS、Intuneなどと連携でき、セキュリティ強化や管理の効率化が図りやすい
よくあるDNSトラブルのポイント
Always On VPNで陥りやすいDNSトラブルには、次のようなものがあります。
- VPNクライアントに渡されるDNSサーバーの順序が正しくない
- Split Tunneling(スプリットトンネル)設定時に外部向けDNSを優先してしまい、社内DNSが参照されにくくなる
- IPv6対応を考慮しないまま運用しており、意図しないアドレス解決が行われる
今回は特に1つ目の「DNSサーバーの順序が逆転する」問題にフォーカスして解説を進めます。
DNSサーバー情報が逆に渡される問題
Windows ServerのVPN機能を利用する中で、クライアント側が受け取るDNSサーバーの情報が逆転してしまうケースがあります。具体的には「192.168.1.1」が先頭に割り当てられ、本来優先すべき社内DNS(例えば192.168.1.200)が2番目や3番目に設定される状況です。
問題の背景と症状
- DHCPが自動的に割り当てるDNSサーバー設定で、インターネット向けルーターやISPのDNSアドレスが先頭に来てしまう
- Always On VPN接続が確立されていても、優先DNSサーバーが外部向けDNSの場合、社内のドメインコントローラーが正しく引けずアクセス失敗
- クライアントユーザーが「社内リソースへ接続できない」「ドメイン名の解決ができない」といったトラブルを訴える
実際のところ、WindowsのVPNクライアントは複数のDNSサーバー情報を同時に保持できますが、最初に登録されたDNSサーバーが優先される傾向にあります。そのため、運用者が意図しない順序でDNSサーバー情報が振り分けられると、ドメイン名解決が一貫性を欠き、安定したアクセスが行えません。
原因の考察
代表的な原因としては以下が考えられます。
- RASサーバー側のIPv4アドレス割り当てがDHCP Relayに委ねられている
- Windows Serverのリモートアクセスサービス(RAS)で「DHCPからの自動割り当て」を利用する場合、DHCPサーバーの設定やスコープオプションによってDNSサーバーの順序が制御される
- DHCPのオプション設定が意図せず上書きしている
- DHCP Option 6(DNS Servers)の値に外部DNSが先頭に記載されている、または他のオプションでクライアントに優先度を上書きする情報が流れている
- サードパーティのセキュリティソフトやネットワーク管理ソフトとの干渉
- ごくまれですが、ウイルス対策ソフトやVPNクライアントアプリが独自にDNS設定を変更する場合がある
解決策と推奨アプローチ
この問題を根本的に解決するには、RASサーバー側でのIPv4アドレス割り当て方法を「DHCPからの自動取得」ではなく、「スタティックプール(固定プール)」に切り替えるのが有効です。加えてDHCPサーバー側では、この固定プールに対しDNS関連の情報が正しく適用されるような予約(Reservation)やスコープオプションの特例を設定します。
固定プールの設定手順
大まかな流れとしては以下のステップになります。
Step1: RASのIPv4アドレス割り当てを固定に設定
- 「Routing and Remote Access」(RRAS)コンソールを開く
- 「サーバー マネージャー」→「ツール」→「Routing and Remote Access」からRRAS管理画面を起動
- サーバーのプロパティを開く
- RRASのサーバー名を右クリックし、「プロパティ」を選択
- IPv4タブで「スタティックアドレスプール」を選択
- 「DHCPからアドレスを割り当てる」ではなく「スタティックアドレスプール」をチェックし、希望するアドレス範囲を登録
- 例:192.168.10.1〜192.168.10.50をVPNクライアント用アドレスとして割り当てたい場合は、同範囲を入力
- 設定を保存し、RRASサービスを再起動
この作業によって、VPNクライアントに付与されるIPアドレスはRRASで指定した範囲内から払い出されるようになります。
Step2: DHCP側でのスコープ設定・Reservation
- DHCPマネージャーを開く
- 「サーバー マネージャー」→「ツール」→「DHCP」でDHCP管理コンソールを起動
- スタティックプールの範囲に対するReservationやオプションを設定
- 基本的にはRASサーバー側でIPを割り当てるため、DHCP側ではこのアドレス範囲を排除しておくか、Reservationを設けて競合しないようにする
- もしVPNクライアントがDHCPからDNSやDefault Gateway情報を受け取る必要がある場合は、Option 6(DNS Servers)などを正しく構成し、社内DNSサーバーアドレスを優先的に記述
- DNSの優先順位を社内DNSに指定
- DHCPオプションに複数のDNSサーバーアドレスを載せる際、必ず先頭に社内DNS(例:192.168.1.200)、次に外部DNS(例:8.8.8.8など)を設定
これにより、VPN接続時のクライアントはRRASで設定されたスタティックプールからIPアドレスを取得し、同時にDHCPオプション(もしくはRASサーバー側の指定)に従って正しいDNSサーバーの順序を参照するようになります。
DNS優先順位設定の確認方法
作業後は、VPNクライアント端末で以下の手順を行い、DNSサーバーが正しく設定されているか確認します。
ipconfig /all
VPNアダプターに割り当てられているIPv4アドレスがスタティックプールの範囲内かつ、DNSサーバー欄の先頭に社内DNSが表示されていれば成功です。さらに必要に応じて、
ipconfig /flushdns
コマンドでDNSキャッシュをクリアし、実際に名前解決ができるかテストします。
事前チェックリスト
- VPN接続の種類
- Always On VPNのデバイストンネル、ユーザートンネル、IKEv2/IPsecなど使用するトンネル種類を確認
- ドメインコントローラーのバージョン
- Windows Server 2012や2016、2019などバージョンによってDHCP・DNSの動作が微妙に異なる場合がある
- ネットワークアダプター(物理/仮想)の構成
- NICチーミングやHyper-V上の仮想スイッチが絡むと、DHCPリレーの設定が複雑になりやすい
- 既存クライアントの動作確認
- 一部クライアントのみ不具合が発生しているのか、すべてのクライアントで共通なのかを切り分け
具体的な設定例と補足
ここでは、より具体的な例を示しながら設定手順を補足します。
PowerShellを使った構成例
Routing and Remote Access(RRAS)をPowerShellで制御する場合、以下のようなコマンドを利用可能です。
- RRASサーバーのインストール
Install-WindowsFeature -Name RemoteAccess -IncludeManagementTools
Install-WindowsFeature -Name RSAT-RemoteAccess-Powershell
- RRASの設定開始
# サービス開始
Install-RemoteAccess -VpnType RoutingAndRemoteAccess
- IPv4アドレスのスタティックプールを設定
# 例:192.168.10.1~192.168.10.50をVPNクライアント向けに設定
Set-RemoteAccess -IPAddressRangeStart 192.168.10.1 -IPAddressRangeEnd 192.168.10.50
- DNSサーバー情報の設定例
RRAS単体でDNSオプションを指定する場合、次のようなコマンドが利用できます(バージョンによっては設定項目が異なるので注意)。
Set-VpnAuthProtocol -UserNameAuthProtocols PAP,MSCHAPv2 -PassThru
# DNSの優先サーバーとして192.168.1.200を指定する場合
Set-DnsClientServerAddress -InterfaceAlias "VPN アダプターの名前" -ServerAddresses 192.168.1.200,8.8.8.8
ただし、Always On VPNのプロファイルを構成ファイルで配布している場合、XML設定ファイルの中にDNSサーバー情報を記述して配布する方法が一般的です。
グループポリシーによる設定管理
ドメイン参加済みのクライアントに対しては、グループポリシーを活用することでDNSサフィックスや名前解決ポリシーを集中管理できます。例えば、GPOの「コンピュータの構成」→「ポリシー」→「ネットワーク」→「DNSクライアント」あたりで社内DNSサフィックスを優先的に使うよう指定しておくと、VPN環境でもスムーズに内部リソースの名前解決が行えます。
- 特定のDNSサフィックス(例:corp.example.local)を常に社内DNSで解決
- Windows 10以降では「Name Resolution Policy Table (NRPT)」を使ってドメイン別にDNSサーバーを振り分けることも可能
よくある質問とトラブルシューティング
実運用においては、単にDNSサーバーの設定を整えても想定外の問題が発生するケースがあります。ここでは、よくある質問や対処法をいくつかまとめます。
クライアント側でのDNSキャッシュクリア
VPNクライアントがDNS設定を受け取っているはずなのに名前解決がうまくいかない場合は、DNSキャッシュが古い情報を保持している可能性があります。ipconfig /flushdns
でキャッシュをクリアし、再度名前解決を試すと問題が解決する場合があります。また、クライアントOSがWindows 10/11などの場合、再起動やネットワークアダプターの無効・有効切り替えで設定を再読み込みできることがあります。
複数VPNクライアントが混在する場合の対策
組織によっては、Always On VPNクライアントだけでなく、他社製のVPNクライアントが混在していたり、拠点間VPNが存在していたりと、ネットワークが複雑化している場合もあります。このような環境下では、下記のような対策が必要です。
- それぞれのVPNクライアントが使用するアドレス範囲(プール)を明確に分ける
- DHCPで別々のスコープを設定し、DNSサーバー情報をコンフリクトさせないようにする
- ポリシーベースのルーティングや名前解決ルールをドキュメント化し、運用者全員が把握できるようにする
旧バージョンのWindows ServerやDCの混在
ドメインコントローラーがWindows Server 2012、VPNサーバーが2019など異なるバージョンが共存している場合でも、基本的な解決策は変わりません。ただし、DHCPサーバーが古いバージョンだと、GUIでは設定項目が少ない可能性があります。必要に応じてPowerShellコマンドやレジストリエディタで直接オプションを追加・変更するケースもあるため、技術文書や公式ドキュメントを参照しながら作業を進めるようにしましょう。
まとめ
Always On VPNを導入すると、リモート環境でもシームレスに社内リソースへアクセスできる利便性が得られます。一方で、DNSサーバーの優先順位が誤って割り当てられると、ドメイン名によるアクセスがうまくいかず、運用面での混乱を引き起こします。こうした問題を防ぐためには、RASサーバー(RRAS)のIPv4アドレス割り当てをスタティックプールに切り替え、DHCPオプションの設定を正しく行うのが有効です。また、グループポリシーやName Resolution Policy Table(NRPT)を活用すれば、大規模環境でも集中管理しやすくなります。
運用開始時だけでなく、新規クライアントやユーザーが追加されるタイミングで改めてDNSの設定や優先順位をチェックすることで、不要なトラブルを未然に防ぐことができます。最終的には「クライアントが常に社内DNSサーバーを正しく参照できる状態」を維持し、リモートアクセスの利便性とセキュリティを両立させることが重要です。
コメント