Kc's blog

Appearance

kc_shen2026-10-28
2261
9m

Windows 通过 EasyConnect 共享内网 HTTPS 服务：端口转发实战与踩坑记录 ​

一、需求背景 ​

工作中遇到这样一个需求：

一台 Windows 电脑已经安装并登录企业 VPN 客户端 Sangfor EasyConnect，能够正常访问企业内网服务；另一台位于同一局域网的电脑没有连接 VPN，但也需要访问同一个内网 HTTPS 页面。

目标地址：

text
https://10.91.9.142:10088

两台电脑的网络信息如下。

设备IP 地址说明
VPN 主机192.200.124.178Windows，已连接 EasyConnect
客户端192.200.125.170需要通过 VPN 主机访问内网
EasyConnect 虚拟网卡2.0.1.9VPN 主机的虚拟网卡地址
内网目标10.91.9.142:10088HTTPS 服务

VPN 主机自身能够访问目标服务，但客户端直接访问失败。

最终采用 Windows 自带的 netsh interface portproxy 实现 TCP 端口转发，不需要额外安装代理软件。

二、最终解决方案 ​

1. 在 VPN 主机上配置端口转发 ​

在运行 EasyConnect 的 Windows 电脑上，以管理员身份打开 PowerShell，执行：

powershell
netsh interface portproxy add v4tov4 `
  listenaddress=192.200.124.178 `
  listenport=10088 `
  connectaddress=10.91.9.142 `
  connectport=10088

参数说明：

  • listenaddress：本机对局域网提供服务的 IP。
  • listenport：客户端连接的端口。
  • connectaddress：VPN 内网目标 IP。
  • connectport：目标服务端口。

配置完成后，数据流向如下：

text
客户端浏览器
    |
    | HTTPS 请求
    v
192.200.124.178:10088
    |
    | Windows portproxy
    v
10.91.9.142:10088
    |
    | EasyConnect VPN
    v
企业内网 HTTPS 服务

2. 添加 Windows 防火墙入站规则 ​

如果 Windows 防火墙阻止了入站连接，可以添加一条仅针对目标端口的规则：

powershell
New-NetFirewallRule `
  -DisplayName "EasyConnect TCP Forward 10088" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalAddress 192.200.124.178 `
  -LocalPort 10088 `
  -Action Allow

如果规则已经存在，不要反复创建；可以先检查现有规则。

3. 验证端口转发规则 ​

执行：

powershell
netsh interface portproxy show all

应看到类似结果：

text
侦听地址          端口    连接地址       端口
192.200.124.178   10088   10.91.9.142   10088

这只能证明规则已配置，不能单独证明后端转发正常。

4. 验证客户端是否能连接转发入口 ​

在另一台电脑上执行：

powershell
Test-NetConnection 192.200.124.178 -Port 10088

本次测试结果：

text
ComputerName     : 192.200.124.178
RemotePort       : 10088
TcpTestSucceeded : True

说明客户端已经能够建立到 VPN 主机端口的 TCP 连接。

5. 验证 VPN 主机能否访问内网服务 ​

在 VPN 主机上执行：

powershell
Test-NetConnection 10.91.9.142 -Port 10088

本次结果：

text
InterfaceAlias   : 以太网 4
SourceAddress    : 2.0.1.9
TcpTestSucceeded : True

说明 VPN 主机能够通过 EasyConnect 虚拟网卡连接目标服务。

6. 使用正确的 URL 访问页面 ​

目标服务根路径 / 会返回 HTTP 301 重定向：

text
HTTP/1.1 301 Moved Permanently
Location: https://10.91.9.142:10088/sh-zxcyc/

因此，客户端最终使用的地址是：

text
https://192.200.124.178:10088/sh-zxcyc/

这里需要注意：浏览器访问的是 VPN 主机地址，而不是原始内网 IP。

三、踩过的坑 ​

坑 1：开启 IPv4 转发，不代表服务就能访问 ​

排查过程中曾开启 Windows 网卡的 IPv4 转发：

powershell
Set-NetIPInterface `
  -InterfaceIndex 16 `
  -AddressFamily IPv4 `
  -Forwarding Enabled

但 IP 转发与 TCP 端口转发是不同的机制。

  • IPv4 转发：允许 Windows 转发 IP 数据包。
  • portproxy：监听指定 TCP 端口，并建立到目标地址的连接。
  • ICS（Internet Connection Sharing）：提供网络连接共享相关的 NAT、地址分配等功能。

本次最终采用的是 portproxy，不需要依靠 ICS 才能完成这个 TCP 端口映射。

不要为了配置一个 TCP 端口而盲目叠加路由、ICS 和 NAT 设置，以免改变现有网络环境。

坑 2：TCP 端口测试成功，不代表浏览器一定能打开 ​

以下命令成功：

powershell
Test-NetConnection 192.200.124.178 -Port 10088

只说明 TCP 连接可以建立，不代表 HTTPS 请求、TLS 握手和网页资源加载全部正常。

遇到问题时，可以继续使用：

