はじめに（この記事で分かること）#

VPNの接続は、思っているより頻繁に切れる。Wi-Fiからモバイル回線への切り替え、ルーターの再起動、スリープからの復帰、アプリの更新。そのたびに、端末は数秒から数十秒、VPNを通さずにインターネットへ出られる状態になりうる。Private Internet Access（PIA）のヘルプは、回線が戻ったときに「VPNより先に端末がインターネットにつながり、短時間通信が露出して実IPが見える場合がある」と、この隙間をそのまま書いている。

キルスイッチは、この隙間を塞ぐための仕組みだ。ただし、名前が同じでも中身は事業者とOSごとに違い、「キルスイッチをオンにした」だけでは、どの場面を塞いだのかが分からない。この記事では、2019年に摘発された闇市場Wall Street Market（WSM）の訴状が記した「VPNが切れた間の露出」を起点に、キルスイッチが止めるものと止めないもの、アプリ・OS・ルーターという3つの層の違い、Ubuntu 26.04 LTSでの設定例、そして自分で回線を切って漏れを観測する手順を扱う。

前提: 脅威モデルの整理#

脅威モデル入門では、隠す相手をISP、プラットフォーム、広告網、法執行機関、標的型攻撃者の5つに分けた。キルスイッチが守るのは、このうち「接続先に実IPが届くこと」だけである。

ISPに対しては、キルスイッチは何も隠さない。VPNを使っていてもいなくても、ISPは契約者が通信している事実と時刻を見ている。キルスイッチが効くのは、通信の向こう側、つまりログインしたサービスや書き込んだ掲示板、アクセスした自分のサーバーが接続元IPを記録する場面だ。日本の発信者情報開示は、プラットフォームが記録した接続元IPとタイムスタンプから始まる。VPNが切れていた数十秒の間に送られたリクエストが一つでもあれば、その記録には実IPが残る。

広告網に対しては、効果は小さい。広告網はIPアドレスよりもCookieやブラウザの特徴で利用者をつなぐので、IPが一瞬漏れても失うものは限られる。一方、標的型攻撃者が接続先を用意できる立場にある場合、たとえば相手が送ってきたリンクの先が相手のサーバーなら、漏れは一度で足りる。法執行機関については、次の節のWSMがまさにその例になる。

相手キルスイッチの効き方
ISP効かない。通信の事実・時刻・量は見えたまま
プラットフォーム・自分のサーバー効く。切断中のリクエストが実IPで記録されるのを防ぐ
広告網小さい。主な識別手段はCookieとブラウザの特徴
法執行機関効く範囲がある。ただし接続先の記録以外の経路（支払い、端末押収）は別問題
標的型攻撃者相手が接続先を用意できる場合に効く

切れた瞬間に何が漏れるか#

経路表が元に戻る#

VPNアプリは、接続するときにOSの経路表（どの宛先への通信をどのインターフェースから出すかの表）を書き換え、既定の出口をトンネルのインターフェースに向ける。WireGuardの公式解説は、この書き換えの方式を何通りも紹介している。既定経路を置き換える方式、0.0.0.0/1と128.0.0.0/1の2本で既定経路を上書きする方式、そしてwg-quickが使う、fwmark（パケットに付ける印）とポリシールーティングを組み合わせる方式だ。wg-quickの方式では、WireGuard自身が送る暗号化済みのUDPパケットにだけ印を付け、印のないパケットはすべてトンネル用の経路表へ送る。

どの方式でも、トンネルのインターフェースや経路が消えれば、OSの経路表には元のWi-Fiや有線の既定経路だけが残る。アプリはそのまま通信を続け、パケットは何事もなかったように物理インターフェースから出ていく。ブラウザの画面には何の変化もない。これが「切れた瞬間に漏れる」の正体で、漏れるのは接続先から見た送信元IPアドレス、つまりISPが割り当てた実IPだ。DNSの問い合わせ先も通常の設定に戻るので、名前解決もISPやルーターのDNSに向かう（DNS側の詳細はDNSリークの記事で扱う）。

