VPN と iCloud Private Relay の仕組みを調べた

以前の記事で、Apple の iCloud Private Relay に関するニュースを取り上げた。WebKit の一部機能がプロキシサーバーを通らず、端末から直接外部へ通信していたらしい。細工された Web ページを開くと、実際の IP アドレスや利用している DNS サーバーが漏れる可能性があったそうだ。

これを読んで、今までなんとなく VPN や iCloud Private Relay は安全！という印象しかなかったが、そもそもなんで安全なのか？何が起こっているのか気になったので、簡単に調べてみた。

VPN とは何か

VPN は Virtual Private Network の略です。Web 通信を VPN 経由にすると、通信先の Web サービスから自宅の公開 IP アドレスを隠せます。また、自宅や店舗のルーター、公衆 Wi-Fi の運営者、インターネット回線事業者や携帯電話会社から、どの Web サービスと通信しているかを見えにくくできます。

VPN はどう通信しているのか

では、VPN はどのようにして、自宅の公開 IP アドレスや、どの Web サービスと通信しているかを隠すのでしょうか。

Web サービスから自宅の公開 IP アドレスを隠す

まずは、自宅の公開 IP アドレスを隠す方法から考えます。

端末が Web サービスと直接通信すると、Web サービスには自宅の公開 IP アドレスが見えます。

自宅の端末
  ↓
Web サービス

Web サービスから見える接続元: 自宅の公開 IP アドレス

これでは、Web サービス側から自宅の公開 IP アドレスが丸見えです。IP アドレスから、おおまかな地域や利用している通信事業者を推測したり、アクセス履歴を同じ接続元として紐付けたりできます。怖いですね〜

そこで、端末と Web サービスの間に VPN サーバーを挟みます。

自宅の端末
  ↓
VPN サーバー
  ↓
Web サービス

Web サービスから見える接続元: VPN サーバーの IP アドレス

このように、Web サービスから接続元の IP アドレスとして見えるのは、直接通信している VPN サーバーの IP アドレスになります。これによって、Web サービスから自宅の公開 IP アドレスを隠せます。

途中のネットワークから通信先を隠す

次に、どの Web サービスと通信しているかを、途中のルーターや通信事業者から隠す方法を考えます。

VPN サーバーを挟むだけで通信を暗号化していなければ、端末と VPN サーバーの間にあるルーターや通信事業者から、本来の接続先を読み取られる可能性があります。

自宅の端末
  ↓ 暗号化されていない通信
自宅や店舗のルーター
  ↓ (本来の接続先を読み取れる可能性がある)
インターネット回線事業者や携帯電話会社
  ↓ (本来の接続先を読み取れる可能性がある)
VPN サーバー
  ↓
Web サービス

そこで、端末から VPN サーバーまでの通信を暗号化します。本来の接続先である Web サービスの情報も、暗号化された内側へ入れます。パケットの中身を簡略化すると、次のようになります。

外側のパケット
├─ 送信元: 自宅の公開 IP アドレス
├─ 宛先: VPN サーバー
└─ 暗号化された内側のパケット
   ├─ 本来の宛先: Web サイト
   └─ 通信内容

途中のルーターや通信事業者からは、端末が VPN サーバーと通信していることは見えますが、その先でどの Web サービスと通信しているかは見えにくくなります。

ちなみに、暗号化された内側のパケットは、VPN サーバーに届くと復号されます。例えば、WireGuard という VPN では、この復号に使う鍵を、端末と VPN サーバーが行うハンドシェイクによって作ります。このとき、暗号鍵そのものをネットワークで渡すのではなく、端末と VPN サーバーが情報を交換し、双方で同じ共有秘密を計算します。その共有秘密から通信用の鍵を作り、この鍵も定期的に更新します。

これによって、暗号化された内側のパケットは、途中のルーターや通信事業者に読まれずに VPN サーバーまで届きます。VPN サーバーは VPN の暗号化を解除し、内側にある本来の宛先を確認して、Web サービスへ通信を転送します。「良い感じじゃん！」と思うかもしれませんが、これでめでたしめでたし……とはいきません。

この仕組み上、VPN サーバーには、自宅の公開 IP アドレスと本来の接続先の両方が分かる可能性があります。HTTPS の通信内容まで読めるわけではありませんが、誰がどこへ接続したかは把握できる可能性があります。

つまり、VPN を使うと、通信経路への信頼の一部を VPN 運営者へ移すことになります。

VPN 通信における OS の役割

私も知らなかったのですが、VPN では OS ががっつり関わっています。Linux では、通信をどこへ流すかを決めるルーティングをカーネルが行い、VPN の種類によっては暗号化もカーネル内で行います。（まあ、ルーティングに OS が関わるのは、言われてみれば確かにそうなのですけどね。）実際の通信経路を見ると、OS は次のように関わっています。

