使ったVPNの出口アドレスを記録して検証する方法

デスクトップVPNクライアントにどのサーバーを使ったか尋ねても、正直な答えはたいてい地点名です。その名前はあなたが選んだ入口であり、通信が出て行ったアドレスはまったく別のマシンである可能性があります。アプリには二つ目の番号を残す仕組みがないので、記録は使った瞬間に作るしかありません。方法は二つあり、サポート窓口で通用するのはそのうち一つだけです。

二つの記録、実在するのは一つだけ

クライアント自身の表示は、よくても選んだ地点と時刻の一覧です。これは見落としではなく設計上の判断で、アドレスは運用上の詳細であり、割り当ての間で入れ替わり、対応表を公開すればサポートも不正利用の処理も難しくなります。プロバイダーが自社ネットワークの前面にクラウドのインスタンスを置くのは、端点を誰にも告げずに移せるようにするためです。アプリが示すのはあなたがした選択であり、通信が通った経路ではありません。

自分で作れる記録は、各行に公開アドレス一つとUTCの時刻一つを持つローカルファイルで、より小さく、見た目は悪いものの、はるかに役に立ちます。外部の観測者にも見えるものを正確に記述しているからです。

方法A：出口アドレスを自分で記録する

エコーサービスはリクエストが届いた送信元アドレスを返し、これが定義上の出口アドレスです。記録は、ルートとDNSが落ち着く前に接続済みと表示するクライアントがトンネル前のアドレスを記録して最初の行からログを汚すため、トンネルが接続済みと報告した後に実行してください。

#!/bin/sh
umask 077
log="$HOME/vpn-exit.log"
printf '%s %s\n' "$(date -u +%Y-%m-%dT%H:%M:%SZ)" "$(curl -fsS https://api.ipify.org)" >> "$log"

二つの工夫が、この断片を飾りではなく実用品にします。時刻とアドレスが同じ行にあるので後から解析するときに対応づける必要がなく、umask 077 はファイルを作成した瞬間から非公開に保ちます。起動ごとに一度ではなく接続ごとに一度実行し、端末ごとに一つのファイルを保ってください。

ログには、いつトンネルを使い、どのネットワークから現れたかが残り、これは回数よりも閲覧履歴に近いものです。弁明できる保存期間を選び、ファイルは共有の同期フォルダーの外に置き、意図して削除してください。

方法B：プロバイダーに履歴を求める

接続ログを保持し、サポートの問い合わせに時刻とサーバー名で答えるプロバイダーもあります。その記録が示すのは提供者の設備であり、あなたの通信ではなく、保持期間と調べる意思の分だけの価値しかありません。また記録されるのはセッションであり、個々のリクエストではありません。期間は通常短く、トンネルのプロバイダー側から測られます。

ログを取らないと宣伝するプロバイダーは求められてもこれを出せず、クライアント側の最近の地点一覧も同じものではありません。ログなしのプロバイダーに出口アドレスを尋ねると、たいていはそのデータが存在しない理由の説明で終わります。

サポート窓口でそれぞれの記録が証明できること

二つの記録は別の問いに答えますが、比較が観念的でなくなるのはこの表においてです。

あなたの手にあるのは最初の列だけです。プロバイダーの記録は、ある時点でアカウントが接続していたことを確認できますが、どのリクエストがトンネルを使ったかは確認できず、提供者が運用上の詳細として扱うアドレスを名指しすることもありません。どちらの記録も、共有された出口アドレスが同じ一分間に多くの顧客を運びうるため、個人を特定しません。

どちらかを信じる前に、両方を基準値と比較する

アドレス単体では何も証明しません。接続前に直接のアドレスを、接続後にトンネル経由のアドレスを記録し、比べてください。値が同じなら、そのリクエストはトンネルを通っておらず、原因は分割トンネル、優先されるプロキシ、直接経路に落ちたクライアントのいずれかです。

curl -fsS https://api.ipify.org; echo
curl -fsS https://api64.ipify.org; echo
dig +short TXT o-o.myaddr.l.google.com @1.1.1.1

DNSとIPv6についても同じ比較を繰り返してください。アドレスのエコーが証明するのは一つのHTTPリクエストの経路であり、どのリゾルバーが答えたかは何も示しませんが、片方で漏れている端末がもう片方では完全に健全に見えることがあります。