一方で、トンネルが「途切れた」だけでインターフェースが残っている場合は事情が違う。wg-quickの方式なら、印のないパケットは引き続きトンネル用の経路表に送られるので、サーバーが応答しなくなってもパケットはトンネルに入って届かないだけになる、と仕組みからは読める（筆者の解釈で、実際の挙動は後述の手順で確かめてほしい）。漏れが起きやすいのは、アプリが再接続のためにトンネルをいったん壊す時、利用者が手で切断した時、端末の起動直後でVPNがまだ立ち上がっていない時である。

WSMで起きたこと#

米司法省が2019年5月1日付で公開した刑事訴状の第23項は、こう記している。ドイツ連邦刑事庁（BKA）の捜査で、WSMの管理者たちが主に二つのVPN事業者を通じて市場の設備にアクセスしていたことが分かった。BKAは、管理者だけが触れられる管理機能にアクセスしていた一人がVPN Provider #1を使っていたと判断した。そして、WSMのサーバー設備を分析する中で、BKAは「VPN Provider #1 connection would cease」、つまりこの接続がときどき途切れていたことに気づいた。その管理者がそれでもWSMの設備にアクセスし続けたため、そのアクセスが管理者の実IPを露出させた（原文は「exposed the true IP address of the administrator」）。

訴状はその先も記している。露出したIPアドレスはドイツの通信事業者のもので、その回線を使っていたのはUMTSスティック（モバイル回線用のUSBモデム）だった。このスティックは「registered to a suspected fictitious name」、偽名と疑われる名義で登録されていた。BKAは2019年1月17日から2月7日にかけて複数の監視措置でこのスティックの位置を割り出し、2月5日から7日に、スティックが運営者の自宅と勤務先で使われていたことを確認した（第24項）。逮捕時の所持品にもUMTSスティックがあった（第33.a項）。

ここから読み取れることと、読み取れないことを分けておく。訴状から確かに言えるのは、VPNの接続が途切れていた間のアクセスが、押収・分析されたサーバー側の記録に実IPとして残ったことだ。訴状は、接続が途切れた理由も、その管理者がどのVPNアプリを使い、キルスイッチに当たる機能を有効にしていたかも書いていない。したがって「キルスイッチがあれば防げた」と断定する根拠は訴状にはない。筆者の読みとしては、切断中の通信を遮断する仕組みが働いていれば、少なくともこの経路での露出は起きにくかったと考えられる。ただしその場合も、偽名のUMTSスティックという回線の選び方や、他の運営者を特定した別の痕跡（ケーススタディを参照）には何の影響もない。

もう一つ見落とされやすい点がある。実IPを記録したのは、VPN事業者でもISPでもなく、接続先であるWSM自身のサーバーだった。キルスイッチの議論はVPNの側に目が行きがちだが、漏れを「見る」のは常に接続先である。

キルスイッチの3つの実装#

キルスイッチと呼ばれるものは、どこで遮断するかによって、アプリ、OS、ルーターの3つの層に分かれる。層が違えば、塞げる隙間も違う。

アプリ内のキルスイッチ#

VPN事業者のアプリが、OSのファイアウォールや経路を操作して、トンネル以外の通信を止める方式だ。各社の公式ヘルプを読み比べると、名前の違いの裏に共通の分かれ目が二つある。「予期しない切断のときだけ止めるか、VPNにつながっていない間はずっと止めるか」と、「アプリを閉じた後や端末の起動時まで止めるか」である。

Mullvadのアプリでは、組み込みのキルスイッチは常に有効で、設定から無効にできない。ヘルプによれば、遮断は「Connect」を押した時点から利用者が切断するまで続き、接続の失敗、接続中の契約期限切れ、起動時の接続確立中、端末の回線断の各場面で「BLOCKING INTERNET」と表示して通信を止める。ただし、利用者が「Disconnect」を押したり、アプリを終了したりした後は遮断されない。そこまで止めるのが任意の「Lockdown mode」で、ヘルプはこれを有効にすると端末がインターネットに出るのに「常にMullvadのVPN接続を必要とする」と説明している。スプリットトンネルの対象にしたアプリは、Lockdown modeでも通信できる。

