目录
[二、第一次尝试：使用 ICS（Internet Connection Sharing）](#二、第一次尝试：使用 ICS（Internet Connection Sharing）)
[三、第二次尝试：关闭 ICS，开启 Windows 路由转发](#三、第二次尝试：关闭 ICS，开启 Windows 路由转发)
[1. 关闭 ICS](#1. 关闭 ICS)
[2. 开启 IPEnableRouter](#2. 开启 IPEnableRouter)
[3. 在物理网络主机添加静态路由](#3. 在物理网络主机添加静态路由)
[四、关键突破：抓包发现 95 收到请求但不回包](#四、关键突破：抓包发现 95 收到请求但不回包)
[五、最终解决方案：开启每个接口的 forwarding](#五、最终解决方案：开启每个接口的 forwarding)
[六、ICS 与 Windows 路由转发的本质区别](#六、ICS 与 Windows 路由转发的本质区别)
在使用 eNSP 做网络实验时，我们经常希望：
让 eNSP 内的虚拟设备（交换机、路由器、防护墙）与真实物理网络互通。
例如：
-
让物理机访问 eNSP 内的主机
-
让物理网络中的其他电脑访问 eNSP 的 防火墙
-
让 eNSP 内的设备访问外网
看似简单，但真正做起来会遇到各种坑。
在我之前使用eNSP的过程中，我曾经让物理网络中的设备访问虚拟环境中的防火墙，比如通过浏览器访问防火墙的web页面。当时磕磕碰碰的不太顺利，主要是我强行绑定到桥接口，网络不稳定。今天我按照官方做法加上自己的一些理解终于把 eNSP实验环境和物理网络彻底打通了。
我们都知道eNSP中提供网云cloud可以和物理世界打通，但是普遍的是只能和运行eNSP的物理机打通，不能连接外部。因为在添加通道的时候只能添加host-only网卡，不能添加桥接网卡。
关于eNSP中的cloud设置按照下图设置即可。
本片文章就是在添加host-only网卡的基础上打通网络连接。希望能帮到同样在折腾 eNSP 的你。
一、需求背景
我的实验环境如下：
-
物理网络：
172.16.13.0/24 -
物理机：
172.16.13.95 -
eNSP Host-Only 网段：
192.168.56.0/24 -
eNSP 主机：
192.168.56.94 -
eNSP 交换机 VLAN 接口：
192.168.56.93
目标非常明确：
让物理网络中的任意主机（如 172.16.13.91）能够访问 eNSP 内的设备（如 192.168.56.1、192.168.56.94 等）。
二、第一次尝试：使用 ICS（Internet Connection Sharing）
我最开始使用 Windows 的 ICS（共享网络）功能，希望让 eNSP 访问外网。
结果 ICS 自动把 Host-Only 网卡改成了：
192.168.137.1这样的话要不你把网卡改回192.168.56.1，要不改变实验环境中的地址规划。但是这样只能够实现实验环境中的设备访问外部网络，无法让外部网络访问实验环境中的设备。原因很简单：
ICS 是单向 NAT，只允许内部访问外部，不允许外部访问内部。
也就是说：
-
eNSP → 物理网络：可以
-
物理网络 → eNSP：不行
不过这种情况想实验拓扑中的设备可以直接上互联网，因为ICS已经做了NAT转换。不需要上层网关参与路由和NAT。
三、第二次尝试：关闭 ICS，开启 Windows 路由转发
既然 ICS 不行，那就让 Windows 变成真正的路由器。
我做了以下操作：
1. 关闭 ICS
恢复 Host-Only 网卡为 192.168.56.1
2. 开启 IPEnableRouter
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v IPEnableRouter /t REG_DWORD /d 1 /f3. 在物理网络主机添加静态路由
route add 192.168.56.0 mask 255.255.255.0 172.16.13.95理论上，这样 91 → 95 → 56.1 就应该通了。
但实际情况是：
172.16.13.91 ping 192.168.56.1 不通。
四、关键突破：抓包发现 95 收到请求但不回包
我在 172.16.13.95 上抓包，发现：
-
95 收到了 来自 91 的 ICMP Echo Request
-
但 95 没有发送 Echo Reply
这说明：
Windows 收到了包，但没有把它当成"本机包"处理。
为什么？
因为 Windows 的逻辑是：
-
如果目标 IP 属于同一网卡 → 直接回包
-
如果目标 IP 属于另一块网卡 → 需要"跨接口处理"
-
如果 forwarding 没开 → 丢弃，不回包
也就是说：
95 虽然有 192.168.56.1，但来自 172.16.13.x 的包要跨网卡处理，必须开启 forwarding。
五、最终解决方案：开启每个接口的 forwarding
Windows 的 IPEnableRouter=1 只是"允许路由"， 但真正的转发需要对每个接口单独开启。
我执行了两条命令：
netsh interface ipv4 set interface 3 forwarding=enabled
netsh interface ipv4 set interface 17 forwarding=enabled其中：
-
Interface 3 = 172.16.13.95（物理网卡）
-
Interface 17 = 192.168.56.1（Host-Only 网卡）
执行完这两条命令后------不需要重启------奇迹发生了：
172.16.13.91 能 ping 通 192.168.56.1 了！
这说明：
Windows 已经开始跨网卡处理数据包，真正变成了一台路由器。
六、ICS 与 Windows 路由转发的本质区别
| 功能 | ICS（共享网络） | Windows 路由转发（IP forwarding） |
|---|---|---|
| 工作模式 | NAT | 路由（L3 转发） |
| 内部访问外部 | ✔ | ✔ |
| 外部访问内部 | ❌ | ✔ |
| 多网段互通 | ❌ | ✔ |
| 可控性 | 低 | 完全可控 |
| 适合场景 | 家庭上网共享 | 实验室、企业网络、eNSP、GNS3 |
一句话总结：
ICS 是 NAT，只能让内部访问外部； Windows 路由转发是三层路由，可以让所有网段互通。
七、最终效果
现在我的网络实现了：
-
物理网络 → eNSP 主机
-
物理网络 → eNSP 交换机
-
eNSP → 物理网络
-
eNSP → 互联网（需要上层设备额外设置）
上图是我的实验拓扑中的PC1 在ICS和路由情况下ping 1.1.1.1的不同结果。
也就是说把物理机当成一台路由器，可以实现网络连通。但是想让实验拓扑中的设备上互联网可能需要额外的设置，比如让互联网网关172.16.13.1知道192.168.56.0网段的存在，需要设置NAT和回城路由。在没有这个条件的情况下其他主机想要访问实验拓扑需要单独设置静态路由。