【実務・中級編】リモートアクセスVPNにおけるスプリットトンネリングの設計とリスク – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

境界防御の終焉と「スプリットトンネリング」の甘い誘惑：現場で戦うエンジニアのための設計指針

ネットワークエンジニアとして現場を渡り歩いていると、VPNの設計議論で必ずぶつかる壁がある。「全てのトラフィックを社内に流す（フルトンネル）」か、「必要なものだけ流す（スプリットトンネル）」か、だ。

教科書的には「セキュリティ重視ならフルトンネル」と教わる。しかし、現代のクラウドネイティブな開発環境で、Zoomのビデオ会議やYouTubeの技術ドキュメント、SaaSのAPIコールまで全て本社経由でトラフィックを折り返せば、VPNゲートウェイは悲鳴を上げ、遅延は酷く、ユーザーからの「ネットが遅い」という怨嗟の声がチケットシステムを埋め尽くすことになる。

今日は、そんな現実的なトレードオフの中でいかに「スプリットトンネリング」を安全に実装するか、その深淵を覗いてみよう。

—

スプリットトンネリングの構造：パケットはどこを走るのか

スプリットトンネリングの核心は、OSのルーティングテーブルをいかに賢く操作するかに尽きる。

通常、VPNクライアントが接続を確立すると、仮想NIC（TUN/TAPインターフェース）が作成される。ここで「社内リソース（例：10.0.0.0/8）」への通信だけをその仮想NICへ流し、それ以外はデフォルトゲートウェイ（物理LAN側）へ流すようルーティングテーブルを書き換えるわけだ。

ルーティングのシーケンス（簡略化）

1. 接続時: VPNクライアントがIKEv2やSSL-VPNでゲートウェイとハンドシェイク。
2. 経路配布: ゲートウェイからPUSH設定（OpenVPN等）やSplit-Tunnel用構成プロファイルがクライアントへ送られる。
3. 経路適用: ip route（Linux）やRoute Print（Windows）にて、特定のサブネット宛のメトリックが優先される。
4. 通信: APIリクエストがアプリケーションから投げられると、OSが宛先を見て「社内か、それ以外か」を瞬時に判断する。

—

セキュリティリスク：背中ががら空きであるという事実

スプリットトンネリングの最大の弱点は、「VPN接続中の端末が、同時にインターネットにも露出している」ことだ。

もしユーザーがVPN接続中に悪意あるWebサイトへアクセスし、そこから攻撃者がPCに侵入した場合、そのPCは社内ネットワークへの「踏み台」になる。 境界防御が崩壊し、VPNという「信頼のトンネル」を通じて社内の重要サーバーに直接アクセスできてしまう。

このリスクを低減するためには、単なる「ルート分け」で終わらせず、ゼロトラストの思想を注入する必要がある。

—

実践的な対策：エンドポイントとAPIの守り方

スプリットトンネリングを採用する場合、以下の対策をコードレベル、あるいは設定レベルで組み込むのが「凄腕」の流儀だ。

1. 接続先IPの厳格化（PythonによるAPI制御例）

社内APIを叩く際、接続先が意図したVPN経由であることをコード側でも意識する。

import requests
import socket

def secure_api_call(url):
    # 名前解決してIPを特定し、社内レンジかを確認する防御的コーディング
    hostname = url.split("//")[-1].split("/")[0]
    ip_addr = socket.gethostbyname(hostname)
    
    # 社内IP範囲外へのアクセスを弾く、または警告を出す
    if not ip_addr.startswith("10.0."):
        raise PermissionError(f"セキュリティ警告: 社外ネットワークへのアクセスを検知しました: {ip_addr}")
    
    # 実際のリクエスト
    response = requests.get(url, timeout=5)
    return response.json()

2. コンフィグでの制御（OpenVPNの例）

サーバー側からプッシュする設定で、許可するサブネットを極小化する。redirect-gateway def1を避け、必要なネットワークのみをpush "route ..."で送り込む。

# server.conf の記述例
# 全トラフィックを流さず、特定レンジのみをルーティングさせる
push "route 10.0.0.0 255.0.0.0"
push "route 172.16.0.0 255.240.0.0"

# 重要：DNSも漏洩を防ぐために社内DNSを指定する
push "dhcp-option DNS 10.0.0.1"

—

現場のトラブルシューティング：なぜ繋がらないのか？

スプリットトンネリングで最も多いトラブルは「名前解決」だ。VPN経由で社内APIを叩こうとしても、Public DNSが社内ドメインを解決できず、かといって社内DNSが外部サイトをうまくさばけないケースがある。

現場のTips:

DNSリークを確認せよ: nslookup や dig を使い、社内APIを叩く際にどのDNSサーバーが応答しているか必ず確認すること。
メトリックの競合: Windowsの場合、物理NICと仮想NICのメトリック値が競合して通信が迷子になることがよくある。route printでメトリックを確認し、VPN側の優先度を高く設定し直す必要がある。
curlでのデバッグ: 疎通確認には必ず -v オプションをつけて、どのIP（どのインターフェース）が使われているかをログで追え。

# curlで特定のインターフェースを意識した疎通確認
# VPNアダプターのIPを指定してリクエストを投げる
curl -v --interface 10.x.x.x https://internal-api.example.com

—

最後に：完璧な防御は存在しない

スプリットトンネリングは、利便性とセキュリティのギリギリの妥協点だ。しかし、この設計を採用するなら、「エンドポイント自体が侵害されているかもしれない」という前提を忘れてはならない。

EDR（Endpoint Detection and Response）の導入、ゼロトラストネットワークアクセス（ZTNA）への段階的な移行こそが、真の解決策だ。VPNはその過渡期における強力な道具だが、使い方を誤れば足元をすくわれる。

ネットワークは生き物だ。ルーティングテーブルを愛し、パケットの流れを想像し、常に疑う心を持って設計に向き合ってほしい。君の書くコードと構築するインフラが、組織を守る最後の砦になるのだから。