Как технически создается цепочка socks серверов?

Question

[Денис]

Объясните технически, как создается цепочка через нескольких socks серверов? Нужно именно описание на уровне протокола, а не пример конфигурации в каком либо готовом продукте.
Желательно для Socks V5.

Answer 1

[15432]

Принцип цепочки прокси один как для SOCKS, так и для HTTPS. Я делал цепочку на HTTPS прокси так:
1) Подключаюсь по TCP к прокси №1 (TCP connect на нужный адрес/порт)
2) Прошу прокси создать канал с прокси №2 (в моём случае, шлю по TCP пакет "CONNECT 222.222.222.222:8080")
3) Прокси подключается по TCP к указанному адресу
4) Я получаю от прокси №1 сообщение, что подключение установлено ("HTTP/1.0 200 Connection established\r\n\r\n")
5) Далее прокси №1 просто перенаправляет пакеты туда-обратно между мной и прокси №2, никак их не изменяя и не обрабатывая. Забываем про него, считаем, что у нас прямое TCP соединение с прокси №2
6) Повторяем пункты 2-5 для всех других прокси в цепочке
7) Просим последний прокси подключить нас к нужному сайту и опять ждём сообщения "Connection Established"

В случае с SOCKS прокси команды и ответы будут в формате SOCKS, остальное идентично.

Comments

[Денис]

С HTTPS проще. там всего один канал. А в SOCKS5 на запрос CONNECT, сервер возвращает адрес и порт, куда надо соединиться, для получения канала до указанного адреса. То есть у него несколько каналов, один для управления, и несколько - для соединений. Если немного не так объяснил, то вот выдержка из RFC:

CONNECT
В ответ на CONNECT, BND.PORT содержит номер порта, который сервер назначает для соединения с указанным хостом, а BND.ADDR содержит связанный IP-адрес. Выданный BND.ADDR зачастую отличается от IP-адреса, который клиент использует для доступа к SOCKS-северу, так как такие сервера часто имеют несколько IP-адресов. Ожидается, что сервер будет использовать DST.ADDR и DST.PORT и адрес клиента при обработке запроса CONNECT.

[15432]

Разве это не при команде "0x02 = establish a TCP/IP port binding"?
При команде "0x01 = establish a TCP/IP stream connection" он не должен текущий коннект пробросить на указанный адрес?

[Денис]

В общем пока сам все не реализовал - не разобрался. Вы были абсолютно правы. Все работает точно так же, как и в случае с HTTPS.
Но есть один нюанс, который все портит. Если во время построения цепочки, один из следующих серверов не предоставил соединения, то рвется вся цепочка. Есть ли такое же поведение в случае с HTTPS?

[15432]

Ну да, соединение останется на этом самом сервере. Обратно "шагнуть" нельзя. Но можно его попросить подключиться еще раз или к другому адресу (если он не закрыл TCP сокет после ошибки подключения)

[Денис]

15432: Нет. Нагло рвутся все соединения. Приходится строить цепочку заново.
а если соединение не разорвалось, то при попытке установить новое, сервер возвращает ошибку и все таки его рвёт. А если последний присоединенный сервер порвал соединение, вся цепочка тут-же разлетается. Возможно, это какое-то свойство бесплатных SOCKS, но факт остается фактом.
Теперь у меня мысль, не переделать ли все на HTTP(S) прокси? Поэтому интересует, как ведут себя они в данном случае?

[15432]

Денис: как только TCP сокет закрывается (сайтом или последним сервером), все прокси в цепочке до него тоже закрывают соединение. Так что всё идентично.