Перенаправление сокетного соединения

Question

Большинство прокси-серверов выполняют пересылку данных на соответствующий «настоящий» сервер.Тем не менее, я нахожусь в процессе разработки распределенной системы, в которой, когда «прокси» получает соединение через сокет TCP / IP, удаленная система фактически соединяется с реальным сервером, который назначает прокси.Все последующие данные передаются от удаленного к реальному серверу.

Так можно ли «переслать» запрос на подключение к сокету, чтобы удаленная система соединялась с реальным сервером?

(на данный момент я предполагаю, что с помощьюудаленная система. Т.е. прокси не может ответить на соединение, отправив IP-адрес фактического сервера и удаленных подключений с ним.)

Это будет под операционной системой Windows (не Server), поэтому можетне использовать такие хитрые вещи, как TCPCP.

Answer 1

Я предполагаю, что ваша "удаленная система" - это та, которая инициирует попытки подключения, т.е. клиент прокси.

Если я правильно понял: когда "удаленная система" хочет подключиться куда-то, вы хотите«прокси-сервер», чтобы решить, куда будет действительно идти соединение («настоящий сервер»).Когда решение принято, вы больше не хотите подключать прокси-сервер - данные соединения не должны проходить через прокси, а должны передаваться напрямую между «удаленной системой» и «реальным сервером».

Проблема в том, что если вы хотите, чтобы соединение действительно прямое , "удаленная система" должна знать IP-адрес"реального сервера", и наоборот.

(Я предполагаю, что на данный момент ничего нельзя сделать с удаленной системой. Т.е. прокси не может ответить на соединение, отправив IP-адрес фактического сервера и удаленные соединения сэто.)

Как я уже сказал, это невозможно.Почему проблема в том, чтобы «прокси» отправлял обратно действительный IP-адрес?

Это безопасность - вы хотите убедиться, что соединение действительно идет туда, куда хотел прокси?Если это так, у вас нет выбора - вы должны идти на компромисс.Либо прокси-сервер пересылает все данные, и он знает, куда эти данные отправляются, либо позволяет клиенту подключаться самостоятельно, но вы не можете контролировать, где он подключается.

Большинство сетевых проблем можно решить, еслиу вас есть полный контроль над всей сетью.Здесь, например, вы можете задействовать маршрутизаторы на пути между «удаленной системой» и «реальным клиентом», чтобы убедиться, что соединение прямое и оно идет туда, куда хотел прокси.Но это сложно, и, вероятно, на практике это не вариант (поскольку вы не можете контролировать эти маршрутизаторы).

Компромисс может заключаться в том, чтобы распределить по сети несколько «серверов ретрансляции», которые будут пересылать соединениявместо того, чтобы фактический прокси-сервер отправлял их.Когда прокси-сервер принимает решение, он находит лучший (ближайший) сервер ретрансляции, сообщает ему о соединении, а затем приказывает клиенту подключиться к серверу ретрансляции, чтобы убедиться, что соединение идет туда, где прокси-сервер намеревался его установить.

Answer 2

Возможно, есть способ сделать это, но для этого вам нужно использовать драйвер Windows.Я не пробовал этого, когда соединение приходит с IP-адреса, отличного от localhost, но оно может работать.

Взгляните на NetFilter SDK.Есть пробная версия, которая полностью функциональна до 100000 соединений TCP и UDP.Другая возможность состоит в том, чтобы написать драйвер для Windows самостоятельно, но это не тривиально.

http://www.netfiltersdk.com

В основном это работает следующим образом:

1) Вы создаетекласс, который наследуется от NF_EventHandler.Там вы можете предоставить свою собственную реализацию методов, таких как tcpConnectRequest, чтобы позволить вам перенаправлять TCP-соединения куда-то еще.

2) Вы инициализируете библиотеку с помощью вызова nf_init.Это обеспечивает связь между драйвером и вашим прокси, поскольку вы предоставляете ему экземпляр своей реализации NF_EventHandler.

Существуют также несколько примеров программ, которые вы можете увидеть, как происходит перенаправление.Например, чтобы перенаправить соединение через порт 80 с идентификатором процесса 214 на 127.0.0.0:8081, вы можете выполнить:

TcpRedirector.exe -p 80 -pid 214 -r 127.0.0.1:8081

Для вашего прокси-сервера это будет использоваться следующим образом:

1) Подключиться из вашего клиентского приложения к прокси.

2) Запрос на соединение перехватывается NetFilterSDK (tcpConnectRequest)конечная точка соединения модифицируется для подключения к серверу, который выбирает прокси.Это важный бит, потому что ваше соединение идет извне, и эта часть может не работать.

Answer 3

Похоже на проблему маршрутизации, на один уровень ниже, чем TCP / IP;
Вы на самом деле ищете ARP, как прокси : я бы сказал, что вам нужно управлять пакетами ARP, проверяя запросы ARP:

КЛИЕНТ -> WHOIS PROXY.MAC
PROXY -> PROXY.IP is SERVER.IP

Затем обычное сокетное соединение черезTCP / IP от клиента к серверу.