Windows Server 2019で構築したVPNがインターネットに繋がらない時の解決策まとめ

リモートワークや外出先からの社内リソースアクセスで大活躍するのがVPN。ところが、いざWindows Server 2019でリモートアクセスサーバーを構築してみたら、インターネットに接続できないトラブルに頭を抱えるケースも少なくありません。そこで今回は、VPN経由でのアクセスに失敗する原因とその対処法を詳しく解説します。

リモートアクセスサーバーの基本構成を再確認

Windows Server 2019には「Routing and Remote Access(RRAS)」という機能が含まれており、VPNサーバーとして利用できます。ドメインコントローラー(以下、DC)を同じサーバーで兼任させる構成も可能ですが、ネットワーク設定を誤ると外部通信ができなくなりがちです。ここでは、まずVPNサーバーの基本構成をしっかり理解しておきましょう。

ドメインコントローラーとVPNサーバーの同居はアリ?

会社規模が小さい場合や限られたサーバー台数で運用している現場では、DCとVPNサーバーを同居させるケースがよくあります。もちろんセットアップ自体は可能ですが、下記のようなメリット・デメリットを把握しておく必要があります。

メリットとデメリット

  • メリット:サーバー台数が少なく済むためコストが削減できる。Windows Serverのライセンス数やハードウェアも最小限で済み、管理も一元化しやすい。
  • デメリット:ネットワーク負荷や障害発生時の影響が大きい。VPN機能の設定ミスが、ドメイン全体の認証機構にまで悪影響を及ぼすリスクがある。

このように、運用上の簡便さの一方で、セットアップや運用を慎重に行わないと大きなトラブルにつながりかねません。特にリモートアクセスにおいては、NATやルーティング周りの設定ミスがインターネット接続不良を引き起こすことが多いです。

問題の症状と主な原因

VPNサーバーに接続できるのに、社内リソースにもインターネットにもアクセスできない場合、下記のような要素が絡んでいる可能性があります。

1. 社内リソースへ接続できない

VPNトンネル自体は確立しているものの、ドライブマッピング(ネットワークドライブ)やSQLサーバー、ファイルサーバーなど社内ネットワーク内のサービスに接続できないケースです。これはルーティング設定やファイアウォールの設定に起因することが多く、VPNクライアントのIPアドレス帯が正しく許可されていない、または社内のDNS解決がうまく機能していないなど、複数の要因が考えられます。

2. インターネットにアクセスできない

「VPNに接続するとインターネットが使えなくなる」という状況です。原因としては、すべてのトラフィックがVPN経由になっている場合にサーバー側でNATが有効になっていなかったり、Split Tunnelingを無効にしているのにゲートウェイが設定されていなかったりするパターンが代表的です。特に、社内DNSサーバーしか引けない状態だと、外部サイトの名前解決に失敗し、ブラウザでインターネットサイトを表示できない場合もあります。

3. メール送信ができない

SMTP(25番ポート)やサブミッションポート(587番など)を利用したメール送信がVPN経由になり、外部への通信が通らないケースです。ファイアウォールやISP側の制限なども絡む可能性があり、VPNサーバーのNATルールでSMTPやサブミッション用ポートを開放していない場合も原因になります。

Split Tunnelingとフルトンネルの違いを理解する

VPNの運用方法として、Split Tunneling(分割トンネル)とフルトンネル(全トラフィックをVPN経由)の2種類があります。どちらを採用するかによって設定内容が変わるため、まずは基本的な考え方をおさらいしましょう。

Split Tunneling

VPNクライアントが、社内リソース向けの通信だけをVPNに送り、それ以外(インターネットアクセス)は自宅や外出先のネットワークを直接利用する方式です。クライアントPCの「VPN接続のプロパティ」から「リモートネットワーク上のデフォルトゲートウェイを使用する」のチェックを外すことで有効化できます。

  • 利点:インターネットアクセスがクライアント独自の回線を使うため、サーバー側の帯域負荷を軽減できる。
  • 注意点:社内環境と外部サイトを行き来するときに、DNS設定の不備などで名前解決がうまくいかない場合がある。また、社内と外部の通信が混在するためセキュリティポリシーを慎重に設計する必要がある。

フルトンネル

クライアントのすべての通信をVPNサーバーを経由して行う方式です。「リモートネットワーク上のデフォルトゲートウェイを使用する」にチェックが入った状態です。

  • 利点:クライアントが社内ネットワークに完全に入った状態になるため、一元的なセキュリティポリシーや監視、フィルタリングを適用しやすい。
  • 注意点:インターネットアクセスまでVPN経由になるため、帯域を圧迫しやすい。NATやDNSの設定が正しくないと外部サイトに一切アクセスできないリスクが高い。

NAT設定の確認

フルトンネルで運用する場合、VPNサーバー側でNAT機能を設定しないと、クライアントから外部インターネットへ通信が行えません。Windows Server 2019のRRASでは、以下の手順でNATを有効化できます。

