境界のジレンマ：開発現場を蝕む「全部VPN」の呪縛とスプリットトンネリングの現実解
おい、ちょっとこっちに来てくれ。
お前が今担当しているその新しい社内向けWeb APIのステージング環境、また「社内からしか繋がらない」ってインフラチームから差し戻されたのか？ ……無理もない。うちの会社じゃ、セキュリティポリシーの金科玉条として「全トラフィックを強制的にお堅い社内VPNの暗号トンネルにブチ込む」っていう古典的な全通トンネリング（Full Tunnel）が長年信奉されてきたからな。
だが、エンジニアとして冷静に考えてみてほしい。
お前が手元のMacやLinuxで、自宅の光回線からわざわざ社内VPNを張った状態で、YouTubeのチュートリアル動画を見たり、AWSのパブリックなS3バケットから数GBのDockerイメージをPullしたり、あるいはパブリックな外部Web APIの叩きテストをしたりしているとする。その背後で何が起きているか、パケットの気持ちになって想像したことがあるか？
お前のPCから出たパケットは、わざわざ数千キロ離れた（あるいは情シスが適当に立てたクラウド上の）VPNゲートウェイの重たいカプセル化処理（IPsecやWireGuardの暗号化）を強制され、そこから改めてゲートウェイのIPで外のインターネットへと出ていく。当然、レイテンシは跳ね上がり、社内VPNのファイアウォールや帯域制限装置（NAT/Proxy）には無駄な負荷が蓄積し、インフラ部門からは「今月の回線費用が爆発しているんだが！」と怒りのSlackが飛んでくる。
ここで登場するのが、今回深掘りするスプリットトンネリング（Split Tunneling）だ。
すべての通信を盲目的にカプセル化するのをやめ、「社内リソースへのトラフィックだけをVPNへ流し、それ以外のインターネット向けトラフィックはローカルのゲートウェイから直接ダイレクトに放り出す」という、極めて実用的かつ、一歩間違えるとセキュリティの地雷原を踏むアプローチについて、プロの現場の視点から徹底的に解き明かしてやろう。
—
1. スプリットトンネリングの通信メカニズム：OSのルーティングテーブルはどう書き換わるのか？
まず、ネットワークの基本に立ち返ろう。VPNクライアントソフトウェア（OpenVPNやWireGuard、IPsecクライアントなど）が「接続完了」のステータスを吐いた瞬間、OSの裏側で何が起きているか知っているか？
答えはシンプルだ。OSのIPルーティングテーブル（ip route や route print）の動的な書き換えである。
フルストトンネリングの場合、デフォルトゲートウェイ（0.0.0.0/0）のメトリック（優先度）がVPNの仮想インターフェース（tun0 や ppp0 など）に向かって書き換えられる。これによって、DNSへの問い合わせを含め、すべてのパケットが問答無用でVPNトンネルの吸い込み口に引きずり込まれるわけだ。
一方、スプリットトンネリングを有効にした場合、ルーティングテーブルの振る舞いはこう変わる。
宛先ネットワーク (Destination) ネットマスク (Gateway/Interface) 説明
--------------------------------------------------------------------------------------------------
0.0.0.0/0 192.168.1.1 (物理Wi-Fiルーター) -> 一般のインターネット通信は直通
10.100.0.0/16 10.8.0.1 (仮想VPNトンネル `tun0`) -> 社内プライベートNW宛てだけVPN経由
172.16.50.0/24 10.8.0.1 (仮想VPNトンネル `tun0`) -> 開発用DBサーバー群もVPN経由このルーティング設定の妙により、OSのネットワークスタックは、パケットの宛先IPアドレスを評価し、「あ、こいつは 10.100.0.0/16 の社内基幹系だな」と判断した瞬間だけカプセル化の処理を行い、「お、GoogleのパブリックDNS 8.8.8.8 か、なら目の前のカフェのWi-Fiルーターから直接出しちまえ」とバイパスする。
この挙動を理解していれば、例えば「社内APIの疎通はできるのに、なぜか社内のローカルDNS（10.100.0.2）の名前解決が失敗して外部のAPIエンドポイントを見失う」といった、現場でありがちなDNSリーク起因のトラブルにも即座に切り込みを入れることができるはずだ。
—
2. セキュリティトレードオフ：利便性の裏に潜む「スプリット」の魔物
「よし、じゃあ全部スプリットトンネリングにして開発効率を爆上げしようぜ！」と思ったそこのお前、ちょっと待て。セキュリティスペシシャリストとしての俺の帽子をかぶせてもらうぞ。
スプリットトンネリングの導入は、企業のセキュリティ境界（Perimeter）を文字通り「スプリット（分裂）」させる行為に他ならない。ここで発生する代表的なトレードオフを整理しておこう。
メリット：インフラ・開発効率の劇的な改善
- 帯域幅の温存: 重たい動画やパブリックなリポジトリからの巨大なバイナリダウンロードが社内VPNサーバーを経由しなくなるため、VPN装置のCPU負荷と回線コストが激減する。
- ローカルリソースの維持: 自宅のローカルネットワークにあるプリンター、スマート家電、あるいはローカルのNASやテスト用プリンター等との接続が、VPNを切断することなく同時に利用できる。
- レイテンシの最適化: 外部のSaaSやWeb APIへダイレクトにアクセスできるため、往復の遅延（RTT）が小さくなり、ローカルでの開発・デバッグ体験が圧倒的に快適になる。
デメリット・セキュリティリスク：攻撃者の侵入経路（サイドローディング）
- ローカルネットワーク経由の踏み台リスク（Split-Horizon / ローカルネットワーク漏洩）:
ユーザーが自宅やスタバなどの信頼できないパブリックWi-Fiに接続している状態でスプリットトンネリングを使っているとどうなるか？ ユーザーのPCは、同じローカルセグメントにいる悪意ある端末から見える状態（直接通信可能）のまま、同時に社内ネットワーク（10.100.0.0/16）の認証済みセッションを保持していることになる。もし自宅のPCがマルウェアに感染していれば、ローカルネットワークを介して社内VPNのセッションが乗っ取られ、社内基幹システムへの踏み台（Pivot）として悪用されるリスクが跳ね上がる。
- DNS漏洩（DNS Leaking）とトラフィックの可視化不足:
企業側から見ると、ユーザーがインターネット上でどのようなサイトにアクセスしているのか、セキュリティゲートウェイ（SWG等）で一元的に監視・ログ収集することができなくなる。シャドーITの利用や不審なサイトへのアクセスを検知しにくくなる点は、コンプライアンス上大きな課題となる。
—
3. 実務で直面するトラブルとデバッグ手法：なぜAPI通信が弾かれるのか？
実務の現場では、スプリットトンネリングを導入した途端に「特定の社内Web APIだけが403や504を返す」「ローカルからのリクエストがCORSエラーやIP制限に引っかかる」といった不具合が頻発する。
ここで、シニアエンジニアが現場で使う具体的なデバッグコマンドと、そのアプローチを伝授しよう。
ステップ1: 現在のルーティングとインタフェースの確認（macOS / Linux）
まずは手元の端末で、どのルートがどのインターフェースに割り当てられているかを正確に把握する。
# macOSやLinuxの場合、ルーティングテーブルを表示
netstat -nr
# または、より現代的なipコマンドを使用する場合 (Linux)
ip route showもし「特定のAPIサーバーのIP（例: 192.168.50.10）」宛てのパケットが、意図した tun0 ではなく、物理インターフェース（en0 や eth0）に吸い寄せられている場合、VPNクライアント側の設定ファイルでルートのプッシュ（Push Routes）が正しく行われていない証拠だ。
ステップ2: パケットの足取りを追う（traceroute と curl）
次に、パケットが実際にどこを通って宛先に到達しているのか、あるいは途中でブラックホールに吸い込まれていないかを追跡する。
# パケットの経路（ホップ）を確認し、VPNゲートウェイを経由しているか確認する
traceroute api.internal.example.com
# 実際にHTTPリクエストを投げ、レスポンスヘッダーやルーティングをデバッグする
curl -v -H "Authorization: Bearer <TOKEN>" https://api.internal.example.com/v1/healthここで、PythonなどのスクリプトからAPIを叩く際のスニペットも紹介しておこう。社内APIと外部パブリックAPIを混在させて叩くようなマイクロサービス環境のテストスクリプトでは、スプリットトンネリング環境下での挙動を意識しておく必要がある。
import requests
import sys
# 社内プライベートAPIののエンドポイント（VPN経由でルーティングされるべき）
INTERNAL_API_URL = "https://api.internal.example.com/v1/data"
# パブリックな外部APIのエンドポイント（ローカルからダイレクトにルーティングされるべき）
PUBLIC_API_URL = "https://httpbin.org/ip"
def test_api_routing():
try:
print("--- 1. 外部パブリックAPIへのリクエスト ---")
pub_res = requests.get(PUBLIC_API_URL, timeout=5)
print(f"Status: {pub_res.status_code}")
print(f"Client Public IP (Seen by external): {pub_res.json()}")
print("\n--- 2. 社内プライベートAPIへのリクエスト ---")
# スプリットトンネリング環境下では、ここだけがVPN経由のプライベートIPで通信される
int_res = requests.get(INTERNAL_API_URL, timeout=5, verify=False)
print(f"Status: {int_res.status_code}")
print(f"Response: {int_res.json()}")
requests.exceptions.RequestException as e:
print(f"通信エラーが発生しました: {e}", file=sys.stderr)
if __name__ == "__main__":
test_api_routing()このスクリプトを実行した際、もし INTERNAL_API_URL への接続がタイムアウトする場合は、単にVPNの接続状態だけでなく、DNSサーバーの向き先（ローカルのルーターが返すDNSか、社内の内向きDNSか）がスプリットトンネリングによって意図せず切り替わっていないか（いわゆるスプリットDNSのミスマッチ）を疑うべきだ。
—
4. エンジニアが守るべき「スプリットトンネリング設計」のベストプラクティス
最後に、お前が今後インフラのアーキテクチャを設計する際、あるいはセキュリティチームとポリシーを交渉する際に必ず押さえておくべき実践的な指針をまとめておく。
1. 「必要な最小限」のルートのみをプッシュする（Principle of Least Privilege）:
VPNサーバー側からクライアントに配るルーティング設定（push "route ..." 等）では、無駄に広いセグメント（例: 10.0.0.0/8 全体）を渡すな。本当にアクセスが必要な具体的なサブネット（例: 10.100.50.0/24）だけに絞り込め。
2. ローカルネットワークアクセス（Local LAN Access）の制御を明示的に行う:
クライアントが接続するWi-Fiなどのローカルセグメントへのアクセスを完全遮断するか、あるいは許可するかを、VPNクライアントのポリシーで明確に制御せよ。セキュリティ感度の高い環境では、ローカルLANへのアクセスを禁止（Block Local LAN Access）しつつスプリットを実現する「セキュア・スプリット」の構成が望ましい。
3. ゼロトラストネットワークアクセス（ZTNA）への移行を見据える:
そもそも、レガシーなVPN機器を無理にスプリットさせて運用する時代は終わりの始まりだ。これからは、社内・社外の境界を問わず、デバイスの健全性（Postur Check）やユーザーのコンテキストに基づいて、アクセスするアプリケーション単位で動的に認可を制御する ZTNA（Zero Trust Network Access） へのリプレイスを検討すべきだ。Cloudflare AccessやAWS Verified Access、Tailscaleなどのモダンなソリューションは、まさにこの「必要なものだけを安全にルーティングする」思想の究極形と言える。
—
おわりに
技術には常に「トレードオフ」という名の代償が存在する。全通トンネリングの強固な安全性（と引き換えの圧倒的な遅延と高コスト）をとるか、スプリットトンネリングのスマートな利便性（と引き換えのきめ細やかなセキュリティ管理の必要性）をとるか。
プロのエンジニアに求められるのは、「何が安全か」を盲目的に信じることではなく、「どのレイヤーでどのようなリスクが生まれ、どうコントロールすべきか」をパケットレベルで把握し、デザインすることだ。
さあ、ウンチクはこれくらいにして、さっそくお前の環境のルーティングテーブルを叩いてみろ。ネットワークの裏側で何が起きているか、自分の目で確かめてみるんだな。
コメント