VPNの「切断」を許すな：キルスイッチのパケットフィルタリングとOS内部の攻防
カフェの公共Wi-Fiでコーヒーを片手に、VPNを張ってセキュアな作業に没頭する。この光景は現代のデジタルノマドの象徴だが、ネットワークスペシャリストとして言わせれば、VPNの「コネクション」を過信するのは禁物だ。
VPN接続が不安定な瞬間に何が起きるか。トンネルがダウンしたコンマ数秒の間、OSは律儀にも「デフォルトゲートウェイ」へ向かって、暗号化されていない剥き出しのパケットを放流する。これが「パケット漏洩（Leakage）」の正体だ。今回は、この脆弱性をカーネルレベルでどう封じ込めるのか、その実装の深淵を紐解いていこう。
—
キルスイッチの正体：ファイアウォールによる「強制遮断」
キルスイッチとは、単なる「接続監視」の機能ではない。OSのパケットフィルタリングエンジン（Linuxなら iptables や nftables、macOSなら pf）を動的に操作し、VPNトンネルを通らない通信をすべて「Drop」するステートフルなガードレールだ。
nftablesによる実装の最適化
現代のLinuxにおけるパケットフィルタリングの最適解は nftables だ。VPNが確立された瞬間、あるいは切断された瞬間に、カーネル空間のフィルタールールを更新する。以下は、VPNの仮想インターフェース（例: tun0）以外の全アウトバウンド通信を遮断する、最もプリミティブかつ堅牢なルール定義だ。
# テーブルの作成
sudo nft add table inet vpn_killswitch
# VPNインターフェース（tun0）以外からの通信をすべてドロップするチェーンを作成
sudo nft add chain inet vpn_killswitch output { type filter hook output priority filter \; }
# VPNインターフェースへの通信を許可
sudo nft add rule inet vpn_killswitch output oifname "tun0" accept
# VPNインターフェース以外への出力は即座にDrop
# これにより、VPN切断時のリークを物理的に封じる
sudo nft add rule inet vpn_killswitch output dropこの設定の肝は、priority filter を適切に設定することで、カーネルのネットワークスタックにおける処理順序を制御し、パケットがルーティングテーブルに到達する前に判定を下す点にある。
—
パケットの生存戦略：RTT削減とTCPバッファチューニング
VPNを導入すると、トンネルという「カプセル」を通る分だけオーバーヘッドが生じ、RTT（Round Trip Time）は必然的に増大する。これを補うには、トランスポート層のチューニングが不可欠だ。
特に、VPN経由でTLSハンドシェイクを行う際、TCP Fast Open や BBR 輻輳制御アルゴリズムの併用がパフォーマンスを左右する。Linuxカーネルの sysctl 設定で、VPNのボトルネックを解消するチューニングの例を挙げる。
# パケットのキューイング遅延を最小化（BBR輻輳制御の有効化）
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr
# TCPウィンドウサイズを拡大し、高遅延環境でのスループットを維持
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"
# TCP Fast Openを有効化し、ハンドシェイクのRTTを1往復分削減
sysctl -w net.ipv4.tcp_fastopen=3これらは、VPNという仮想的な境界を守りつつ、物理回線の制約をギリギリまで引き出すための「実務的な処方箋」だ。
—
なぜ「生のパケット」は漏れ出るのか
VPNソフトの多くは、アプリケーション層やユーザー空間で動作している。しかし、OSのルーティングテーブルはカーネル空間にある。VPNプロセスがクラッシュしたり、OSがサスペンドから復帰した瞬間、ルーティングテーブルの書き換えが物理インターフェース（wlan0 など）の再認識よりも遅れることが多々ある。
この「競合」を解消するためには、ユーザー空間のロジックに頼るのではなく、カーネルレベルのフィルタリングルールを「デフォルト・クローズド」にすることが唯一無二の正解となる。
セキュリティの深層：ヘッダー圧縮とトラフィック解析
VPNプロトコル（特に WireGuard や OpenVPN）において、ヘッダー圧縮は帯域節約だけでなく、トラフィックのメタデータ解析に対する防衛策にもなり得る。TLSの ALPN（Application-Layer Protocol Negotiation）で適切なプロトコルを即座に特定し、無駄なハンドシェイクを省くことは、セキュリティ上の攻撃対象領域（アタックサーフェス）の削減にも寄与する。
—
現場のエンジニアへ送るアドバイス
あなたがインフラアーキテクトであれば、VPNクライアントの「オン/オフ」というUI上のスイッチを信じてはいけない。真のキルスイッチは、OSの nftables や pf の設定値そのものだ。
もしあなたが大規模な社内ネットワークを管理しているなら、エンドポイントのキルスイッチ設定を Ansible 等の構成管理ツールで強制配布し、VPNインターフェースがダウンしているデバイスは、社内リソースへ一切のパケットを通さないようなネットワークアクセスコントロール（NAC）を並行して運用することを強く推奨する。
ネットワークは「壊れるもの」という前提に立ち、壊れた瞬間に何をすべきかをコードで記述する。それが、我々エンジニアに課せられた最小にして最大の責務である。
コメント