ova
ブログに戻る
·9分で読める·productdevbook

macOSでVPNの通信量をモニタリングする方法

macOSでVPNトンネルが何を運んでいるかを正確に把握する方法。アプリ別トラフィック、暗号化オーバーヘッド、リーク検出までを解説します。

  • VPN
  • macOS
  • Bandwidth
  • Privacy

VPNに接続し、正しい国を報告するウェブチェックを実行して、すべてがトンネル経由になったと思い込みます。2日後、あるアプリ——たとえば古いチャットクライアントや同期エージェント——がずっと公衆インターネットと直接話していて、トンネルを完全に無視していたことに気づきます。VPNはオンでした。リークは、トンネルが立ち上がる前に物理インターフェースにバインドして手放さなかったプロセスにあったのです。

macOSでVPNの通信量をモニタリングすることは、一部はVPNが仕事をしていることの確認、一部はVPNを静かに迂回するアプリを捕まえることです。本稿はutunインターフェースが実際何か、組み込みツールでVPNトラフィックを読む方法、リークを検出する方法、トンネルが追加するオーバーヘッドを測る方法をカバーします。VPN自身のダッシュボードが十分教えてくれないからmacOSでVPN通信量モニターを検索していたなら、下のツールキットがより難しい問いに答えます。

utunインターフェースとは何か

VPNクライアントがmacOSで接続すると、仮想インターフェース——通常utun0、utun1、utun2などと名付けられた——を作成します。(「utun」は「user tunnel」の略。)VPNプロセスはOSがそのインターフェースにルーティングしたパケットを読み、暗号化してカプセル化し、結果のラップされたパケットを物理インターフェース(通常Wi-Fiのen0)経由で書き出します。

現在何が立ち上がっているか見るには、ターミナルでこれを実行:

ifconfig | grep -E "^(en|utun)" -A 3

次のようなものが見えます:

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.42 netmask 0xffffff00 broadcast 192.168.1.255
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
        inet 10.8.0.6 --> 10.8.0.1 netmask 0xffffff00

en0は実ネットワーク。utun0はVPN。一部のVPNクライアントは複数のutunインターフェース(データプレーン用1つ、コントロール用1つ)を作ります。一部はiOSスタイルのインターネット共有トンネルとの衝突を避けるためにutun9以上を作ります。

nettopでmacOSのVPN通信量をモニタリングする方法

nettopはmacOSに組み込まれており、プロセスがどのインターフェースを使っているかを見る最も直接的な方法です。関連する呼び出し:

sudo nettop -P -m route

これは各プロセスの接続をルートでグループ化して表示します。VPN経由で話すプロセスはutunインターフェース経由のトラフィックを示し、トンネルを迂回するプロセスはen0(またはイーサネットならen1)経由を示します。

nettopを1分観察し、問います: どのアプリがutun0を使い、どのアプリがen0を使っているか? すべてをトンネル経由にする意図でen0上にSlackが見えるなら、それはリークです。

-Pフラグはプロセス別に集計、-m routeはルート列を表示。バイト数には-xを追加。-cと遅延を追加すると定期更新、例: nettop -P -c 2。

ovaがVPNトラフィックについて表示するもの

ovaのようなアプリ別モニターはnettopが見るのと同じカーネル統計を見て、時間とともに集計します。ovaで「Slack」に帰属する通信量は、Slackが送ったすべてを含みます——en0経由かutun0経由かはプロセス別合計を変えません。だからovaは「Slackはどれだけ使ったか?」にきれいに答えます。アプリ別の数字をインターフェース別に分解することは現在しません——その詳細レベルが必要ならnettopが正しいツールです。

ほとんどのVPNユーザーには問題ありません。通常答えてほしい問いは:

  • 「VPNクライアント自身は期待する通信量を使っているか?」
  • 「過去1時間に何かスパイクしたか?」
  • 「現在最も重いアプリはどれか?」