ブラウザやアプリ
  ↓
OS のルーティング処理
  ↓
仮想ネットワークインターフェース
  ↓
VPN ソフトウェアやカーネルで暗号化
  ↓
VPN サーバー
  ↓ 通常の通信として転送
Web サイト

実際に、WireGuard という VPN があるのですが、Linux ではその実装がカーネルに組み込まれています。コードは drivers/net/wireguard/ にあります。

drivers/net/wireguard/
├─ device.c    wg0 という仮想ネットワーク機器を扱う
├─ send.c      パケットを暗号化して送信する
├─ receive.c   受信したパケットを復号する
├─ noise.c     鍵交換を行う
└─ socket.c    暗号化したデータを UDP で送る

ただ、暗号化を常にカーネル内で行うわけではありません。OpenVPN という VPN では、Linux カーネルの drivers/net/tun.c が tun0 などの仮想ネットワークインターフェースを提供し、そこからユーザー空間の OpenVPN プロセスへパケットを渡します。暗号化は、その OpenVPN プロセスが行います。

なお、現在の OpenVPN には DCO という仕組みもあり、暗号化などの処理をカーネルへ移すこともできます。VPN といっても、暗号化処理がどこで動くかは実装や構成によって違うようです。

WireGuard とかのコードを見てみても面白そう。

iCloud Private Relay の仕組み

では次に、iCloud Private Relay を見ていきます。

iCloud Private Relay は、どのような通信経路になっているのでしょうか。今回は OS 内部の処理を省くと、次のようになります。Safari から Apple 側の中継へ送り、さらに別会社の中継を通って Web サイトへ接続します。

Safari
  ↓
Apple 側の中継
  ↓
別会社の中継
  ↓
Web サイト

なぜ、わざわざ 2 社を中継するのでしょうか。Apple だけで中継してくれれば、別会社はいらないようにも見えます。「そうか！ Apple は利用者の情報を別会社へ売っているのか！」と思うかもしれません。もちろん、そういう話ではありません。

一般的な VPN サーバーは、利用者の端末と直接通信し、その後に Web サイトへ通信を転送します。そのため、VPN サーバーには利用者の実際の IP アドレスと接続先の IP アドレスの両方が分かってしまいます。

iCloud Private Relay は、この 2 つの情報を 1 社が同時に持たないように、中継を 2 段階に分けています。では、実際にどのように通信しているのか、順番に見ていきます。

まず、Safari は Apple 側の中継へ接続します。Apple 側の中継には、利用者の実際の IP アドレスが見えます。通常の VPN サーバーは、ここで接続先の情報も復号しますが、iCloud Private Relay の Apple 側の中継は復号しません。そのため、利用者がどの Web サイトへ接続しようとしているのかは分かりません。図にすると、以下のようになります。

Safari
  ↓
Apple 側の中継（実際の IP アドレスは分かるが、接続先は分からない）
  ↓
別会社の中継
  ↓
Web サイト

次に、別会社の中継が接続先の名前を復号し、一時的な IP アドレスを使って Web サイトへ接続します。このとき、別会社の中継には Apple 側の中継を経由した通信が届くため、利用者の実際の IP アドレスは分かりません。図にすると、以下のようになります。

Safari
  ↓
Apple 側の中継（実際の IP アドレスは分かるが、接続先は分からない）
  ↓
別会社の中継（実際の IP アドレスは分からないが、接続先は分かる）
  ↓
Web サイト

これによって、どちらか一方の中継だけでは、「この IP アドレスの利用者が、この Web サイトへ接続した」と結び付けられません。通常の VPN 運営者 1 社を全面的に信頼するのではなく、Apple と別会社で信頼を分割しているということですね。この仕組みによって、利用者のプライバシーを守りやすくしているのでしょう。

ただ、一般の利用者がここまで仕組みを知っているのかどうか……。自分も、普通の VPN を言い換えたものが iCloud Private Relay だと思っていましたし（笑）。

そして、前回の記事で取り上げたのが、この中継を通らず、端末から Web サイトへ直接通信してしまう不具合です。せっかく 2 段階に分けても、中継自体を通らなければ、実際の IP アドレスなどが漏れてしまうということですね。

ということで、今回の VPN と iCloud Private Relay の説明は以上です。

参照元

• IP and DNS Leaks in WebKit Affecting Proxy Browsers and Apple iCloud Private Relay — Mysk
• About iCloud Private Relay — Apple Support
• Protocol & Cryptography — WireGuard
• WireGuard source code — Linux kernel
• Universal TUN/TAP device driver — Linux kernel documentation
• OpenVPN Data Channel Offload — OpenVPN