スプリットトンネリングの深淵：パフォーマンスとセキュリティの危うい均衡点
ネットワークエンジニアにとって、VPNは「絶対的な安心」をもたらす聖域であると同時に、パフォーマンスを蝕む「忌まわしいボトルネック」でもある。全トラフィックを暗号化トンネルへ押し込む「フルトンネリング」は、セキュリティの観点からは潔癖で美しい。しかし、Zoomの会議がパケットロスでカクつき、SaaSのレスポンスがRTT（Round Trip Time）の増大で息切れを起こす現場において、その「潔癖さ」はしばしば事業継続の足かせとなる。
そこで登場するのが「スプリットトンネリング（Split Tunneling）」だ。しかし、この機能はただの「通信の選別」ではない。OSのルーティングテーブルを書き換え、パケットの運命を左右する高度なインフラ操作である。本稿では、この諸刃の剣をエンジニアとしてどうハンドリングすべきか、パケットレベルの挙動から紐解いていく。
—
パケットの運命を決定づけるルーティングの裏側
スプリットトンネリングの核心は、OSの IP routing table における優先順位の制御にある。VPNクライアントが立ち上がると、通常は 0.0.0.0/0 のデフォルトゲートウェイがVPN仮想インターフェース（tun0 や utun）へ書き換えられる。
スプリットトンネリングでは、これをあえて崩す。特定の宛先（例えば社内のプライベートIPレンジや特定のSaaSエンドポイント）のみをトンネルへ流し、それ以外を物理インターフェース（eth0 や wlan0）からISPへ直接放出する。
なぜパフォーマンスが劇的に改善するのか
フルトンネリングでは、本来ISPから直接引けるコンテンツまで、一度VPNゲートウェイを経由し、カプセル化（ESPやUDP/443でのラップ）を経て復号される。このオーバーヘッドと、地理的に離れたVPNサーバーを経由することによるRTTの増大は、TCPの窓（window size）制御に直接的な悪影響を与える。
特に TCP Cubic や BBR を利用している場合、VPNによる遅延の揺らぎ（Jitter）は、輻輳制御アルゴリズムを誤認させ、スループットの急降下を招く。スプリットトンネリングはこの「無駄な往復」を排除することで、物理的な回線能力を最大限に引き出すのだ。
—
セキュリティトレードオフ：穴はどこに空いているのか
しかし、エンジニアが警戒すべきは「トンネル外」のトラフィックだ。VPNをバイパスした通信は、TLSのハンドシェイクを除けば、中間者攻撃（MITM）やDNS汚染に対して無防備な状態に晒される。
特に、DNS leak は見落とされがちだ。ローカルのDHCPから降ってきたDNSサーバーを使用して名前解決を行うと、社内リソースへのアクセス経路が外部に筒抜けになるだけでなく、DNSハイジャックによるフィッシングサイトへの誘導リスクが跳ね上がる。
実装上の注意：ルーティングの断片化を避ける
Linuxでスプリットトンネリングを実装する際、ip route コマンドで静的に制御することが多いが、モバイル環境ではネットワークの切り替わりによりルーティングが汚染されるリスクがある。以下は、特定のネットワークのみを通すためのルーティング設定例だ。
# 1. 社内ネットワーク（10.0.0.0/8）のみをVPNトンネル(tun0)へ向ける
sudo ip route add 10.0.0.0/8 dev tun0 metric 10
# 2. 残りのインターネットトラフィックは物理インターフェース(wlan0)を優先する
# デフォルトゲートウェイのメトリックを下げることで優先度を調整
sudo ip route add default via 192.168.1.1 dev wlan0 metric 100—
極限の最適化：MSSとTCPバッファのチューニング
スプリットトンネリングを採用しても、トンネルを通るトラフィックにはカプセル化によるMTU（Maximum Transmission Unit）の減少が伴う。VPNパケットのヘッダー分を考慮し、MSS (Maximum Segment Size) を適切に調整しなければ、ICMP Fragmentation Needed が届かない環境で「パケットがブラックホールに消える」という悪夢を見ることになる。
iptables によるMSSクランプの最適化
以下の設定は、トンネルを通るパケットのヘッダーサイズを考慮し、過剰なフラグメンテーションを防ぐための鉄則だ。
# VPNインターフェースを通るパケットのMSSを強制的に小さくする（例: 1360）
# MTU 1500からIPsec/TLSオーバーヘッドを差し引いた値を設定する
sudo iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360—
結論：ゼロトラスト時代における正しい立ち位置
スプリットトンネリングは、単なる利便性のための妥協ではない。境界防御が崩壊し、ユーザーが「どこにいても安全であること」を求められるゼロトラスト時代において、「必要な通信のみを厳重に暗号化し、それ以外はローカルの信頼性に依存する」という設計思想は、トラフィックの可視化とセキュリティの最適化を両立させるための洗練された戦略だ。
ただし、これを導入する際は必ず以下の鉄則を守ってほしい。
1. DNSの強制: トンネル外のDNSクエリを許さない（DNS-over-HTTPS の強制や、VPN専用DNSサーバーの使用）。
2. エンドポイントの堅牢化: トンネル外へ出るパケットに対しては、OS標準のファイアウォール（nftables や Windows Defender Firewall）による厳格なフィルタリングを適用すること。
3. 可観測性の確保: スプリットされたトラフィックが意図通りに流れているかを、tcpdump や Wireshark で定期的に検証する泥臭いプロセスを省かないこと。
ネットワークは生き物だ。静的な設定で満足せず、パケットの脈動を感じながら、その都度最適解を追求し続けることこそが、我々エンジニアに課せられた矜持である。
コメント