Proton VPNは二段構えだ。標準のキルスイッチは「接続が誤って切れたときだけ作動する」もので、Windows版とLinux GUI版で有効にしたときに選ばれるのはこちらだ。LinuxのCLI版は標準のみに対応する。「Advanced kill switch」はProton VPNに接続している時だけインターネットを許可し、端末を再起動しても有効なまま残る。対応はWindows、Linux GUI、iOS/iPadOS（ベータ）である。同じヘルプは、macOSではサーバーを切り替える際に実IPが露出しうる短い時間があること、Appleのサービスの一部のDNS問い合わせはキルスイッチを有効にしてもVPNを迂回しうることを明記している。

ExpressVPNの現在のヘルプは、この機能を「Internet Kill Switch」と呼んでいる。ヘルプ自体は旧称に触れていないが、機能ページのURLとLinuxのコマンドにはnetwork-lock・networklockの名が残っており、以前「Network Lock」と呼ばれていた機能とみられる。既定で有効で、接続中・接続済み・再接続中・接続失敗の間は通信を止めるが、利用者が自分で切断した場合は止めない。ヘルプは、接続中にこの機能が有効になるまで「数秒かかる場合がある」とも書いている。Windows、Mac、Linuxには、VPN接続中以外のすべての通信を止める「Advanced Internet Kill Switch」がある。ローカルネットワークの機器には既定でアクセスできる。

NordVPNのWindows版には、VPNから切断されると通信を切る「Internet Kill Switch」と、指定したアプリを終了させる「App Kill Switch」がある。App Kill Switchは既定で無効だ。Linux版はnordvpn set killswitch onで有効にし、予期しない切断でも手動の切断でも端末全体の通信を止める。App Store版のmacOSとiOSでは、同等の機能が「VPN bypass prevention」という名前になっている。

PIAの「VPN Kill Switch」は既定で有効で、VPNが切れたときに接続が戻るまで通信を止める。Windows版の「Advanced Kill Switch」は、切断に反応するのではなくVPN接続をインターネット利用の条件にするもので、PIAのアプリを閉じていても働く。AirVPNは同種の機能を「Network Lock」と呼び、すべてのソフトウェアで使えるとFAQに書いている（詳細はAirVPNのレビュー）。

事業者切断時に止める機能手動切断・アプリ終了後も止める機能公式ヘルプの注記
Mullvad組み込みのキルスイッチ（常に有効、無効化不可）Lockdown mode（任意）スプリットトンネル対象のアプリは通信できる
Proton VPN標準のキルスイッチAdvanced kill switch（Windows、Linux GUI、iOS/iPadOSベータ）macOSのサーバー切替時の短い露出、Appleサービスの一部DNS
ExpressVPNInternet Kill Switch（既定で有効）Advanced Internet Kill Switch（Windows、Mac、Linux）有効になるまで数秒かかる場合がある。LANは既定で許可
NordVPNInternet Kill Switch（Windows）、LinuxのkillswitchLinuxのkillswitchは手動切断でも遮断App Kill Switchは既定で無効
PIAVPN Kill Switch（既定で有効）Advanced Kill Switch（Windows）回線復帰時にVPNより先につながる隙間を説明
AirVPNNetwork Lock—全ソフトウェアで利用可（FAQ）

表は2026-11-08時点の各社ヘルプの記述で、アプリの版によって名前も挙動も変わる。自分の端末で確かめる手順は後の節で扱う。

アプリ内の実装が止めないものも、各社のヘルプから読み取れる。手動で切断した後（標準の設定のまま）、アプリを終了した後（同）、スプリットトンネルで外したアプリ、許可されたローカルネットワーク宛ての通信、そしてアプリ自体が動いていない間だ。アプリが更新中に止まる、クラッシュする、といった場面の挙動は、どの事業者のヘルプにも一般的な形では書かれていない。

