スプリットトンネリングの深淵：ルーティング制御とパケットフローの最適化
VPNを常時接続（Always-on）にしていると、時としてパケットのオーバーヘッドがネットワーク体験を劇的に劣化させることがある。全トラフィックをVPNトンネルに流し込む「フルトンネリング」は、セキュリティの観点からは確かに潔いが、Netflixのストリーミングや大容量のCDNキャッシュまで暗号化・復号のオーバーヘッドを強いるのは、現代のインフラとしては非効率の極みだ。
今回は、インフラアーキテクトが避けては通れない「スプリットトンネリング」の技術的実装と、その裏側でパケットがどのような運命を辿るのか、カーネルレベルの挙動を交えて解説する。
—
1. ルーティングテーブルの戦場：なぜ「選択」が必要か
スプリットトンネリングの核心は、OSのルーティングテーブルにおける「優先順位」の制御にある。Linuxベースの環境であれば、ip routeコマンドによるメトリック制御が基本だ。
VPN接続が確立されると、通常は0.0.0.0/0（デフォルトゲートウェイ）がVPN仮想インターフェース（tun0等）に向くよう書き換えられる。ここを細分化（Subnetting）することで、特定の宛先のみをVPNにルーティングする。
# 1. 現在のルートを確認
ip route show
# 2. 社内ネットワーク(10.0.0.0/8)のみをVPN(tun0)へ向ける
# メトリックを小さく設定し、優先度を上げる
sudo ip route add 10.0.0.0/8 dev tun0 metric 100
# 3. 特定のパブリックIPを直接ローカルゲートウェイへ向ける
# VPN経由での不必要な遅延を排除する
sudo ip route add 203.0.113.5 dev eth0 metric 10この設定により、パケットは自身の宛先IPに基づき、カーネルのルーティング決定プロセスで「道」を選別する。ここで重要なのは、TCPのハンドシェイク中に発生するRTT（往復遅延時間）の削減だ。VPNをバイパスすることで、余計なヘッダーカプセル化（ESPやUDPカプセル化）を回避でき、数ミリ秒単位のレスポンス改善が可能となる。
—
2. トランスポート層の最適化：MSSとバッファチューニング
カプセル化されたパケットは、外側のヘッダー分だけMTUサイズが小さくなる。これを考慮せずにMTUをデフォルト（1500）のまま運用すると、中間ルータでのパケットフラグメンテーションが発生し、パフォーマンスが崩壊する。
これを防ぐための鉄則は、MSS Clampingだ。
# iptablesを用いて、VPN経由のTCPパケットのMSSを1360に強制調整する
# 1500 - (IPヘッダー + ESPヘッダー + UDPヘッダー)
sudo iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360また、大容量通信が頻発する環境では、sysctlによるTCPウィンドウサイズの調整も忘れてはならない。高遅延なVPN回線を通るパケットのフロー制御を最適化するには、バッファを拡大しておく必要がある。
# /etc/sysctl.conf に追記して反映
# 通信の並列性とスループットを向上させるためのパラメータ
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216—
3. セキュリティの陥穽：DNSリークとSplit DNS
スプリットトンネリングにおいて最も警戒すべきは、VPNを使っている「つもり」で、DNSクエリがISP側の名前解決サーバーに漏洩する「DNSリーク」だ。
セキュリティ専門家として忠告したいのは、systemd-resolvedを用いたドメインベースのルーティング（Split DNS）の活用である。全クエリをVPNに流すのではなく、社内ドメイン（例: *.internal.corp）へのクエリのみをVPN上のDNSサーバーへ向ける設計が理想だ。
# 特定のドメインに対するDNSサーバーを指定する（resolvectl）
# 他のトラフィックはシステム標準のDNS（8.8.8.8等）を利用させる
sudo resolvectl dns tun0 10.10.10.1
sudo resolvectl domain tun0 ~internal.corp—
4. 結び：パケットを「支配」するということ
スプリットトンネリングは、単なる利便性のための機能ではない。それは、トラフィックの性質を見極め、セキュリティ要件とパフォーマンス要件を動的に調停するための「高度な制御」だ。
すべてのトラフィックを一律に暗号化トンネルに押し込むのは、思考停止に近い。どのパケットにどのような防護を施し、どのパケットを最適化されたルートに乗せるか。その判断基準こそが、我々エンジニアの腕の見せ所である。
ネットワークの挙動をパケットレベルで解像度高く捉え、カーネルのルーティングスタックを自在に操る。その先にあるのは、攻撃者にとっても管理者にとっても「隙のない」強固なインフラである。さあ、今すぐ自身のパケットフローを見直し、最適解を実装してほしい。
コメント