RRASコンソールでのNAT設定手順

  1. サーバーマネージャーを開き、「ツール」から「Routing and Remote Access」をクリック。
  2. 左ペインでサーバー名を右クリックし、「構成と有効化ウィザード」を開く(既にRRASを有効にしている場合は「プロパティ」から確認)。
  3. 「NATを使用したインターネット接続」を選択し、インターネット接続のアダプターを指定。
  4. VPN用のLANインターフェースは「内向き」のインターフェースとして設定。
  5. ウィザードが完了したら、[IPv4]→[NAT]を展開し、インターネット接続のインターフェースで「NAT有効」を確認する。

上記設定を誤ると、クライアントはVPNサーバーを経由して外部サイトに向かうトラフィックの出口がなくなり、インターネット接続に失敗する原因となります。

DNS設定の見直し

VPNを通して社内DNSにクライアントを参照させている場合、外部サイトへの名前解決は通常、社内DNSサーバーのフォワーダー設定に委ねられます。フォワーダーが適切に設定されていない場合、外部サイトのホスト名が解決できず「サーバーが見つかりません」エラーが発生します。

DNSフォワーダーの設定例

Windows DNSサーバーのDNSマネージメントコンソールから行います。

  1. DNSマネージャーを開き、該当DNSサーバーを右クリックして「プロパティ」を選択。
  2. 「フォワーダー」タブを開き、「転送先」に外部のDNSサーバー(例: 8.8.8.8、1.1.1.1など)を設定。
  3. 「OK」ボタンで設定を確定し、DNSサーバーサービスを再起動する。

これにより、社内DNSが解決できない外部ドメインに対しては、指定した外部DNSへ問合せが転送されるようになります。

ファイアウォール設定とポート開放

VPNクライアントからの通信を受け入れるためには、以下のようなポートが関係します。さらに、VPN接続後の通信が適切に通るよう、必要ポートを開放しておくことが重要です。

プロトコル/ポート用途備考
TCP 443SSTP (SSL VPN)HTTPS経由でVPNトラフィックをトンネル
UDP 500, 4500IKEv2/IPsecモバイル環境や最新VPNプロトコルで使用
TCP 1723PPTP古い方式だが簡単に構築しやすい
GRE (プロトコル番号47)PPTPデータ通信PPTP利用時はGREも許可が必要
TCP 25SMTPメール送信をサーバー側で受け流す場合
TCP 587サブミッションポート外部SMTPサーバー利用時も解放が必要な場合あり

もしリモートアクセスサーバーと境界ファイアウォールが別機器になっている場合は、上記のプロトコル/ポートをファイアウォールでも許可しなければなりません。さらに、クライアントからの応答をサーバーへ正しく戻すためのルールが構成されていることも確認しましょう。

VPNクライアント側の設定を点検

クライアントがWindows PCの場合、「VPN接続のプロパティ」や「ネットワーク アダプターの設定」を細かくチェックすることも忘れないでください。

IPv4プロパティでゲートウェイ設定を確認

VPN接続に用いる「IPv4のプロパティ」から、「詳細設定」に進むと「リモートネットワーク上のデフォルトゲートウェイを使用する」のチェックが見つかります。フルトンネル運用かSplit Tunneling運用かに合わせて、正しく設定しましょう。

ルートテーブルの確認

クライアントPC上でコマンドプロンプトを開き、「route print」を入力すると現在のルーティングテーブルが表示されます。VPN接続時に、適切なデフォルトルートや社内リソース向けの経路が追加されているか確認することで、問題の切り分けに役立ちます。

C:\> route print

===========================================================================
Interface List
  10 ...00 xx xx xx xx xx ...... Intel(R) Ethernet Connection
  11 ...00 xx xx xx xx xx ...... Wi-Fi
  15 ...00 xx xx xx xx xx ...... VPN Connection
===========================================================================
(以下略)

ここで、VPNインターフェース(例: Interface Listで15番に割り当てられている)に対してデフォルトゲートウェイが設定されているか、あるいは目的の社内サブネットへのルートが存在するかなどをチェックします。

アクセス制御リスト(ACL)やファイル共有設定

VPN経由で社内のファイル共有やデータベース(例: SQL Server)にアクセスできない場合、ネットワークやサーバーアプリケーションのアクセス制御が「VPNクライアントからのサブネットを許可していない」ケースも考えられます。特にファイル共有では、サーバーマネージャー内の「共有と記憶域の管理」で共有フォルダーのアクセス権や、Windows Firewallの「ファイルとプリンターの共有」が正しく設定されているか見直しましょう。

ログとトラブルシューティングツールを活用

問題が長引く場合は、Event Viewer(イベントビューア)やRRASのログを参照し、どの段階でエラーが発生しているかを確認するのがおすすめです。以下にトラブルシューティングに役立つ例を挙げます。

