VPN を二段重ねにする：何が隠れて何が犠牲になるか

トンネルを二段重ねにしても匿名にはならない。変わるのは 観測が二人のプロバイダーに分かれることだ。どちらも、あなたの自宅アドレスと目的地を同時には見ない。これは確かな、しかし限られた利点であり、初めてこれに頼ったときに表面化するルーティング、DNS、MTU の問題を伴う。

1. 二段目を何のために使うかを決める

設定を始める前に目的を一文で書き出す。ISP にどのサイトを見たかを知られたくないのなら、トンネル一段で足りる。どの単一プロバイダーにもあなたのアドレスと通信を結び付けさせないのなら、二段が必要だ。誰にもあなたを特定させないことなら、何段重ねても届かない。

鎖の強さは、弱いほうのプロバイダーのログと、両社が保持するアカウント記録の強さまでしかない。支払い、登録メール、アプリのテレメトリーはトンネルの完全に外側にある。

2. 外側のトンネル経由で内側の端点に到達できるようにする

よくある失敗は、内側のトンネルがそもそも確立しないことだ。フルトンネルの外側接続が既定ルートを握るため、内側のクライアントが自分の端点へ向かう試みは外側のトンネルに飲み込まれ、破棄されるかループする。内側の端点には外側のインターフェース経由の明示的なルートが必要で、内側のクライアントを起動する前に設定しておく。そうしないとハンドシェイクがルートと競争して負ける。

WireGuard は同じ衝突を逆方向から見せる。各ピアの AllowedIPs がどの宛先をそのトンネルに入れるかを決めるので、すべてのアドレスを主張する内側のインターフェースは、より具体的なルートが勝たない限り外側の端点も主張する。二つのインターフェースで重なる AllowedIPs は、片側が黙って負ける設定だ。

コンテナの連鎖は分離を明示し、罠を明白にする。独自の名前空間、独自の既定ルート、そして中のクライアントを持つコンテナは、ホストがそこへ送ったものを転送する。ホスト自身がその経路を使い始めるわけではない。転送を有効にし、コンテナのトンネル用のルートを追加し、サービスをコンテナのアドレスに向ける。

3. DNS を同じ経路に保つ

DNS は通信が通る場所を通らなければならない。内側のプロバイダーがリゾルバーを押し込み、ホストがまだローカルのものを問い合わせているなら、その照会はトンネルが隠すはずだったサイトをまさに露呈する。クライアントのステータス画面を信じるのではなく、各トンネルインターフェースでキャプチャして確認する。ここでの漏洩は通常の閲覧では見えず、キャプチャでは明らかだ。

分割 DNS の設計はこれを難しくする。ローカル名の問い合わせがトンネルの外に属するのは正当な場合があるからだ。たまたま応答したリゾルバーから例外リストを発見するのではなく、意図して書き出す。

4. ユーザーに先回りされる前に MTU を設定する

MTU はもう一つの予測可能な犠牲者だ。二重のカプセル化はヘッダーを二つ削り、経路 MTU をすでに下げた外側のトンネルは内側の余地をさらに減らす。症状はおなじみだ。小さな要求は通るが、大きな転送と TLS ハンドシェイクが止まる。

ip link set dev wg1 mtu 1280 は乱暴な修正で、転送側で MSS を絞るのがより丁寧なやり方だ。接続をやり直すことは修正ではない。

5. 実際に起きる故障を試す

外側のトンネルをわざと切って、何が起きるかを見る。外側のホップが死んだときに黙って直接経路へ落ちる鎖は、鎖がないより悪い。守られていると信じたまさにその瞬間に漏れるからだ。目指すべき挙動は、すべての通信を止めるキルスイッチだ。結果を記録しておく。障害の最中に再発見したくはない。

遅延と第二の故障点は恒久的なコストだ。二段とは、都合の悪い時間に何かが壊れたときのサポート窓口が二つになることでもある。