powershell
curl.exe -vk --connect-timeout 5 `
  https://192.200.124.178:10088/sh-zxcyc/

其中：

  • -v：输出连接和 TLS 交互过程。
  • -k：忽略证书校验，仅用于诊断。
  • --connect-timeout 5：连接超时限制为 5 秒。

坑 3：根路径返回 301，不代表服务异常 ​

本次目标服务根路径返回：

text
HTTP/1.1 301 Moved Permanently
Location: https://10.91.9.142:10088/sh-zxcyc/

这是 Nginx 将根路径重定向到应用子路径的行为，不是连接失败。

可以用下面的命令自动跟随重定向：

powershell
curl.exe -vkL --connect-timeout 5 `
  https://10.91.9.142:10088/

但需要注意：如果直接通过 portproxy 访问，服务器返回的重定向地址仍然可能指向原始内网 IP。客户端没有相应路由时，浏览器可能无法继续访问。因此，直接使用正确的子路径和代理入口地址更合适。

坑 4：必须区分“端口可连接”和“网页正常返回” ​

本次最关键的验证是，在客户端执行：

powershell
curl.exe -vk --connect-timeout 5 `
  https://192.200.124.178:10088/sh-zxcyc/

最终收到了：

text
HTTP/1.1 200 OK
Server: nginx
Content-Type: text/html
Content-Length: 5484

这说明 HTML 页面已经通过转发返回。

HTTP 200 是确认转发链路成功的重要证据，比单纯的 TcpTestSucceeded : True 更有意义。

如果 HTML 已返回但浏览器仍显示空白，则应进一步检查浏览器开发者工具中的 Console 和 Network，确认 CSS、JavaScript、登录接口及其他 API 是否也能正常访问。

坑 5：HTTPS 证书与访问地址可能不匹配 ​

通过原始地址访问：

text
https://10.91.9.142:10088

与通过转发入口访问：

text
https://192.200.124.178:10088

虽然都可能连接到同一台后端服务器，但浏览器校验的是当前访问地址与服务器证书是否匹配。

因此，使用转发入口后可能出现证书警告。

curl -k 只适用于诊断，不应该作为长期忽略证书错误的解决办法。生产环境应优先使用证书匹配的内部域名，并按企业要求配置证书信任。

四、下次如何快速开启 ​

下次需要再次使用时，可以按以下流程操作。

第一步：连接 EasyConnect ​

在 VPN 主机上正常登录企业 VPN。

确认目标服务仍然可达：

powershell
Test-NetConnection 10.91.9.142 -Port 10088

预期：

text
TcpTestSucceeded : True

第二步：检查端口转发规则 ​

以管理员身份打开 PowerShell：

powershell
netsh interface portproxy show all

如果已经存在下面这条规则，就不需要重复添加：

text
192.200.124.178:10088
    -> 10.91.9.142:10088

如果规则不存在，再执行：

powershell
netsh interface portproxy add v4tov4 `
  listenaddress=192.200.124.178 `
  listenport=10088 `
  connectaddress=10.91.9.142 `
  connectport=10088

第三步：检查防火墙规则 ​

确认入站规则仍然存在并且有效：

powershell
Get-NetFirewallRule `
  -DisplayName "EasyConnect TCP Forward 10088"

如果规则不存在，再按前面的命令添加。

第四步：从客户端访问 ​

在客户端浏览器打开：

text
https://192.200.124.178:10088/sh-zxcyc/

如果访问失败，先分别测试：

powershell
Test-NetConnection 192.200.124.178 -Port 10088

以及：

powershell
curl.exe -vk --connect-timeout 5 `
  https://192.200.124.178:10088/sh-zxcyc/

这样可以快速区分端口连接问题和 HTTPS 页面响应问题。

五、如何关闭或清理配置 ​

如果以后不再需要端口转发，可以删除对应规则：

powershell
netsh interface portproxy delete v4tov4 `
  listenaddress=192.200.124.178 `
  listenport=10088

如果防火墙规则是专门为本方案创建的，也可以删除：

powershell
Remove-NetFirewallRule `
  -DisplayName "EasyConnect TCP Forward 10088"

删除前应确认规则没有被其他用途依赖。

之前手动开启的 IPv4 转发是否恢复为原值，需要根据这台电脑原先的网络配置决定；不要在不了解其他网络用途时随意修改。

六、总结 ​

这次问题的关键不是目标 HTTPS 服务不可用，而是需要让局域网客户端通过一台已经连接 EasyConnect 的 Windows 电脑访问内网服务。

最终方案是：

  1. VPN 主机正常连接 EasyConnect。
  2. 使用 Windows netsh interface portproxy 映射 TCP 端口。
  3. 根据需要添加精确的防火墙入站规则。
  4. 客户端使用 VPN 主机的 IP 和映射端口访问。
  5. 如果服务存在子路径重定向，直接使用正确的应用路径。
  6. 用 curl -vk 和 HTTP 状态码验证实际请求，而不只依赖端口连通性。

最终访问地址：

text
https://192.200.124.178:10088/sh-zxcyc/

最后提醒：这种方式会让其他设备通过 VPN 主机访问特定的内网服务，应仅用于获得授权的网络环境。portproxy 规则通常会持久保留，但如果 VPN 主机的 IP 变化、EasyConnect 断开或企业安全策略限制转发，就需要重新检查配置和连接状态。

最近更新