OSのファイアウォールと設定#

二つ目の層は、OS自体が「VPN以外の通信を許さない」と決める方式だ。

Androidは、Android 7.0以降で「常時接続VPN（Always-on VPN）」を持ち、端末の起動時にVPNサービスを立ち上げて動かし続けられる。Android Developersの説明では、利用者は設定の「ネットワークとインターネット」→「VPN」にあるVPNの設定パネルで「VPNなしの接続をブロック（Block connections without VPN）」を有効にでき、システムはVPNを使わない通信をすべて遮断する。アプリの外で、OSが遮断するのが強みだ。ProtonとNordVPNのヘルプも、Androidでは自社のキルスイッチがこのOSの仕組みに近い働きをすると説明している。

ただし、OSの遮断にも例外がある。Mullvadは2022年10月10日のブログで、「VPNなしの接続をブロック」を有効にしていても、AndroidはWi-Fiにつないだ際の接続確認（connectivity check）の通信をトンネルの外に送ると報告した。DNSの問い合わせとHTTP(S)の通信が含まれ、利用者向けの設定では止められず、アプリ側では直せないとしている。また、VPNアプリが許可リストや除外リストを使って一部のアプリをVPNの外に出している場合、そのアプリはOSの遮断の対象から外れる。

iOSとmacOSでは、VPNアプリがincludeAllNetworksという設定を使うと、システムはほとんどの通信をトンネルに通す。Appleの開発者向け文書（iOS 14以降、macOS 10.15以降）は、この設定でも常にトンネルの外に出る通信として、DHCPのようにローカルネットワークへの接続を保つ制御通信、Wi-Fiのキャプティブポータルの認証、VoLTEのような携帯回線専用のサービス、Apple Watchのような周辺機器との通信を挙げている。

iOSには、既存の接続の問題も記録されている。Proton VPNは2020年3月25日、iOS 13.3.1で、VPNに接続しても既に開いていた接続が閉じられず、トンネルの外で通信を続ける問題を公表した。例として挙がったのはAppleのプッシュ通知サービスで、iOSはVPNアプリに既存の接続を切る権限を与えていないため、どのVPN事業者も回避策を提供できないとしている。同じ記事の追記によれば、AppleはiOS 14で開発者向けにキルスイッチの仕組みを提供したが、2022年8月18日の検証では、Appleのサービスの一部のDNS問い合わせはなおVPNの外から送られ、接続によっては数分から数時間トンネルの外に残った。Appleはこの通信を「expected（想定どおり）」とし、Always On VPNは管理（MDM）下の監視対象デバイスでのみ使えると説明している。

LinuxではOSのファイアウォール（nftables）を自分で書ける。これが次の節の主題になる。

ルーターの迂回防止#

三つ目の層は、家庭やオフィスのルーターでVPNを終端し、トンネルが落ちたらWANに出さない方式だ。プライバシーのためのネットワーク機器で扱ったように、利点はVPNアプリを入れられないIoT機器や来客の端末まで同じ規則で縛れることにある。ただしQubesをVPNルーターの後ろに置く記事で確認したとおり、OPNsenseの公式手順でもキルスイッチは任意の追加設定で、トンネルを作っただけでは有効にならない。IPv6と、ルーター自身が上流へ送るDNS問い合わせも別に確認が要る。

ルーターの層が止めないものも明確だ。スマートフォンを持って家を出てモバイル回線に切り替わった瞬間、ルーターの保護は届かない。ルーターより手前、つまりLAN内の他の機器から見える情報も隠れない。端末側とルーター側は置き換えではなく重ね合わせる関係で、外に持ち出す端末には端末側の遮断が別に要る。

Ubuntu 26.04での確認#

Ubuntu 26.04 LTSでWireGuardをwg-quickで使う場合の、遮断の作り方を3つ示す。前提のパッケージの版は、Ubuntuのマニュアルページで確認できる範囲でwireguard-tools 1.0.20250521、nftables 1.1.6、ufw 0.36.2である。以下はいずれも設定例で、インターフェース名（wg0）、VPNサーバーのIPアドレス（203.0.113.10）、ポート（51820）は自分の環境に読み替える。筆者はこの記事のために各例をUbuntu 26.04上で検証していない。構文はUbuntu 26.04のマニュアルページで確認したが、入れた後は次の節の手順で必ず実測してほしい。