ovaはこの3つすべてに一目で答えます。ヘルパープロセスの折りたたみ付きで、SlackヘルパーPIDが別行として現れません。VPNクライアント自身(Tailscale、Mullvad、ProtonVPN、NordVPNなど)は独自の行として現れ、その数字は物理リンク経由で出ていくラップされた/暗号化された合計です。

アプリ別履歴
ovaはスクラブ可能な履歴を保持するので、VPNを有効にする前後の通信量を比較できます——差分が暗号化オーバーヘッドです。

リークを検出する

VPNリークとは、アプリのトラフィックがトンネルを迂回して直接インターネットに行くことです。原因:

  • アプリがVPN立ち上げ前にルートをキャッシュし、まだそれを使っている。
  • VPNが特定の宛先(LAN、マルチキャスト、特定サーバへのDNS)をルーティングしない。
  • macOSの「ローカルネットワークを除外」トグルがその通りに動いている。
  • VPNがスプリットトンネルされていて、特定のアプリがバイパスリストにある。
  • IPv6が有効でVPNがIPv4のみルーティングする(よくある原因)。

診断ループ:

  1. VPN接続済みで、nettop -P -m routeを実行し、トンネルされる予定だったのにen0トラフィックを示すプロセスを探す。
  2. プロセス別通信量についてovaと相互参照。プロセスがovaでトラフィックを示すがnettopにutun行がないなら、リークしています。
  3. ネットワークレベルで確認: ブラウザからipleak.netまたはdnsleaktest.comを訪問。報告されるIPは自宅/オフィスではなくVPN出口のはず。
  4. 特にDNSについては: scutil --dns | grep nameserverを実行——リストされるネームサーバはISPのではなくVPNのものであるべき。

特にIPv6については、最も安全なセットアップは明示的にIPv6をルーティングするVPNか、接続中にシステム全体でIPv6を無効化すること。ネットワークごとの無効化: システム設定 → ネットワーク → あなたのネットワーク → 詳細 → TCP/IP → IPv6を構成 → リンクローカルのみ。

VPNオーバーヘッドの測定

VPNはオーバーヘッドを2通りで追加します: スループット(実回線速度より少なくなる)とレイテンシ(各往復が追加のホップを通る)。

スループットオーバーヘッド

暗号化税はプロトコル次第:

  • WireGuard: 高速リンクで通常5〜10%のオーバーヘッド。Apple Siliconでハードウェアアクセラレート。
  • OpenVPN: 15〜30%のオーバーヘッド。CPU依存、高速ではWireGuardより遅い。
  • IKEv2/IPsec: 10〜20%のオーバーヘッド。macOSネイティブサポート。
  • 独自プロトコル(Lightway、WireGuardベースのNordLynxなど): おおむねWireGuardレベルの効率。

測定するには: VPNオフで速度テストを実行し、結果を記録。VPNオン時、オフテストエンドポイントと同じメトロエリアのサーバに対して同じテストを実行。比率がオーバーヘッドです。両テスト中にovaを使う——速度テストクライアントに表示されるアプリ別トラフィックはアプリケーション層スループット。VPNテスト中のシステム全体レートは暗号化フレーミングのため高くなります。

レイテンシオーバーヘッド

VPNオフでping 8.8.8.8を実行し、定常状態RTTを記録。VPNを接続し、再度ping 8.8.8.8。差分は暗号化、VPN出口への移動、戻りの往復コスト。典型的な数値:

  • 同じ都市のVPN出口: +5〜+15ms。
  • 別の国のVPN出口: 地理によって+50〜+200ms。
  • 別大陸のVPN出口: +150〜+400ms。

これはほとんど不可避な物理です——東京にトンネルして往復コストがかからないわけにはいきません。

VPN自身の通信量利用を特定する

VPNクライアントプロセス自身はovaに独自の行として現れます——「Mullvad VPN」、「Tailscale」、「ProtonVPN」など。そこに見える数字は物理リンク経由で出ていく暗号化されラップされた合計です。これが「VPNが消費している実インターネット通信量はいくらか」の正しい数字です。

