「VPNフルートンネルの罠」を越えろ──DNS解決とルーティングの深淵
ネットワークエンジニアとして現場を歩いていると、若手から必ずと言っていいほどこんな相談を受ける。「VPNに繋ぐと、社内リソースにはアクセスできるのに、インターネットが極端に遅くなる」あるいは「DNSの解決がおかしい」。
これらはすべて、フルートンネル（All-Tunneling）の仕組みを理解できていないことで生じる、典型的な「ネットワークの迷宮入り」だ。今日は、パケットがVPNのトンネルを駆け巡る際、裏側で何が起きているのか、その泥臭い現実を解き明かしていこう。
—
1. フルートンネルという「強制連行」の正体
フルートンネルとは、平たく言えば「端末から出るすべてのトラフィック（宛先IPが何であれ）を、一旦VPNゲートウェイを通す」という構成だ。
通常、PCのルーティングテーブルは、デフォルトゲートウェイ（0.0.0.0/0）をローカルのWi-Fiルーターに向けている。しかし、VPNクライアントを起動してフルートンネルを有効にすると、クライアントソフトはOSのルーティングテーブルを強引に書き換える。
具体的には、以下のような挙動になる。
1. 既存のデフォルトルートの優先度を下げる（または削除）。
2. VPNの仮想ネットワークインターフェースに、より高い優先度（メトリック）でデフォルトルートを注入する。
これで、君のPCから出るGoogleへのパケットも、社内サーバーへのパケットも、すべて一度VPNトンネルという「暗いトンネル」の中へ放り込まれることになる。
—
2. DNS解決という「隠れた地雷原」
フルートンネルで最もトラブルが起きやすいのがDNSだ。
多くのVPN設定では、接続と同時に「社内DNSサーバーのIPアドレス」が端末にプッシュされる。ここでミスを犯すと、「VPNは繋がっているのに、インターネット上のWeb APIを叩くと名前解決できずに死ぬ」という現象が起きる。
DNSクエリのフローを追え
端末が api.external-service.com を解決しようとする際、OSは以下の順序で動く。
1. OSのスタブリゾルバが、設定されたDNSサーバー（VPN経由で指定された社内DNS）にクエリを投げる。
2. 社内DNSは「社内ドメイン」なら解決できるが、インターネット上のドメインに対しては「再帰問い合わせ」を行う。
3. もし社内DNSにインターネットへのアクセス権限がない、あるいはスループットが極端に低い場合、ここでボトルネックが発生する。
実務Tips:
開発環境で curl を叩く際、名前解決が遅いと感じたら、まずは明示的にDNSを指定して疎通確認をしよう。
# 明示的にGoogleのDNS(8.8.8.8)を使って名前解決を試す
# これで解決できるなら、VPN経由の社内DNSサーバーに問題がある可能性大
curl -v --dns-servers 8.8.8.8 https://api.example.com/v1/data—
3. Pythonでのデバッグ：トラフィックがどこを通っているか
API開発をしていると、「本当にVPN経由で通信できているか？」を確認したくなるはずだ。Pythonの requests ライブラリを使えば、クライアント側のIPアドレスを簡単に確認できる。
import requests
# 外部のIP確認用APIを叩く
# VPNのゲートウェイがグローバルIPを変換（NAT）して出口にしているなら、
# 返ってくるIPアドレスは会社のグローバルIPになるはずだ
try:
response = requests.get('https://api.ipify.org?format=json', timeout=5)
print(f"現在のグローバルIP: {response.json()['ip']}")
except Exception as e:
print(f"通信エラー: {e}")もしここで「自宅のプロバイダのIP」が表示されたら、それはフルートンネルの設定が失敗しているか、スプリットトンネルが混在している証拠だ。
—
4. 現場で使える「ルーティング確認」コマンドの極意
トラブルシューティングの基本は「今のルーティングテーブルはどうなっているのか」を疑うことだ。以下のコマンドを使いこなしてほしい。
macOS / Linux
# デフォルトゲートウェイの確認
netstat -nr | grep default
# または、ipコマンドでルートを確認（Linuxの場合）
ip route show defaultここで tun0 や ppp0 といったインターフェースが 0.0.0.0/0 のネクストホップになっていれば、フルートンネルは正常に機能している。
Windows (PowerShell)
# ルーティングテーブルの確認
Get-NetRoute -DestinationPrefix "0.0.0.0/0"ここで「InterfaceMetric」の値に注目してほしい。この値が小さいほど、そのルートが優先される。VPNアダプタのメトリックが、物理インターフェース（Wi-Fi等）よりも小さくなっていることが、フルートンネル成功の絶対条件だ。
—
5. 最後に：エンジニアとしての心構え
フルートンネルは「全集中」のネットワーク状態だ。セキュリティ的には盤石だが、DNSの設計を誤れば、開発者の生産性を著しく削ぐ。
- DNSは適切にスプリットしているか？（社内ドメインのみVPN経由にし、それ以外はローカルDNSにするような構成は検討されているか？）
- VPNゲートウェイの帯域は全トラフィックを捌けるか？
これらを理解せず、「とりあえず繋げば安心」という運用をしていると、必ずどこかで致命的なレスポンス低下に見舞われる。
ネットワークは魔法ではない。パケットが物理的な距離と論理的なトンネルをどう移動しているか、その一歩一歩を想像する力を養ってほしい。それができれば、どんな難解な通信トラブルも、ただのパズルに過ぎなくなるはずだ。
現場からは以上だ。何か詰まったら、またパケットをキャプチャして深淵を覗いてみよう。
コメント