Proxyサーバーの宛先と戻り先ってどうやって指定しているんでしょうか？

Question

プロキシにはローカルプロキシ、パブリックプロキシ(公共プロキシ)の２種類があります。
今回は、ネット上に転がっているFreeなproxyに話を絞ります。

ふと思いました。
「そういえば、クライアントからPROXYサーバーにどうやってwebサーバーのIPアドレスを教えているんだろ・・・」

考えられるやり方は・・・（私の予測です。）
(1)パケットにwebサーバーのIPアドレスを付与する。2つのIPアドレスを載せるため普通のパケットとは異なるものになってしまう。
(2)戻ってくる時は、proxy内のログ（ソースIPとwebIPの対情報を載せておく）を参照すれば可能かな～～

wiresharkで多段proxyネットワークTorのパケットを覗いてみました。
・・・・Torのパケットを見つけられませんでした。普通のパケットと特に違いがないため見分けが付きませんでした。
（難易度が高すぎました。）

・・・ということで、調べてみました。（私の持っている本には載っていなかったので）
Proxy利用時のhttps通信のパケット(IPヘッダ、TCPヘッダ)に関して
プロキシサーバーを解する場合に、宛先IPはどのように渡されるのでしか？

直接接続の時の HTTPの中身(リクエストURI)が Get /upload/ HTTP1.1

プロキシ経由の時のHTTPの中身(リクエストURI)が Get http://www.hidemyass.com/upload/ HTTP1.1

つまり、ペイロードの部分にwebサーバーの宛先ドメインを載せているわけですね！
クライアントからProxyにパケットが届いたら、proxyはパケットを再構築しなくてはならないですね。

プロキシ経由でWeb閲覧するクライアントパソコンは、yahooのIPアドレスを知る必要はありません。

名前解決するのはプロキシサーバなので、クライアントパソコンが名前解決できない状態であってもWeb閲覧できます。

こちらは、ローカルプロキシの場合の話だと思うので、今回の場合は適応しないですね。

しかし、クライアントに戻る時はどうするのでしょうか？？
クライアントは http://www.hidemyass.com/upload/のように特定できません。

(2)戻ってくる時は、proxy内のログ（ソースIPとwebIPの対情報を載せておく）を参照すれば可能かな～～

これでしょうか？(これならwebサーバーからのパケットのペイロードのところに宛先を入れなくてもいい感じですかね。)

しかし、これでは匿名性が失われてしまいますよね・・・・
１段proxyの場合、権限のある人がサーバーのlogを調べれば簡単に見つかってしまいます。
アクセスした後にlogを削除しているなら、大丈夫そうですが・・・
おまけにproxyの管理者には丸見えなので、あまり良いやりかたではなさそうです。

どうやっているんでしょうか？
実際はこんな風にやっている・・・というものを教えてください！！

さらに、多段proxyの場合、次のproxyサーバーのたくさんのIPアドレスを載せる必要がありまよね？
２段以でも結構大変ではないでしょうか？

「ちなみに、多段proxyのtorは次のproxyの選択するためのサーバーが専用に用意されているようです。
普通のproxyにはそのようなサーバーはないので、この方法もないかなと思いますが・・・」

[追記]

絵に描いてみましたわ。
なぜか横になっている・・・

クライアントからwebは、ペイロードのドメインをIPアドレスに変換し、パケットのヘッダ部分に書く必要がありますよね。（パケットを作りなおす。）
しかし、帰りはどのソケットに書き込めば良いのか分からないため、logを参照する必要が出てきます。
（２つのIPアドレスが対情報になって書かれているテーブルみたいな・・・）
mattnさんが仰っているのは、このソケット同士をproxy内部で繋げるということですか？？

「追記２」

acceptされた後に、webサーバーに対してconnect要求を行うという事でしょうか？

Answer 1

まずプロキシには2つの接続方法があります。一つは GET/POST 等に続いて URL を指定する方法で、最も簡単なプロキシサーバの動作です。これは仰る様にログに残ります。

もう一つの接続方法が CONNECT メソッドを使う方法です。例えば多段でサーバAとサーバBを経由するとします。まずクライアントはサーバAに対して以下のリクエストを発行します。

CONNECT サーバB:ポート

するとこれ以降、クライアントとサーバBがソケットで繋がれた状態となります。この後、通常通りクライアントはサーバBに対して GET/POST といったリクエストを送信します。

ここでサーバBへの CONNECT をポート 443 で接続し TLS や https ネゴシエーションにより暗号化する事でサーバAでは解読できない通信が行われる事になります。例えばサーバBもプロキシで、CONNECT の後に

GET サーバC

であったり

CONNECT サーバC:ポート

の様に更に多段にする事で、間に挟まれたプロキシからは接続先を見る事は出来ても中でどの様な通信が行われているのか分からない状態となる訳です。

なお、プロキシを超えて ssh したりする場合にもこの CONNECT メソッドが使われます。

追記

ちなみに GET /path の様なリクエストでプロキシと呼ばれるものは、おそらくですがリバースプロキシの事かと思います。望んでいらっしゃる様な、外部のサイトを見るためのプロキシではなく、HTTP サーバが内部の別のサーバにリクエストを転送する為に用いられます。

Comments

[mattn]

そういえば昨日ここまで書いて寝てしまいましたが、匿名性について回答してなかったです。プロキシを介して匿名性は無いです。たとえ TLS/https であっても暗号化スイートを知る事が出来るのであれば解読は可能です。あるとすればクライアントとサーバ間で鍵を使って喋る、もしくはパケットを分散するくらいかと思います。パケットを分散するというのは質問の中にも出てきた Tor 等が有名です。