方法1: wg-quickのPostUp/PreDown#

wg-quickのマニュアルページには、「いわゆるキルスイッチ」として次の2行を[Interface]に加える例が載っている。

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

%iはインターフェース名に置き換わる。規則の意味は「トンネル以外から出ていき、WireGuardの印も付いておらず、宛先がローカルでもないパケットを拒否する」で、マニュアルは、AllowedIPsに0.0.0.0/0を含む構成でwg-quickのfwmarkと組み合わせて働くと説明している。IPv6を使うならip6tablesで同様の行を加える必要があるとも書いている。DHCPの多くはPF_PACKETソケットを使うのでこの規則を素通りする、という注記もある。Ubuntu 26.04のiptablesパッケージにはnftablesの仕組みの上で動くiptables-nftが含まれる。

この方式には構造上の穴がある。規則はトンネルを立ち上げた後（PostUp）に入り、トンネルを下ろす前（PreDown）に消える。つまりwg-quick down wg0を実行した後、端末を起動してからトンネルを上げるまでの間、そしてwg-quickが途中で失敗した場合は、規則が存在しない。守れるのは「トンネルが上がっている間にサーバーへ届かなくなった」場面に限られる。

方法2: トンネルと無関係に常駐するnftablesの表#

トンネルの上げ下げと関係なく、常に「wg0とVPNサーバー宛て以外は出さない」表を置く方法だ。

#!/usr/sbin/nft -f
# /etc/nftables.d/killswitch.nft（設定例）
destroy table inet killswitch   # 既存の表があれば消す（無ければ何もしない）

table inet killswitch {
    chain output {
        type filter hook output priority filter; policy drop;

        oifname "lo" accept
        oifname "wg0" accept

        # VPNサーバー（wg0.confのEndpointはホスト名でなくIPアドレスで書く）
        ip daddr 203.0.113.10 udp dport 51820 accept

        # LAN内の機器（プリンター等）に届く必要がある場合だけ、範囲を絞って足す
        # ip daddr 192.168.1.0/24 accept
    }
}

inetの表はIPv4とIPv6の両方に効くので、トンネルがIPv4だけを運ぶ構成でも、物理インターフェースからIPv6で直接出る通信はここで止まる。oifnameを使うのは、nftのマニュアルが説明するとおり、名前で照合する規則はインターフェースがまだ存在しなくても追加でき、後から同名のインターフェースが作られれば再び一致するからだ。wg0が消えている間は「wg0から出る」に一致する通信がなく、VPNサーバー宛て以外はすべて既定のdropに落ちる。Endpointをホスト名で書くと、トンネルを上げる前のDNS問い合わせがこの規則で止まるので、IPアドレスで書いておく。

読み込みと確認は次のとおりだ。

sudo nft -c -f /etc/nftables.d/killswitch.nft   # 構文の確認のみ
sudo nft -f /etc/nftables.d/killswitch.nft
sudo nft list table inet killswitch

UFWと同時に使った場合の振る舞いも、nftのマニュアルから読める。同じフックに複数の基本チェーンがあるとき、どれか一つがdropを出せば、他のチェーンがacceptしていても最終的に破棄される。この表を置けば、UFW側の規則が通信を許していても、ここで落ちる。

起動時に自動で読み込むにはnftables.serviceを使う。ただし、Ubuntu 26.04のnftablesパッケージが入れる既定の/etc/nftables.confは先頭にflush rulesetがあり、これを読み込むと他の仕組み（UFWを含む）が入れた規則まで消える。既定ファイルをそのまま使うのではなく、中身を確認し、include "/etc/nftables.d/killswitch.nft"を足す形に整えてからsudo systemctl enable nftables.serviceを実行する。起動直後に本当に隙間がないかは、再起動して確かめる以外に確実な方法がない。

