フルートンネルの深淵：DNSリークを封じ、RTTを極限まで削ぎ落とすVPN構築術
「VPNを張れば安全」という神話は、もはや過去の遺物だ。ゼロトラスト全盛の今、フルートンネル（オールトンネリング）構成は、単なるリモートアクセス手段ではなく、エンドポイントから社内コアネットワークまでを貫く「論理的な要塞」でなければならない。
しかし、現場で遭遇するのは、パケットの迷走やDNSリークによるセキュリティホール、そしてTCPハンドシェイクがもたらす致命的なオーバーヘッドだ。本稿では、インフラアーキテクトが知っておくべき、フルートンネルの「裏側」をパケットレベルで解剖する。
—
1. DNS解決の罠：パケットの「出口」を制御する
フルートンネル構成において最も多い失敗は、0.0.0.0/0 をVPNトンネルに押し込みながら、DNSクエリだけがISPのDNSサーバーへ「漏洩」するケースだ。これは単なるプライバシーの問題ではなく、DNSハイジャックによる中間者攻撃の入り口となる。
DNS解決の強制とルートテーブルの最適化
クライアントがVPN接続を確立した際、OSの resolv.conf やネットワーク設定を強制的に書き換える必要がある。ここで重要なのは、Split-DNS の考え方だ。社内リソース（*.corp.local 等）は社内DNSサーバーで解決し、それ以外はVPN経由の再帰的問い合わせを行う。
Linux環境であれば、systemd-resolved を用いたルーティング設定が推奨される。
# 特定ドメインのみをVPN内のDNSサーバーへルーティングする設定例
# /etc/systemd/resolved.conf または resolvectl コマンドを使用
resolvectl dns tun0 10.0.0.1
resolvectl domain tun0 ~corp.local
# "~" を付与することで、そのドメインへのクエリのみをこのインターフェースへルーティングするこの設定により、DNSクエリはトンネル内を走り、それ以外のパブリックな名前解決は、セキュリティポリシーに基づいたDNSフィルタリングサービス（Umbrella等）を経由するように設計するのが現代の最適解だ。
—
2. トランスポート層の最適化：TCP-over-TCPの「メルトダウン」を防ぐ
VPNの最大の敵は、TCP上でTCPを動かすことで発生する「TCP Meltdown」だ。内側のTCPがパケットロスを検知して再送を行う際、外側のトンネルTCPも同様に輻輳制御を行い、結果としてタイムアウトが連鎖する。
RTT削減のためのバッファチューニング
この問題を回避するには、可能であれば WireGuard のようなUDPベースのトンネリングを採用すべきだが、企業インフラで IPsec や OpenVPN (TCPモード) を避けられない場合、カーネルレベルのチューニングが必須となる。
# sysctl.conf によるTCPバッファの最適化
# 帯域幅遅延積（BDP）を考慮し、ウィンドウスケールを調整する
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCPの輻輳制御アルゴリズムをBBRに変更（高遅延環境下で圧倒的なスループット向上）
net.ipv4.tcp_congestion_control = bbrBBR を採用することで、VPNトンネル内のパケットロスに対して非常に寛容になり、高RTT環境下でもスループットを維持できる。これは、フルートンネルのパフォーマンスを劇的に改善する「魔法のスイッチ」だ。
—
3. ヘッダー圧縮とパケット断片化の回避
フルートンネルでは、カプセル化（IPsecのESPヘッダーやOpenVPNのオーバーヘッド）により、MTU/MSSが通常よりも小さくなる。これを考慮せずにMTUを 1500 のままにすると、パケット断片化（Fragmentation）が発生し、CPU負荷の増大とパケットロスを招く。
MSSクランプによる最適化
iptables を用いて、トンネルを通過するパケットのMSSを強制的に書き換えることで、断片化を未然に防ぐ。
# VPNインターフェース(tun0)を通過する通信のMSSを適切に制限する
# 一般的なIPsec/OpenVPNのオーバーヘッドを考慮し、1360〜1400程度に設定
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360これにより、接続確立時の SYN パケットが適切なサイズに調整され、後続のデータセグメントが断片化されずにトンネルを通過する。
—
4. 最後に：ゼロトラストへの移行を見据えて
フルートンネルは強力な境界防御だが、一度トンネルに入れば「社内ネットワークは安全」という古い前提に依存してはならない。
私が設計の現場で推奨しているのは、「トンネルはあくまでセキュアなパイプであり、その中身（通信）は必ずTLS 1.3で暗号化され、mTLS（相互認証）によって厳格に制御する」という多層防御の徹底だ。
VPNゲートウェイを単なる「接続ポイント」から「アイデンティティ認識型プロキシ（IAP）」へと進化させること。これが、これからのインフラアーキテクトに求められる真の腕の見せ所である。パケットの挙動を支配し、ボトルネックを可視化せよ。ネットワークの深淵を覗き込む者だけが、真にセキュアなインフラを構築できるのだ。
コメント