Event Viewerの確認

  1. 「サーバーマネージャー」から「ツール」→「イベントビューア」を開く。
  2. 「Windowsログ」や「アプリケーションとサービス ログ」でRRAS関連の警告やエラーが出ていないか確認。
  3. VPNクライアント側(Windows 10/11など)でも同様にイベントビューアを確認し、VPN接続に関連するエラーがないかチェック。

pingやtracertによる通信経路の追跡

コマンドプロンプトで特定のホストに対してpingを行い、応答が返ってくるかを調べます。応答がない場合は、ファイアウォールまたはネットワーク上でパケットがブロックされている可能性があります。次に「tracert <ホスト名 or IP>」で通信経路をたどり、どの段階でタイムアウトするかを見れば、どの区間に問題があるかを特定しやすいです。

具体的な解決策の例

ここまで述べてきたポイントを踏まえて、実際に問題を解消するための具体策をまとめます。

1. Windows FirewallとRRASの設定を再確認

netsh advfirewall firewall add rule name="Allow PPTP" dir=in protocol=TCP localport=1723 action=allow
netsh advfirewall firewall add rule name="Allow GRE" dir=in protocol=GRE action=allow
netsh advfirewall firewall add rule name="Allow IKEv2(500)" dir=in protocol=UDP localport=500 action=allow
netsh advfirewall firewall add rule name="Allow IKEv2(4500)" dir=in protocol=UDP localport=4500 action=allow

例えば上記のように、必要なVPNプロトコルやポートをWindows Firewallで許可するコマンドを実行します。また、RRASの「IPv4」設定でNATインターフェースが正しくインターネット側アダプタに割り当てられているかチェックしてください。

2. DNSフォワーダーの設定検証

社内DNSサーバーの「フォワーダー」を正しく設定し、外部DNS(例えば8.8.8.8)へ問い合わせが転送されるようになっているかを「nslookup」コマンドで検証します。

nslookup www.google.com

結果が返ってこない場合、DNSサーバー側の設定を再度見直す必要があります。

3. ルーティングテーブルの手動追加

Split Tunneling環境で、特定の社内サブネット(例: 192.168.10.0/24)にトラフィックを送るルートがない場合、クライアントで手動追加する方法もあります。

route add 192.168.10.0 mask 255.255.255.0 192.168.20.1

ここで「192.168.20.1」はVPNインターフェースのゲートウェイアドレスを指します。永続化したい場合は「-p」オプションを付け加えます。

4. ファイル共有・SQLサーバーのACL確認

社内のWindowsファイルサーバーやSQLサーバーで、VPNクライアントが取得するIPアドレス帯をアクセス元として許可しているか再点検します。共有フォルダのプロパティやSQLサーバーの「SQL Server Configuration Manager」を開き、外部ネットワークのサブネットからの接続を拒否していないか見直しましょう。

運用のポイントとベストプラクティス

1. 小規模な環境でも、役割分散を検討する

DCとVPNサーバーを同居させている環境では、問題が発生するとドメイン認証にも支障をきたします。可能であれば役割を分散し、VPNサーバーを専用に運用することでトラブルシューティングも簡単になります。

2. 監視とログ収集の習慣化

VPNサーバーの稼働状態やクライアント接続状況を、定期的に監視ツール(例: PRTG、Zabbixなど)で可視化する習慣をつけましょう。問題の予兆を早期に察知し、障害発生時にも原因の絞り込みがスムーズになります。

3. セキュリティアップデートとパッチ適用

VPNトンネルが通っていれば外部からの不正アクセスリスクも高まるため、Windows Serverのセキュリティ更新プログラムは欠かさず適用する必要があります。OSや関連サービスの脆弱性を放置すると、VPN経由で社内ネットワーク全体が危険にさらされます。

まとめ

Windows Server 2019で構築したリモートアクセスサーバー(VPN)からインターネットに接続できない場合の主な対処ポイントとしては、NATとDNSの設定、ファイアウォールのポート開放、そしてVPNクライアント側のルート設定などが挙げられます。特に、フルトンネルを利用する場合はサーバー側でNATを正しく設定することが必須であり、Split Tunnelingの場合はクライアントのルーティングを意識的に管理しなければなりません。

また、VPN接続後に社内リソースにアクセスできない場合、アクセス制御リストやファイル共有の設定ミスが潜んでいる可能性もあります。複数の要因が絡み合うので、pingやtracert、イベントビューアなどを活用しながら、段階的に切り分けを行うと解決までの道筋が見えやすくなるでしょう。

しっかりとした構成管理と継続的な監視によって、VPN環境は安定的に稼働します。セキュリティと利便性を両立させるためにも、サーバーとクライアントの設定を総合的に見直して、トラブルに強いVPN環境を整えましょう。

コメント

コメントする