この記事で分かること
VPN接続が成功しているにもかかわらず、社内のサーバやプリンタなどのリソースにアクセスできない場合、その原因はVPNトンネルの確立だけでなく、ルーティング設定やファイアウォールのセキュリティポリシーに起因することが多いです。本記事では、問題を切り分けるための具体的な手順を詳細に解説し、読者が現場で自力で原因を特定しやすくなるように整理しています。また、ありがちな失敗例や注意点も含めて紹介し、全ての確認観点が網羅されています。
1. VPN接続成功の意味と限界を理解する
まず最初に認識すべきは、VPN接続成功＝社内リソースへアクセス可能ではないという点です。VPN接続成功は、端末とVPNゲートウェイ間で暗号化トンネルが正しく確立されたことを示しますが、トンネル内を通るパケットのルーティングや社内ネットワークでのアクセス許可は別の問題です。
具体的には、まずVPN接続で割り当てられたIPアドレスを確認し、そのIPアドレスが社内ネットワークの許可対象範囲に含まれているかを確かめましょう。
Windowsの場合は ipconfig、Linux/Macなら ifconfig や ip addr コマンドが便利です。
注意点：VPNクライアントで割り当てられたIPが「プライベートIPアドレスの範囲内か」「アクセス先ネットワークのサブネットと矛盾していないか」を確認し、異常があればVPN側のIPプール設定に問題がある可能性があります。
2. ルーティング設定の詳細確認と切り分け手順
VPNトンネルは確立されても、ルーティング設定が適切でなければ社内リソースへパケットが届きません。ルーティング経路の確認はクライアント端末、VPNゲートウェイ双方で必須です。
2-1. クライアント端末のルーティングテーブル確認
- Windows：
route print - Linux/Mac：
netstat -rnまたはip route show
ここでは、アクセスしたい社内リソースのサブネットがVPNインターフェース向きのルートとして存在しているかを確認します。例えば社内リソースが 192.168.10.0/24 なら、その宛先へのルートがVPNのトンネルインターフェース（例: tun0など）へ向かっているかを見ます。
ありがちな失敗例：・ルートが無くデフォルトゲートウェイで送信してしまい、パケットが社内に届かない・VPN接続時に分割トンネルが正しく設定されておらず、アクセス先のルートがVPNトンネル外にある
2-2. VPNゲートウェイのルーティング設定確認
VPNゲートウェイ側で必ず確認すべきは、VPNトンネルで受信したパケットを適切な社内ネットワークに転送（ルーティング）できることです。ルーティングテーブルに社内サブネットへのルートが存在しないと、パケットは正式に破棄されます。
- FortiGate：
get router info routing-table all - Cisco IOS：
show ip route
注意点：社内ネットワークが複数の拠点やVLANに分かれている場合は、特に分岐先へのルートが正しく設定されているか、VRF（仮想ルーティング）やポリシーベースルーティングも考慮する必要があります。
3. セキュリティポリシー（ファイアウォールルール）の深掘りチェック
ルーティングが整っていても、パケットが通る経路上のファイアウォールやVPNゲートウェイのセキュリティポリシーにより通信が遮断されているケースが非常に多いことを理解してください。
特にVPN接続のセキュリティポリシーは、一方向だけでなく双方向の通信許可が求められます。例えば「VPN→内部ネットワーク」は許可されているかを明確にチェックしましょう。
具体的に確認すべきポイント
- VPNセグメントから社内の対象リソースにアクセスする通信が許可されているか。
- 利用するサービス（RDP, SMB, HTTP/S, ファイル共有等）に必要なポート番号とプロトコルが許可されているか。
- セキュリティゾーンやインターフェース間のポリシーが意図した通りに適用されているか。
チェック例
- FortiGate：
show firewall policyやGUIのポリシー一覧でVPNインターフェース関連のルールを詳細に確認。 - Cisco ASA/Firepower：
show access-listで実際に許可・拒否されている通信条件を把握。
さらに、ファイアウォールのログ分析は非常に有効です。拒否ログには遮断された理由が示されていることがあり、該当時間のログフィルタリングを調査することでどのルールがトラフィックを止めているかを特定できます。
4. VPNトンネルインターフェースの詳細状態確認
VPNトンネルが「成功」と表示されていても、実際にトンネル内でデータが正常に交換されているかを詳細に検証します。トンネル状態の確認はトラブルシュートの基本中の基本です。
- FortiGateの場合：
diagnose vpn tunnel listコマンドでトンネルの状態や各パラメータを取得。 - Ciscoの場合：
show crypto sessionやshow vpn-sessiondbでセッション解析。
ポイントはトンネルが “UP” 状態であり、直近のパケット送受信が正常に行われているかです。もしトンネルは確立してもトラフィックが流れていなければ、フェーズ2のトンネル内アクセスに問題があります。
5. 社内リソースへの疎通テストと経路特定
具体的なリソースのIPアドレスに対し、クライアントからの通信確認を行います。成否によって原因の切り分けに繋がります。
- pingコマンド：最低限のICMPプロトコルを通じて端末からリソースへのパケットが届くかを試します。pingが通れば経路は確立されている可能性が高いです。
- traceroute/tracert：通信経路を経由するゲートウェイや機器を追跡し、どこで途切れているかを特定します。途中のノードで止まる場合は、その地点のルーティングやACL設定に問題がある可能性が高いです。
注意点：対象機器がICMPを受け付けない設定の場合、pingは失敗してもTCP接続テスト（例: telnet [ip] [port]）で通信確認を行いましょう。
6. 社内リソースのアクセス制限とDNSの検証
最後に、VPN以外の原因として考えられるのが、社内リソース側の設定です。
- ファイアウォールのホワイトリスト設定：VPNで割り当てられるIPアドレス範囲が許可リストに入っているか。
- アクセス制限ポリシー：社内サーバのローカルファイアウォール（Windowsファイアウォール等）がVPN経由の接続を拒否していないか。
- DNS解決問題：社内リソース名でアクセスできない場合、VPN接続で割り当てられたDNSサーバが正常に名前解決を行えているか。
具体策：IPアドレス直指定の通信テストも並行し、名前解決問題の切り分けを行うことが現場で有効です。
まとめ：原因特定の優先順位とポイント整理
VPN接続成功後に社内リソースへアクセスできない問題は、次の手順で調査すると効率的です。
- VPN接続状態の基本確認：トンネル確立とIPアドレス割り当ての検証。
- クライアント端末のルーティングテーブル確認：社内リソース宛経路がVPN向けであること。
- VPNゲートウェイのルーティング設定：リソースネットワークへのパケット転送経路の有無。
- セキュリティポリシー・ファイアウォールルールの確認：VPN→社内通信および利用ポートの許可状態。
- VPNトンネルの状態詳細チェック：フェーズ2のトンネル内部通信が正常か。
- リソースへの疎通テスト（ping/tracerouteなど）：経路の開通状況と遮断ポイントの特定。
- 社内リソース側設定の確認：アクセス制限・DNS問題の切り分け。
これらを順番に丁寧に進めることで、現場のネットワーク担当者は自信を持って原因特定と対策が可能になります。トラブルシューティングでは焦らず、論理的に段階を踏むことが最重要です。
本記事の手順とコマンド例を活用し、網羅的に検証を進めることでVPN接続後のリソースアクセス問題は確実に解決へと導けるでしょう。
