套接字连接重新路由
大多数代理服务器执行将数据转发到适当的“真实”服务器的工作。然而，我正在设计一个分布式系统，其中当“代理”接收到 TCP/IP 套接字连接时，远程系统实际上与代理指定的真实服务器连接。所有后续数据都从远程流向真实服务器。
那么是否可以“转发”socket连接请求，以便远程系统与真实服务器连接呢？
（我暂时假设远程系统无法做任何进一步的事情。即代理无法通过发送实际服务器的 IP 地址及其远程连接来响应连接。）
这将在普通模式下进行Windows（不是服务器），所以不能使用 TCPCP 之类的狡猾的东西。
Most proxy servers perform the job of forwarding data to an appropriate "real" server. However, I am in the process of designing a distributed system in which when the "proxy" receives a TCP/IP socket connection, the remote system actually connects with a real server which the proxy nominates. All subsequent data flows from remote to the real server.
So is it possible to "forward" the socket connection request so that the remote system connects with the real server?
(I am assuming for the moment that nothing further can be done with the remote system. Ie the proxy can't respond to the connection by sending the IP address of the actual server and the remote connections with that. )
This will be under vanilla Windows (not Server), so can't use cunning stuff like TCPCP.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我假设您的“远程系统”是发起连接尝试的系统，即代理的客户端。
如果我理解正确的话：当“远程系统”想要连接某个地方时，您希望“代理服务器”来决定连接的真正位置（“真实服务器”）。当做出决定时，您不想再涉及代理服务器 - 连接的数据不应该通过代理，而是直接在“远程系统”和“真实服务器”之间进行。
问题是，如果您希望连接真正直接，“远程系统”必须知道“真实服务器”的 IP 地址，反之亦然。
就像我说的，不可能。为什么“代理”发回实际 IP 地址会出现问题？
安全吗？您想确保连接确实到达代理想要的地方吗？如果是这样的话，你别无选择——你必须妥协。代理要么转发所有数据，并且它知道数据要去哪里，要么让客户端自行连接，但您无法控制它连接的位置。
只要您完全控制整个网络，大多数网络问题都可以解决。例如，在这里，您可以在“远程系统”和“真实客户端”之间的路径上使用路由器，以确保连接是直接的并且到达代理想要的位置。但这很复杂，并且在实践中可能不是一个选择（因为您可能无法控制这些路由器）。
一种折衷方案可能是在网络周围分布多个“中继服务器”来转发连接，而不是让实际的代理服务器转发它们。当代理做出决定时，它会找到最好的（最近的）中继服务器，告诉它有关连接的信息，然后命令客户端连接到中继服务器，这确保连接到达代理预期的位置。
I assume your "remote system" is the one that initiates connection attempts, i.e. client of the proxy.
If I get this right: when the "remote system" wants to connect somewhere, you want the "proxy server" to decide where the connection will really go ("real server"). When the decision is made, you don't want to involve the proxy server any further - the data of the connection should not pass the proxy, but go directly between the "remote system" and the "real server".
Problem is, if you want the connection to be truly direct, the "remote system" must know the IP address of of the "real server", and vice versa.
Like I said, not possible. Why is it a problem to have the "proxy" send back the actual IP address?
Is it security - you want to make sure the connection really goes where the proxy wanted? If that's the case, you don't have an option - you have to compromise. Either the proxy forwards all the data, and it knows where the data is going, or let the client connect itself, but you don't have control where it connects.
Most networking problems can be solved as long as you have complete control over the entire network. Here, for instance, you could involve routers on the path between the "remote system" and the "real client", to make sure the connection is direct and that it goes where the proxy wanted. But this is complex, and probably not an option in practice (since you may not have control over those routers).
A compromise may be to have several "relay servers" distributed around the network that will forward the connections instead of having the actual proxy server forward them. When a proxy makes a decision, it finds the best (closest) relay server, tells it about the connection, then orders the client to connect to the relay server, which makes sure the connection goes where the proxy intended it to go.
可能有一种方法可以做到这一点，但您需要使用 Windows 驱动程序来实现它。当连接来自本地主机以外的 IP 时，我还没有尝试过此操作，但它可能会起作用。
看一下 NetFilter SDK。有一个试用版，功能齐全，最多可支持 100000 个 TCP 和 UDP 连接。另一种可能性是自己编写 Windows 驱动程序，但这并非易事。
http://www.netfiltersdk.com
基本上它的工作原理如下：
1）您创建一个继承自 NF_EventHandler 的类。在那里，您可以提供自己的 tcpConnectRequest 等方法的实现，以允许您将 TCP 连接重定向到其他地方。
2) 通过调用 nf_init 来初始化库。这提供了驱动程序和代理之间的链接，因为您向它提供了 NF_EventHandler 实现的实例。
还有一些示例程序供您查看重定向的发生。例如，要将端口 80 上的连接从进程 ID 214 重定向到 127.0.0.0:8081，您可以运行：
TcpRedirector.exe -p 80 -pid 214 -r 127.0.0.1:8081
对于您的代理，这将用作如下所示：
1) 从客户端应用程序连接到代理。
2) 连接请求被 NetFilterSDK (tcpConnectRequest) 拦截，并修改连接端点以连接到代理选择的服务器。这是至关重要的一点，因为您的连接来自外部，而这部分可能不起作用。
There might be a way of doing this but you need to use a Windows driver to achieve it. I've not tried this when the connection comes from an IP other than localhost, but it might work.
Take a look at NetFilter SDK. There's a trial version which is fully functional up to 100000 TCP and UDP connections. The other possibility is to write a Windows driver yourself, but this is non-trivial.
http://www.netfiltersdk.com
Basically it works as follows:
1) You create a class which inherits from NF_EventHandler. In there you can provide your own implementation of methods like tcpConnectRequest to allow you to redirect TCP connections somewhere else.
2) You initialize the library with a call to nf_init. This provides the link between the driver and your proxy, as you provide an instance of your NF_EventHandler implementation to it.
There are also some example programs for you to see the redirection happening. For example, to redirect a connection on port 80 from process id 214 to 127.0.0.0:8081, you can run:
TcpRedirector.exe -p 80 -pid 214 -r 127.0.0.1:8081
For your proxy, this would be used as follows:
1) Connect from your client application to the proxy.
2) The connection request is intercepted by NetFilterSDK (tcpConnectRequest) and the connection endpoint is modified to connect to the server the proxy chooses. This is the crucial bit because your connection is coming from outside and this is the part that may not work.
听起来像是路由问题，比 TCP/IP 低一层；
您实际上正在寻找类似 ARP 的代理：
我想说你需要管理 ARP 数据包，检查 ARP 请求：
客户端 -> WHOIS PROXY.MAC
代理 -> PROXY.IP 是 SERVER.IP
然后通过 TCP/IP 从客户端到服务器的正常套接字连接。
Sounds like routing problem, one layer lower than TCP/IP;
You're actually looking for ARP like proxy:
I'd say you need to manage ARP packets, chekcing the ARP requests:
CLIENT -> WHOIS PROXY.MAC
PROXY -> PROXY.IP is SERVER.IP
Then normal socket connection via TCP/IP from client to server.