VPNの「皮」を被ったザル：DNSリークが暴くネットワーク設計の甘さとその克服
VPNを接続していれば「匿名化は万全だ」と信じているのなら、それはネットワーク層のパケットが語る現実を知らない証拠だ。カフェのフリーWi-Fiでコーヒーを片手にVPNをONにし、満足げに業務をこなすエンジニアの背後で、DNSクエリが暗号化トンネルの脇をすり抜け、ISPのログサーバーへ直行している光景を想像してみてほしい。
これは単なる設定ミスではない。OSのルーティングスタックと、現代の複雑な名前解決メカニズムが引き起こす、極めて深刻な「情報の漏洩」だ。
DNSリークという「穴」の正体
DNSリークの本質は、OSのルーティングテーブルにおいて、デフォルトゲートウェイへの優先度がVPNインターフェース（tun0等）よりも物理インターフェース（eth0やwlan0）のDNS設定に置かれてしまうことにある。
多くのOSにおいて、DNSクエリはアプリケーションからのOS APIコール（getaddrinfo等）を通じて発行されるが、この際、どのDNSサーバーを使うかは、OSのネームサーバーリスト（/etc/resolv.conf）に依存する。VPNクライアントがトンネルを構築しても、このリストが適切に書き換えられない、あるいは「スプリットトンネリング」の設定が甘く、ローカルのDNSサーバーが優先されてしまう場合、パケットはVPNの暗号化の傘下に入ることなく、平文でISPへ流出する。
これは、あなたがどれほど強固なAES-256-GCMのトンネルを築こうが、宛先ドメイン名という「閲覧ログ」が筒抜けであることを意味する。
パケットレベルで紐解く「漏洩」の構造
パケットキャプチャを眺めれば、その挙動は残酷なまでに明らかだ。VPNトンネルの中を通るはずのUDP/53パケットが、突如として物理デバイス側のゲートウェイから送出される。
この事象を防ぐためには、単にVPNを繋ぐだけでは不十分だ。以下の3つのレイヤーで防御を固める必要がある。
1. systemd-resolved との格闘
現代のLinuxディストリビューションは、多くの場合 systemd-resolved が名前解決を管理している。これが厄介なのは、リンク固有のDNSサーバー設定を優先する傾向があることだ。
対策として、VPN接続時にDNSサーバーを強制的にトンネル内へ向ける設定を行う。以下は、NetworkManagerを利用した際の設定例だ。
# VPN接続時に、指定したDNSサーバーのみを使うよう設定（nmcli例）
nmcli connection modify "MyVPN" ipv4.dns "10.8.0.1"
# DNSの自動割り当てを無効にし、強制的にVPN経由のDNSを指定する
nmcli connection modify "MyVPN" ipv4.ignore-auto-dns yes2. ルーティングテーブルの「要塞化」
次に、OSレベルで「VPNトンネル以外を通るDNSパケットを破棄する」というポリシーを適用する。iptables または nftables を使い、物理インターフェースからのUDP/53パケットを強制DROPするルールを追加する。
# 物理インターフェース(wlan0)からのDNSクエリを遮断する（緊急避難用）
iptables -A OUTPUT -o wlan0 -p udp --dport 53 -j REJECT
iptables -A OUTPUT -o wlan0 -p tcp --dport 53 -j REJECTパフォーマンスとセキュリティの二律背反を解消する
DNSリークを防ぐだけでは、インフラアーキテクトとしては片手落ちだ。VPN利用時のRTT（往復遅延時間）の増大は、ユーザー体験を損なう最大の要因となる。
TLSハンドシェイクの最適化とMTUチューニング
VPNによるカプセル化は、IPヘッダーのオーバーヘッドを生む。これに起因するパケットの断片化（Fragmentation）を避けるために、MTU（最大転送単位）を最適化することは必須だ。
# インターフェースのMTUを調整し、断片化によるパフォーマンス低下を防ぐ
ip link set dev tun0 mtu 1360また、TCPバッファのチューニングも重要だ。VPNトンネル内での通信では、デフォルトのTCPウィンドウサイズでは帯域を使い切れないことが多い。
# sysctlでのTCPバッファ最適化
# ネットワークの遅延が大きいVPN環境下でのスループット改善
sysctl -w net.ipv4.tcp_rmem="4096 87380 6291456"
sysctl -w net.ipv4.tcp_wmem="4096 16384 4194304"結論：ゼロトラストの思想を個人の端末へ
DNSリークを「うっかりミス」で片付けてはならない。これは、ネットワークの境界が曖昧になった現代において、端末そのものが「信頼できないネットワーク」を前提に動くべきだという、ゼロトラストの原則を突きつけている。
もしあなたが技術者として、VPNを通したはずのDNSクエリが物理層へ漏れ出していることに気づいたなら、それは構成を見直す絶好のチャンスだ。DNS over HTTPS (DoH) の採用や、VPNトンネル内でのDNSリゾルバの構築など、レイヤーを跨いだ多層防御の検討を強く推奨する。
パケットは嘘をつかない。あなたのネットワークの安全性は、設定ファイルの1行、カーネルパラメータの小さな調整に宿っているのだ。
コメント