スプリットトンネリングとは何か

スプリットトンネリングは、端末からの通信のうち一部だけをVPNトンネルに通し、残りはVPNを通さずに通常の通信経路へ流す考え方です。たとえば「特定のアプリ」「特定の宛先（IPアドレスやドメイン）」「特定の通信だけ」をVPN経由にし、それ以外はそのままインターネットへ出す形が典型です。

この仕組みの狙いは、VPNを使う通信を絞って帯域や遅延の影響を抑えたり、社内アクセス以外は通常のネットワーク品質を活かしたりすることにあります。一方で、VPNを通さない経路が存在するため、期待する保護範囲や見え方（ログ/到達先の扱い）は「常時VPN」より複雑になります。

簡単な動作モデル

動作を単純化すると、次の流れになります。

  1. 端末の通信要求が発生する（アプリが接続先へアクセスする）
  2. VPNクライアントが「その通信をVPN経由にするか」を判断する
  3. VPN経由にする通信はトンネルに入れて送信し、対象外ならそのまま通常経路で送信する

判断の基準としてよくあるのは、宛先のドメイン名やIPアドレスの一致、アプリ単位の指定、あるいはルールの集合（許可リスト/除外リスト）です。ここで重要なのは、「どの通信を対象にしているか」はルールで決まるという点です。ルールが意図とズレると、VPNに通すはずの通信が通らない、または通さないはずの通信が通ってしまう、といった結果になります。

部品と設計のポイント（何が分岐を決めるか）

スプリットトンネリングでは、分岐に関わる要素が複数あります。

  • ルール（対象/非対象の指定） 宛先ベース（ドメイン/IP）か、アプリベースか、双方かで挙動が変わります。
  • DNSの扱い ドメイン名でルールを作る場合、DNS解決の経路や結果の扱いが一致性に影響します。DNSが通常経路になる構成だと、「ルール判定の材料がどの経路から得られるか」が問題になります。
  • 既存接続の扱い 接続中の通信は、ルール変更のタイミングによってすぐに切り替わらないことがあります。

また、分岐後の通信は同じ端末からでも見え方が変わります。VPN経由の通信はVPN側の出口に依存し、通常経路の通信はローカルの回線側の出口になります。結果として、同じアプリでも通信の種類により「体験が分かれる」ことが起こり得ます。

何が「制限」や「落とし穴」になりやすいか

スプリットトンネリングでよく問題になるのは、主に次の点です。

  1. 対象外の通信が残る VPN経由にしたい範囲が完全にカバーされないと、意図した保護が及びません。これは「通さない経路」が存在する仕様上の限界です。

  2. ルールの粒度が足りない/ズレる ドメイン名とIPの対応は常に固定ではありません。CDNやローテーション、解決結果の変更があると、想定していた宛先と一致せず、挙動がぶれます。