[strike1217]

追記しました。
「プロキシを介して匿名性は無いです。」
あら？そうなんですか！

この場合の匿名性というのは、webサーバーからも第三者からどのクライアントからアクセスして来ているかが分からない・・・・ようにすることですよね？

[mattn]

えと、まず画像を貼って貰ったのですがソケットについて学習した方が良いです。プロキシを介してのリクエスト送信およびレスポンス応答は以下の流れです。クライアントから見た処理です。

1. クライアントがプロキシサーバに接続する
2. クライアントがプロキシサーバに GET http://example.com/ を送信する
3. プロキシサーバが example.com に接続する
4. プロキシサーバが example.com から応答を貰う
5. プロキシサーバがクライアントに応答を戻す

この 1 から 5 までの間、クライアントからプロキシサーバ、またプロキシサーバから example.com までのコネクションは繋がりっぱなしです。なのでプロキシサーバがどこに返送するか迷う様な事はなく、単に繋がれたソケットに返送するだけです。

まずここは先に理解して下さい。これとは別にプロキシに匿名性があるかという話は分けて考えて下さい。匿名性の話ですが、2つあります。

ウェブサーバが誰から接続されたのか判断できるかという匿名性
もう一つはプロキシ内で通信を傍受できるかという匿名性

後者は鍵などを使っておらず Tor の様に通信を分散していないのであれば、暗号化スイートさえ分かれば解読出来ます。もちろん手間ですが。しかし接続元は分かるのですからプロキシサーバを提供する人間が接続元を明かしてしまえば Tor であっても匿名性は無いと言って良いと思います。捜査令状が出ればプロキシ提供者も従わないといけない訳ですし。

[strike1217]

「単に繋がれたソケットに返送するだけです。」
うん？
繋がれたソケットが複数ある場合、分からなくないですか？
proxyサーバーのところで、ソケットが一度切れてる（？）と言えば良いんですかね・・・
なんといいますか・・・クライアントからproxy, proxyからwebのソケットは別物ですよね・・・
IPアドレスが違うので・・・・

[mattn]

プロキシの実装ですが、リスンソケットから accept されたクライアントソケットに対してスレッドを起こします。(スレッドじゃない場合もあります)
なのでこのスレッドの引数にはクライアントの1接続と喋るソケットが渡ります。で、そのスレッドではクライアントから受け取った GET http://example.com/foo を元に example.com に接続し GET /foo というリクエストを送信。返送されてきたデータをスレッドの引数であるソケットに垂れ流すだけです。

[strike1217]

ええ～と、つまり、
２つのソケットをスレッドが繋げている・・・・ということでしょうか？

[mattn]

はい。そういう事です。

[strike1217]

あ、追記しました。
proxyサーバーは、accept()のあとに、socket()を記述してソケットを作るんでしょうか？
それとも、別のプロセスを立ち上げて、socket()を実行し最初から作りあげるんですか？

「２つのソケットをスレッドが繋げている」というのは、後者の２つのプロセスのソケットを作りあげ、プロセスを結ぶということですか？

[mattn]

プロセスは重たいのでスレッドですね。(昔の実装は fork だったと思いますが)
クライアントから要求された内容をプロキシが代行してその応答をクライアントに返送しているだけです。

http://go-gyazo.appspot.com/240bc16f56de704f.png

[mattn]

実際は繋いでいるといっても、ウェブサーバから受信したデータをクライアントに送信、クライアントから受信した要求をウェブサーバに送信、をこまごまやってるだけです。

[strike1217]

accept()のあとに、スレッドを立ち上げ、スレッドからsocket()を記述してwebサーバーへのソケットを作りあげる・・・ということですか！
（間違っていたら、ご指摘ください。）

proxyサーバーのソケットプログラミングなんてしたことないので、勉強になりましたわ。

[strike1217]

「一つは GET/POST 等に続いて URL を指定する方法で、最も簡単なプロキシサーバの動作です。
もう一つの接続方法が CONNECT メソッドを使う方法です。」

今議論していたのは、１つ目ですよね。
２つ目はまた全然違うんですか？
現在の主流はどちらでしょうか？

[mattn]

2つ目も対して変わりません。単にクライアントから受け取った CONNECT メソッドの含まれた要求をプロキシが代行してウェブサーバに投げているだけです。何が違うかというと、いったん CONNECT メソッドが通って Established Connection の応答が戻った後は、中身が HTTP でなくても良いという事なんです。世に「ファイアウォール超え」と呼ばれている技術の多くはこれを使っています。

[strike1217]

あ、そんなに変わらないんですね！
わかりました！

Answer 2

ローカルにあろうが、インターネット上にあろうが、仕組みは同じです。

つまり、ペイロードの部分にwebサーバーの宛先ドメインを載せているわけですね！

その通りです。

クライアントからProxyにパケットが届いたら、proxyはパケットを再構築しなくてはならないですね。

これは何のことですか？

しかし、クライアントに戻る時はどうするのでしょうか？？

クライアントからProxyへのリクエスト時のTCPセッションは繋いだままなので、そのセッションに返せばいいです。ログを見たりする必要は無いです。

Comments

[strike1217]

絵に描いてみました。
追記を見てみてください。

[strike1217]

「クライアントからProxyへのリクエスト時のTCPセッションは繋いだままなので、そのセッションに返せばいいです。」

ようやく理解できました！