vmnet8未启用是nat不通的首要原因，需确认其已启用并获取192.168.122.1网关地址；同时检查虚拟机ip、路由、内核参数及防火墙，结合tcpdump抓包定位真实故障点。
确认虚拟网卡 VMnet8 是否真正启用
很多“NAT不通”的问题，其实压根没走到虚拟机内部——宿主机上 VMnet8 适配器根本没启用，或者被 windows 防火墙/第三方安全软件静默禁用。这不是配置错，是物理链路断了。
实操建议：
- 在 Windows 上打开「网络连接」，找到
VMnet8，右键确认状态是「已启用」；若灰色不可点，先去 VMware「虚拟网络编辑器」点右下角「更改设置」再勾选「将主机虚拟适配器连接到此网络」 - 运行
ipconfig /all，搜VMnet8，必须看到类似IPv4 地址 . . . . . . . . : 192.168.122.1——这个192.168.122.1就是虚拟机要 ping 的网关，没有它，后续全白搭 - 如果
VMnet8消失不见，别急着重装 VMware，先试试用services.msc检查VMware NAT Service和VMware DHCP Service是否正在运行
检查虚拟机是否拿到有效 IP 且路由正确
即使 VMnet8 正常，虚拟机也可能卡在 DHCP 阶段：拿到 169.254.x.x（APIPA 地址）或干脆没 IP，ip route show 里连 default via 都没有，自然无法出网。
实操建议：
- 运行
ip addr show，确认主网卡（如ens33或eth0）处于UP状态，且有类似inet 192.168.122.100/24的地址，子网掩码必须是/24（即255.255.255.0） - 运行
ip route show，必须看到一行default via 192.168.122.1 dev ens33；缺了就手动加：sudo ip route add default via 192.168.122.1 - 如果
dhclient报already running，先杀掉旧进程：sudo pkill dhclient，再重试sudo dhclient ens33
验证内核 NAT 相关参数是否被误启
tcp_tw_recycle=1 是个经典“静默杀手”：它在 NAT 环境下会让服务端误判客户端时间戳不连续，直接丢弃连接，表现为 ssh 随机断连、http 请求超时，但 ping 和 traceroute 全部正常——极难定位。
实操建议：
- 检查当前值：
cat /proc/sys/net/ipv4/tcp_tw_recycle和cat /proc/sys/net/ipv4/tcp_timestamps，只要任一为1，就需禁用 - 永久生效：向
/etc/sysctl.conf追加两行：net.ipv4.tcp_tw_recycle=0和net.ipv4.tcp_timestamps=0，然后执行sudo sysctl -p - 注意：
tcp_tw_recycle在较新内核（5.10+）已被移除，但大量生产环境仍跑着 3.x/4.x 内核，不能跳过这步
抓包定位是“发不出去”还是“收不回来”
当 ping 192.168.122.1 不通，又排除了前面所有配置，就得看真实数据包流向——是虚拟机根本没发出 ICMP 请求？还是请求发出去了但网关没响应？
实操建议：
- 在虚拟机里执行：
sudo tcpdump -i ens33 icmp，再开一个终端ping 192.168.122.1；如果tcpdump完全没输出，说明网卡/驱动/路由层就卡住了 - 如果能看到
request但没reply，问题在宿主机侧：检查 Windows 防火墙是否放行了ICMPv4-In规则，或临时关闭防火墙测试 - 别依赖
ping单一结论——tcpdump才告诉你数据到底走没走、走到哪一层
最容易被忽略的，是以为“能获取 IP 就等于网络通”，其实路由缺失、内核参数冲突、宿主机防火墙拦截，都会让流量在某个环节彻底静音，而错误现象几乎一样。