如何强制 System.Net.Socket.Connect() 方法使用袜子代理（代码注入与外部自定义代理）

发布于 2024-07-13 05:44:01 字数 1080 浏览 12 评论 0 原文

我正在使用 WCF 的 netTcpBinding，它直接连接到端点，并且似乎不了解有关袜子代理的任何信息。

我需要使用代理，因为我的大多数客户端不允许直接出站连接，并始终强制使用袜子代理。

我的第一个想法是配置 .net 框架来做到这一点，所以我按如下方式编辑了 machine.config 文件，但它似乎只适用于 http 代理（不适用于袜子）
```
; 
   
     
    <模块/>> 
   
   
  
```
My第二个选项是实现从 netTcpBinding 继承的自定义绑定，并且仅重写连接逻辑以添加代理代码。

我已经拆解了 System.ServiceModel 程序集，不幸的是，许多类被标记为内部（包括 SocketConnectionInitiator、ConnectionPoolHelper、ClientFramingDuplexSessionChannel 和 FramingDuplexSessionChannel，可能还有其他类）

这使得创建自定义 netTcpBinding 成为一项艰巨的工作，而且在交付新版本的 .net 框架时可能会导致一些问题。
另一个想法是将一些代码直接注入到 Socket.Connect() 方法中。这很容易实现，但我对修改.net框架的内部代码不太有信心。另外，虽然套接字类没有标记为密封，但我担心会破坏某些东西，尤其是在框架的后续版本中。
我现在的最后一个想法：我可以创建一个小代理工具，与我的软件在同一台计算机上运行，它会自动连接到公司的袜子代理，并向公司发出良好的“连接服务器”命令真正的袜子代理。

我认为后一种选择更好，但我很想听听其他人的意见。

你怎么认为？

原文

I'm using WCF's netTcpBinding, which connects directly to an endpoint and doesn't seems to know anything about socks proxies.

I need to use a proxy because most of my clients won't allow direct outbound connections, and enforce the use of socks proxies at all times.

My first idea was to configure the .net framework to do that, so I edited the machine.config file as follows, but it seems it only works with http proxies (not socks)

<system.net>
<defaultProxy enabled="true">
  <proxy usesystemdefault="False" proxyaddress="foo:1080" bypassonlocal="True"/>
  <module />
</defaultProxy>
</system.net>

My second option was to implement a custom binding inheriting from netTcpBinding, and only overriding the connection logic to add the proxy code.

I've dissasembled the System.ServiceModel assembly, and unfortunately, a lot of classes are marked as internal (including SocketConnectionInitiator, ConnectionPoolHelper, ClientFramingDuplexSessionChannel and FramingDuplexSessionChannel, and probably others aswell)

This makes creating a custom netTcpBinding a huge work, and moreover could cause some problems as new versions of the .net framework are delivered.
Another idea is to inject some code directly into the Socket.Connect() method. This is quite easy to achieve, but I'm not very confident with modifying the inner code of the .net framework. Also, although the socket class isn't marked as sealed, I'm afraid of breaking something, especially in later relases of the framework.
Last idea I've got for now: I could create a little proxy tool, running on the same computer as my software, which would automatically connect to the corporate's socks proxy, and issue the good "connect server" command to the real socks proxy.