便利な健全性チェック: いつでも、VPNが報告する通信量は、それを使う他のすべてのアプリの合計に暗号化オーバーヘッドのわずかな割合を加えたものとほぼ等しいはずです。大きく異なるなら何か別のことが起きています——スプリットトンネリング、リーク、またはVPNクライアントが保守作業(鍵ローテーション、ピア発見)を行っている。

ovaを動かしてみる

一目で分かるメニューバー通信量モニター——ローカル、署名済み、約3MB。

macOS用ダウンロード

常時オンVPN: 落とし穴

いくつかのVPNクライアントは、トンネルが落ちたときにすべてのトラフィックをブロックする「キルスイッチ」または「常時オン」モードを提供します。便利ですが意外な点があります:

  • スリープ復帰後の最初の数秒は、トンネルが再確立される前にブロックされていないトラフィックがあるかもしれない。一部のクライアントは明示的にこれを保持、他はしない。
  • Wi-Fiネットワークの変更(自宅からカフェへ移動)は短い切断をトリガーする。キルスイッチは保持すべきだが実装次第。
  • 一部のアプリは積極的な再接続ロジックを持つ——トンネルがダウンしているとき100msごとにリトライする。トンネルが戻ったとき再接続時の通信量スパイクになります。

VPNオンでスリープから起きた瞬間にovaを観察しましょう。パターンは通常: VPNクライアント自身が再ハンドシェイク中に小さなサージを示し、5〜30秒以内に個別のアプリが自分のソケットを再接続するときサージし始めます。起動時に200MBのスパイクが見えるなら、Slack/Discord/iMessageが一斉に追いついていることが典型的です。

アプリ別ルーティングとスプリットトンネル

一部のVPNクライアントは特定のアプリだけをトンネル経由でルーティングすることをサポートします。ユースケースは「トレントクライアントをMullvad経由で送りつつ、ビデオ通話にVPNレイテンシを加えないようSlackは直接通す」。

nettopでスプリットトンネルルールを検証:

sudo nettop -P -m route

スプリットトンネルされたアプリはen0トラフィックのみを示し、トンネルされたものはutunのみを示すべき。同じプロセスで両方が現れるなら、ルールがきれいに強制されていない——通常、アプリがルール変更前の長く生きるソケットを保持しているため。それらをクリアするためにアプリを再起動しましょう。

複数のVPN接続をモニタリング

パワーユーザーは時に2つのVPNを同時に動かします——たとえば内部企業サービスへのアクセス用Tailscaleに加え、一般的なインターネットプライバシー用商用VPN(Mullvad、Proton)。macOSはルーティングテーブル経由でこれを扱います: より具体的なルート(Tailscaleの100.64.0.0/10)が広いもの(商用VPNのデフォルトルート)に勝ちます。

ifconfigで複数のutunインターフェースが見えます。netstat -rn | head -30でルーティングテーブルを読みます——最初に一致するルートが勝ちます。ovaはどのトンネルを区別せずにアプリ別合計通信量を表示します。それにはnettopの-m routeビューがリファレンスです。

次に何をするか

macOSでVPN通信量をエンドツーエンドにモニタリングする10分の監査:

  1. VPNを接続。
  2. メニューバーでovaを開き、現在アクティブなアプリを記録。
  3. ターミナルでsudo nettop -P -m routeを実行。
  4. 相互参照: ovaで有意な通信量を示すすべてのアプリは、nettopでutun0(またはVPNが使うどのutunか)の下に接続が現れているべき。それらのプロセスからのen0トラフィックはリーク候補。
  5. ipleak.netを訪問してVPN経由でのIPとDNS出口を確認。
  6. 切断、速度テスト実行、再接続、もう1度テスト実行。オーバーヘッドを計算。

これを終えると、VPNが本当に思っている通りのことをしているか、オーバーヘッドが実際にいくらかかっているか、目を離さないでおくべきアプリはどれかが分かります。それはVPNクライアントのメニューバーの「接続済み」インジケータより強い答えです。