方法3: UFWで外向きを既定で拒否する#

UFWは、インストール直後は外向き（outgoing）の既定が「許可」になっている。これを「拒否」に変え、wg0とVPNサーバー宛てだけを許可する。

sudo ufw default deny outgoing
sudo ufw allow out on wg0 from any to any
sudo ufw allow out proto udp to 203.0.113.10 port 51820
sudo ufw enable
sudo ufw status verbose

UFWのIPv6対応は既定で有効なので、同じ規則がIPv6にも適用される。UFWのstatusは、/etc/ufwの規則ファイルに書かれた規則までは表示しないので、全体を確認したいときはsudo ufw show rawを使う。

NetworkManagerで取り込んだ場合#

Ubuntuのデスクトップでは、WireGuardの設定をNetworkManagerに取り込んで使うこともできる。NetworkManagerのWireGuard設定項目（Ubuntu 26.04のnm-settings-nmcli）には、fwmark、既定経路の特別扱い、ポート、MTU、ピアの経路などがあるが、wg-quickのPostUp/PreDownに当たる項目はない。この場合、方法1は使えないので、方法2か方法3のように接続と無関係に常駐する規則で遮断する。

DNSの扱いは、wg-quickのDNS=がresolvconfを呼ぶ点を含めてDNSリークの記事に譲る。キルスイッチで外向きを止めていれば、トンネル外へのDNS問い合わせも止まるが、それは「漏れない」というより「名前解決が失敗する」形で現れる。

自分で切って検証する#

設定を入れただけでは、どの場面を塞げたのかは分からない。回線を意図的に切り、物理インターフェースから何が出ていくかを観測する。対象は自分の端末と、自分が契約している回線に限る。

  1. 物理インターフェースの名前を調べる。ip -br linkで、Wi-Fiならwlpで始まる名前、有線ならenpで始まる名前が多い。以下ではwlp2s0とする。
  2. tcpdumpを入れ（sudo apt install tcpdump）、別の端末画面で、VPNサーバーとの暗号化通信以外を表示させる。 
    sudo tcpdump -ni wlp2s0 'not (udp and host 203.0.113.10 and port 51820) and not arp'
  3. さらに別の画面で、1秒ごとに外から見えるIPアドレスを確認する。MullvadのヘルプがIP確認用として挙げるam.i.mullvad.netを使う例だ（他の確認サイトでもよい）。 
    while true; do date +%T; curl -4 -s --max-time 3 https://am.i.mullvad.net/ip || echo "v4: blocked"; curl -6 -s --max-time 3 https://am.i.mullvad.net/ip || echo "v6: blocked"; sleep 1; done
  4. 次の場面を一つずつ再現し、tcpdumpに通信が出るか、IPの表示が実IPに変わるかを記録する。
    • Wi-Fiを切って戻す（nmcli radio wifi off、数秒後にnmcli radio wifi on）
    • トンネルを手で下ろす（sudo wg-quick down wg0。事業者アプリなら「切断」ボタン）
    • アプリを終了する（事業者アプリの場合）
    • 端末を再起動し、VPNを上げる前に3の確認を走らせる
    • VPNサーバーに届かない状態を作る（ルーター側で一時的にサーバー宛てを止められるなら）
  5. 観測が終わったら、tcpdumpとループを止め、遮断の規則を一時的に外していた場合は元に戻す。

読み方は単純だ。遮断が効いていれば、tcpdumpに出るのはDHCPや、ルーターから届くIPv6のルーター広告のようなローカルの制御通信だけで、確認ループは「blocked」を返す。ここで実IPが一度でも表示された場面が、その設定で塞げていない隙間である。方法1の設定なら、手で下ろした場面と再起動直後に実IPが出るはずで、それは設定が壊れているのではなく、この方式の守備範囲の外だということを示している。

