透過プロキシ

透過プロキシ

透過プロキシは、自身のサーバーでリクエストを転送しますが、利用者の元のIPアドレスをサイトに伝えます。リクエストとともに情報を運ぶHTTPヘッダーのフィールドに、アドレスを追加することで実現できます。そのため、別のIPを経由して接続しても、自分のアドレスが隠れるとは限りません。

この用語は、従来のプロキシの匿名性レベルの分類に属します。現在の商用プロキシでは、高匿名型のElite / High Anonymityの動作が一般的です。クライアントの元のIPを転送せず、プロキシ利用を示すヘッダーも追加しません。透過型という分類は、主に古い説明や公開プロキシ一覧のラベルを理解する際に役立ちます。

サイトがあなたのIPを知る仕組み

あなたのパブリックIPが198.51.100.24で、プロキシが203.0.113.80からサイトに接続するとします。サイトへの接続はプロキシが開くため、サイトには接続元としてプロキシのアドレスが見えます。

ただし、暗号化されていないHTTPリクエストを転送するとき、プロキシはX-Forwarded-For: 198.51.100.24を追加できます。その場合、サイトは接続からプロキシIPを、リクエスト内のフィールドからあなたのIPを受け取り、2つのアドレスを得ます。

198.51.100.24の端末からのリクエストが、203.0.113.80のプロキシを経由してサイトへ届きます。サイトは接続からプロキシIPを受け取り、X-Forwarded-Forから利用者の元のIPを受け取ります。
プロキシは自身のIPから接続する一方、HTTPリクエスト内で利用者のアドレスも送ります。

IP確認ページには、接続元アドレスだけが表示される場合があります。自分のアドレスもサイトに届いているのに、画面にはプロキシIPしか見えないことがあります。この開示を調べるには、転送された値と、プロキシへの接続に使うパブリックIPを比較してください。X-Forwarded-Forがあるだけでは、本当のアドレスが含まれる証拠にはなりません。サイトは第三者が渡すヘッダーを信頼する必要はありませんが、その値があなたのIPなら、情報はすでに届いています。

元のアドレスを残す理由

プロキシは、匿名性を必要としない用途にも使われます。組織のネットワーク内で、サイトへのアクセスを制限し、リクエストをフィルタリングし、キャッシュ可能な応答を保存できます。保存した応答は、元のサーバーから再取得せずに再び提供できます。

同じ組織の複数システムをリクエストが通ると、次のシステムが送信したクライアントを知る必要がある場合があります。元のアドレスを渡すことは、リクエストの集計やアクセス規則に役立ちます。これは意図的なインフラ設計です。外部サイトから自分のIPを隠すためにプロキシを購入する利用者には向きません。

「透過」のもう1つの意味

ネットワークの文書では、通信が自動的に経由するプロキシを透過プロキシと呼ぶこともあります。利用者はブラウザーにプロキシアドレスを入力せず、ネットワーク機器が経路を設定します。管理者はこの構成で、各端末の通信を共通のフィルタリングシステムへ通せます。

この場合、用語は接続の設定方法を示します。匿名性の分類では、IPをサイトに明かすことを示します。両者は独立した特性です。手動でプロキシを設定してもアドレスが隠れる保証はなく、自動的に経路を変更するだけでIPがHTTPヘッダーに転送されるとも限りません。

HTTPSでは何が変わるか

X-Forwarded-Forの例は、プロキシが読めるリクエストに当てはまります。HTTPプロキシを使う通常のHTTPS接続では、アプリがCONNECTでトンネルを開きます。その後、ヘッダーを含むサイトへのリクエストは、暗号化されたTLS接続内を通ります。暗号化されたバイト列を中継するだけのプロキシは、そこにあなたのIPを挿入できません。

HTTPSを復号する企業のゲートウェイは、動作が異なります。証明書エラーなしで検査するには、利用者の端末がその証明書を信頼している必要があります。そのため、平文HTTPのテストで透過型と判定されても、トンネル内のHTTPSに自動的に同じ結果を当てはめることはできません。

ナレッジベースに戻る