Kali 虚拟机访问 Windows Docker 服务：从桥接踩坑到端口转发 | 技术笔记

上一篇文章把项目部署到了 Docker，接下来就是搭建攻击环境了。我需要让 VMware 里的 Kali Linux 能访问到 Windows 宿主机上的 Docker 服务，听起来很简单，实际上折腾了不少时间。

目标

很明确：

宿主机：Windows，跑着 Docker 服务（监听 127.0.0.1:8000 等端口）
虚拟机：Kali Linux，跑在 VMware Workstation 里
目标：Kali 能像局域网里的另一台机器一样，直接访问宿主机上的 Docker 端口

第一反应：桥接模式

直觉告诉我，给 Kali 配桥接网络就行了。桥接模式会把虚拟机当成网络中的独立主机，由路由器分配 IP，这样 Kali 和 Windows 就在同一个网段了。

于是我在 VMware 里做了配置：

虚拟网络编辑器中：把 VMnet0 设为 Bridged，桥接到本机的 Wi-Fi 网卡
虚拟机网络适配器：选「桥接模式（自动）」

理论上，Kali 应该拿到一个 192.168.x.x 地址，和 Windows 处于同一网段。

踩坑：Kali 拿到了 10.5.x.x

Kali 启动后，执行 ip a，看到的地址是：

inet 10.5.5.165/22

而 Windows 的局域网 IP 是 192.168.133.x 段。结果就是：

Kali ping 不通 Windows 的 192.168.133.x
curl 访问也失败

名义上是桥接，实际却落到了一个 10.5.x.x 的虚拟网段里，更像是 NAT 或 Host-only 网络。

反复排查

为了确认不是配置问题，我做了几轮修改：

重配 VMnet0：以管理员权限打开虚拟网络编辑器，Restore Defaults，重新将 VMnet0 设为 Bridged，绑定到真实 Wi-Fi 网卡
虚拟机网卡强制走 VMnet0：删除原有网络适配器，重新添加，选「自定义：VMnet0」
在 Kali 中刷新 IP：

sudo dhclient -r eth0
sudo dhclient eth0
ip a

多轮操作后，Kali 拿到的依然是 10.5.x.x 段的地址，只是尾号变化。

结论：本机环境有其他虚拟网卡或安全软件影响了桥接行为，继续死磕成本太高。

转折：发现虚拟网已经互通

虽然拿不到 192.168.x.x，但我突然想到——先试试 Windows 和 Kali 在 10.5.x.x 网段上能不能通信。

在 Windows 命令行中：

ping 10.5.7.93

来自 10.5.7.93 的回复: 字节=32 时间<1ms TTL=64
丢失 = 0 (0% 丢失)

通了！ 这说明 Windows 和 Kali 在 VMware 的内部网 10.5.7.0/22 中是完全互通的，只是这个虚拟网和物理局域网 192.168.x.x 隔离。

当前的网络拓扑：

思路一下就清晰了：与其继续强求桥接，不如利用已存在的虚拟网，通过 Windows 做端口转发，把 Docker 服务引入 10.5.7.x 网段。

解决方案：netsh portproxy 端口转发

思路

既然 Kali 可以访问 10.5.7.x 上的 Windows，那么让 Windows：

在 10.5.7.1:8000 上监听端口
把流量转发到本机 Docker 服务的 127.0.0.1:8000
Kali 访问 http://10.5.7.1:8000 就等于访问 Docker

找到 Windows 在虚拟网的 IP

ipconfig

找到 VMware 虚拟网卡，记下它在 10.5.7.0/22 网段上的 IPv4：10.5.7.1

添加端口转发规则

以管理员身份打开 CMD，执行：

netsh interface portproxy add v4tov4 ^
  listenaddress=10.5.7.1 listenport=8000 ^
  connectaddress=127.0.0.1 connectport=8000 protocol=tcp

这条命令的作用：在 10.5.7.1:8000 上监听 TCP，把所有连接转发到 127.0.0.1:8000。

查看当前所有规则：

netsh interface portproxy show v4tov4

如果需要删除：

netsh interface portproxy delete v4tov4 listenaddress=10.5.7.1 listenport=8000

在 Kali 中验证

# 确认和 Windows 的虚拟网 IP 通
ping 10.5.7.1

# 访问 Docker 服务
curl http://10.5.7.1:8000

成功了！ 整条链路打通：

Kali → 虚拟网 (10.5.7.0/22) → Windows (10.5.7.1:8000) → portproxy → 127.0.0.1:8000 → Docker 容器

从 Kali 的视角看，10.5.7.1:8000 就是一个远程目标服务，可以像对任何普通服务器一样进行渗透测试。

过程中的一些坑

VMnet0 显示 “Bridged” 但实际不是

以管理员模式打开虚拟网络编辑器时，VMnet0 显示为 Bridged；从普通入口打开，有时会看到类型变为 Custom。这容易让人误以为配置被重置。

判断方法：不要看 VMware 界面显示什么，直接看 Kali 拿到的 IP 网段。如果是 10.5.x.x，那就还在 VMware 的内部网里。

Kali 桌面显示 “Wired connection 1”

这只是 NetworkManager 给网卡起的名字，不能说明是 NAT 还是桥接。判断网络类型要看：

虚拟机设置中的网络选项
ip a 中的实际网段

为什么没继续死磕桥接

桥接模式在理想情况下确实更「真实」，Kali 会成为局域网里的独立主机。但这次：

桥接受到本机环境影响，始终无法拿到 192.168.x.x
VMware 的虚拟网已经稳定可用
核心目标只是「从 Kali 测试宿主机上的 Docker 服务」，不需要全面模拟真实内网

利用现成的虚拟网 + 端口转发，比继续和桥接对抗划算得多。

总结

几个经验：

判断网络模式，先看实际 IP 网段，不要被「桥接模式」四个字迷惑
只要宿主机和虚拟机在某个网段互通，就可以通过端口转发搭建测试环境
netsh interface portproxy 很适合「虚拟机测试宿主机服务」的场景，一条命令就能搞定
调网络时，先实现最小闭环，再去优化拓扑——先 ping 通，再 curl 通，最后再考虑更复杂的网络结构

网络环境搭好了，接下来就是正式用 Kali 对项目做安全测试了。