VPNの出口IPはトンネルの証明ではない：サーバーが見るもの

VPN利用者しか到達できないサービスを誰かが求めるとき、明白な実装は出口アドレスの一覧を許可することだ。一覧は現実の働きをする。誰が接続できるかを制限する。トンネルが使われたことの証明にはならない。アドレスは出口を運営する者のものであり、その運営者は誰の通信でも転送できるからだ。この二つの言明の間のずれが、設計上の問題そのものである。

サーバーは接続ごとに一つのアドレスを見る

接続は送信元アドレスと宛先ポートを伴って届き、ネットワーク層が報告するのはそこまでだ。クライアントがトンネルを使うとき、あなたのリスナーに届くパケットは出口、またはその手前の変換から来る。クライアント自身のアドレスは、通常はプライベートであり、決して現れない。したがってクライアントのLAN範囲向けに書かれたファイアウォール規則は何の効果もない。

その送信元アドレスの後にあるものはすべてアプリケーションのデータであり、アプリケーションはそれを認証した範囲でしか信頼できない。

自分の出口がどう見えるかを試す

規則を書く前に両端から経路を見る。クライアントが自分の出口について持つ見方と、サーバーが接続について持つ見方が、重要な二つの事実である。

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

最初のコマンドは、クライアントが現れる公開アドレスを報告する。どの許可リストにもこの値を含めなければならない。二つ目は、サーバー上の確立済み接続を相手のアドレスとともに示す。規則が実際に照合するのはこちらである。両者があなたの頭の中のモデルと食い違うなら、方針を編集する前にモデルを直す。クラウドデータベースのファイアウォール、アプリケーションの許可リスト、ロードバランサーは、それぞれ別の変換層を見ることがある。

二つの出口集合のうち、一覧にできるのは一方だけ

一方の場合はリクエストの時点で検査できるが、他方はできない。そのため保証は大きく異なる。

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

公開されているTorの出口一覧は取得して比較できるが、一覧の古さと各出口自身の方針に左右される。それでも既知の出口に対する拒否規則は実施可能であり、見直しもできる。商用VPNには同等の登録簿が存在しない。アドレスは回転し、多くの事業者は何も公開しておらず、トンネルはVPNに属したことのないレンタルしたクラウドアドレス上で動くこともある。自分でまとめる一覧は観察されたアドレスのスナップショットであり、ホスティング範囲まで広げると証明を加えずに無関係な作業負荷を加えることになる。

アドレスは方針の入力として使い、証明として使わない

規則が何のためのものかを決める。ネットワーク制限は狭くとどめ、観察したアドレスを日付と理由とともに記録し、正当な利用者には出口が変わったときの復旧経路を与えるべきだ。アクセス制御には認証済みのアカウントか署名付きトークンが必要であり、これらだけがリクエストを身元に結びつける。リスク評価はアドレスを一つの信頼できない信号として使い、その誤検知と盲点を受け入れることができる。規則を製品上の決定として書くのは誠実だが、トンネルの存在の検証として書くのは誠実ではない。

鏡像の要求、つまりVPNの背後にいる利用者の本当のアドレスを取り戻すことは、同じ理由で失敗する。一つの接続は一つのアドレスを運び、セッション間の変化はいくつもの説明と整合する。以前の値を履歴として扱い、真実として扱わないことだ。