背景
在最近项目中需要使用到windows smb文件共享，并且该项目过程不允许重启系统，其使用到的TCP连接端口为445，该项目测试环境一直处在内部网络，所以一开始没发现什么问题，项目进展到一定程度后，需要在公网环境中进行仿真测试，突然发现smb通道不能使用了，查了半天，发现是ISP把445端口给禁了，这让整个项目处于一个非常尴尬的处境，同时发现很多同行遇到了在原项目中使用了smb文件共享现在公网环境也无法正常工作，所以需要找到一个优雅的方法来完美解决这个问题。
找出SMB监听445的服务
按常理会把smb通道指定别的端口进行通信即可，可研究半天，发现net use使用smb时，无法指定传输端口，其原理是在windows开机启动时加载netbt驱动，smb服务使用默认端口445进行监听，而作为smb客户端也是用这个端口进行远端连接，google半天，是有那么一个注册表可以改这个初始化端口，应该在：
HKLM:\SYSTEM\CurrentControlSet\Services\NetBT
按正常思路，修改注册表，重启对应服务。那接下来使用netstat命令查看一下监听445端口的进程：
可以看出是pid为4的进程进行监听，从任务管理器上看是名叫System，备注"NT Kernel & System"，这玩意儿要重启，岂不是直接告诉你系统重启，但是该项目最大的特点就是不允许重启系统，事情发展到这个形态，不由得让我们Linux开发出身的程序员对一个封闭系统的感叹，唏嘘。
端口代理
但问题总要解决，这个时候我想到了端口代理/端口转发，只要网络流量在公网上不使用445端口就可以，我就设计出了一个思路：
Windows smb客户端访问本地445：
net use \\127.0.0.1\C$
- 1
1.客户端通过访问本地445，端口转发成访问远端，将访问本地445转发成访问远端8445端口，假设smb服务器IP为192.168.1.81：
netsh interface portproxy add v4tov4 listenport=445 connectaddress=192.168.1.81 connectport=8445
- 1
2.服务端由访问8445，端口转发成访问本地445：
netsh interface portproxy add v4tov4 listenport=8445 connectaddress=192.168.1.81 connectport=445
- 1
动手操作，按图描述的结构进行配置，服务端查看端口状态，可看到已有8445端口在监听
而客户端查看445端口状态，依然是pid为4的服务在监听，进行net use连接测试，连上的并不是远端的smb服务，而是本地smb服务。
经分析原理，配置端口代理后，被代理的端口会创建一个监听状态，可是本地已有smb服务监听了445端口，所以在客户端侧端口代理功能相当于失效。
再了解一下windows防火墙架构，如下是示意图：
前面所配置的端口代理应该属于Ipnat.sys模块，但是当我们在客户端在用户态使用net use连接127.0.0.1的smb的时候，在windows sockets driver(winsock.dll)时转到对应的本地smb应用服务，流量请求根本到不了Ipnat.sys模块，导致端口代理也就不会起作用。
端口拦截、端口代理
通过windows防火墙架构理清楚原因后，我们就想是否有别的办法在winsock.dll层面将流量报文拦截下来，然后转移到端口代理中去呢。
果不其然，google上找到了我们需要的驱动WinDivert：
windows 数据包转移 (WinDivert) 是一种用户模式的数据包捕获和转移包，WinDivert 允许用户模式应用程序捕获、修改、丢弃从 windows 网络堆栈发送的网络数据包。
基于这个工具，在github找到衍生开源项目divertTCPconn。
这个项目利用WinDivert驱动可以把指定目的端口的流量转换成访问本地其它端口，这不就正是我们想要的东西，那问题基本解决了，跃跃欲试，重新整理架构图：
把WinDivert和DivertTCPconn结合编译、执行，将访问远端445端口的流量转换成访问本地8445，然后再写一条端口代理从本地8445代理到远端8445，对应命令如下：
端口拦截
divertTCPconn.exe 445 8445
- 1
端口代理
假设远端smb服务器IP为192.168.1.81
netsh interface portproxy add v4tov4 listenport=8445 connectaddress=192.168.1.81 connectport=8445
- 1
经过客户端smb连接
net use \\192.168.1.81\C$
- 1
测试发现，流量并没有走8445端口，后面对divertTCPconn项目源码进行分析，发现在使用过滤器时，针对的是inbound&dst-port=445进行匹配。但对于我们这种情景来说，本地访问远端445是属于outbound&dst-port=445，赶紧把divertTCPconn代码修改：
经再次测试，在服务器之间走的是8445端口，而客户端和服务器内部也能够将445和8445进行转换，总结本案例是通过用户态端口拦截加端口重定向技术，最终达到我们想要的效果，并且在整个过程中，不用修改注册表，不用重启系统。