見落としやすいのがIPv6だ。VPNがIPv4しか運ばない構成で、回線側にIPv6がある場合、IPv4の表示はVPNのIPのままでも、IPv6の問い合わせは実回線から出ていることがある。確認ループでIPv4とIPv6を分けているのはこのためだ。DNSについては、tcpdumpに53番ポート宛ての通信が出ていないかを見ればよい。ブラウザ単位の漏れ（WebRTC）は、端末全体の遮断とは別の話なのでWebRTCリークの記事で確認する。点検の全体の順序は匿名性のセルフチェックにまとめてある。

限界と残るリスク#

キルスイッチは「トンネルが無い時に外へ出さない」仕組みであって、トンネルがある時の通信の中身や行き先の正しさは何も保証しない。その意味で、守備範囲の外にあるリスクがいくつかある。

一つ目は、トンネルが生きたまま経路だけを曲げられる攻撃だ。2024年5月6日に公開されたCVE-2024-3661（TunnelVision）について、NVDの説明は、DHCPのオプション121で経路表に経路を足され、経路に頼るVPNが物理インターフェースへ通信を漏らしうるとしている。発見者のLeviathan Securityは、このときVPNの制御用の通信は生きているので「キルスイッチのような機能は作動しない」と書き、影響はWindows、Linux、iOS、macOSに及び、オプション121に対応しないAndroidは影響を受けないとした。物理インターフェースの通信を止める対策は、その経路の通信を止める（届かなくする）形でしか効かず、Linuxのネットワーク名前空間なら完全に防げるとも述べている。2023年のTunnelCrack（USENIX Security 2023）も、悪意あるWi-Fiが公開アドレスの範囲をLANとして割り当て、LAN宛ての例外を利用して通信をトンネルの外へ出させる攻撃を示し、利用者側の緩和策としてローカルネットワークへのアクセスを無効にすることを挙げている。各社のアプリがLAN宛てを既定で許可しているかどうかは、ここで効いてくる。

二つ目は、OS自身が例外として外に出す通信だ。Androidの接続確認、iOSとmacOSのAppleサービスの一部、includeAllNetworksでも除外される制御通信は、利用者のキルスイッチ設定では止められない。

三つ目は、遮断の副作用だ。外向きを既定で止めると、ホテルやカフェのキャプティブポータルの認証画面が開けない、LANのプリンターに届かない、VPN事業者の障害時に何もできない、といったことが起きる。その不便さに負けて遮断を外した瞬間が、いちばん危ない。WSMの訴状が記したのも、接続が途切れた後に作業を続けた結果だった。

最後に、キルスイッチは実IPの露出を一つの経路で減らすだけで、匿名を約束するものではない。アカウント、支払い、文体、端末の指紋といった他の経路は、VPNの匿名性とIPアドレスの特定で扱ったとおり、キルスイッチとは無関係に残る。

まとめ#

広告やトラッキングを減らしたいだけの人（beginner）なら、使っているVPNアプリのキルスイッチが既定で有効かを確認し、Wi-Fiを一度切って戻して、IP確認サイトの表示が実IPに変わらないかを見るところまでで十分だ。Androidを使っているなら、OSの設定で「常時接続VPN」と「VPNなしの接続をブロック」を有効にしておくのが合理的である。

取材源や身元を守る立場（journalist）なら、「予期しない切断のときだけ止める」標準の設定では足りない。手動の切断後やアプリ終了後、起動直後も止める設定（MullvadのLockdown mode、ProtonのAdvanced kill switch、PIAのAdvanced Kill Switchなど）を選び、iPhoneではAppleサービスの通信がトンネル外に出る既知の制約を前提に、機微な作業をする端末を選ぶ。

サーバーの管理やリモート作業にVPNを使う人（developer）は、WSMの構図にいちばん近い。接続先が自分のサーバーであっても、そのログは押収や侵害で第三者の手に渡りうる。Ubuntuなら方法2のようにトンネルと無関係に常駐する遮断を置き、今日、wg-quick downと再起動の2つの場面で実IPが出ないことを自分の目で確かめておくのが合理的だ。

出典#

参照日はいずれも2026-11-08。