又见connection timed out。今天这位朋友的截图很典型secureCRT会话框里红字提示Connection timed out他反复强调IP我都改成一样的了虚拟机就在VMware里运行着可怎么都连不上。这种案例我经手过太多次了。表面看是secureCRT的问题实际上牵扯到虚拟机网络模式、IP网段规划、防火墙策略、SSH服务状态、甚至VMware虚拟网卡驱动等多个环节任何一个节点掉链子最终表现都是连接超时。这篇文章不绕弯子直接按我实际的排查顺序把这个问题的完整解法讲清楚。适合刚装好Linux虚拟机、用secureCRT却连不上的人也适合想系统弄懂虚拟机网络配置的新手。IP一致性只是第一道门槛过了这道门槛后面还有好几个拦路虎下面从最容易被误解的IP问题讲起一步步拆到根上。1. IP改成一样的这个前提可能从一开始就是错的1.1 你要连接的不是宿主机的IP而是虚拟机内部的IP先搞清楚一个最基本的问题secureCRT连接虚拟机本质是宿主机你的Windows电脑上的客户端去访问虚拟机内部的SSH服务。所以secureCRT里填写的地址必须是虚拟机里看到的那串IP。很多人把改IP这件事做在了Windows的本地连接上——手动把Windows的IPv4地址改成192.168.1.100然后虚拟机里看是192.168.1.101secureCRT里却填了192.168.1.100。这个192.168.1.100是宿主机自己的地址你让它去连虚拟机等于让张三敲自己家门喊李四开门门怎么会开正确的做法是打开虚拟机终端执行ip addr或者ifconfig看网卡通常是eth0、ens33或ens160那一行显示的IP地址那个才是你secureCRT要填的目标。在NAT模式下宿主机的Windows网卡保持自动获取或者任意可上网的配置都行完全不需要跟虚拟机改成一样的。这个基础认知不纠正后面全白搭。1.2 同网段和改一样的是两码事子网掩码才是关键就算你确实在虚拟机里改了IP也还有个常见误区两个IP看起来都在192.168.1.x里就以为能通。比如虚拟机是192.168.1.101宿主机Windows是192.168.1.88子网掩码一个是255.255.255.0一个是255.255.0.0这种情况通常能通但如果虚拟机是192.168.1.101/24宿主机是192.168.88.88/24哪怕两个IP都长得很192.168它们也压根不在同一个局域网。判断是否同网段不需要背子网掩码的计算公式你只需要记住一个实用技巧把IP和子网掩码逐位做与运算后结果相同的就在同一网段。日常最常见的是24位掩码也就是255.255.255.0这种情况下IP前三段相同即为同网段。所以192.168.1.x和192.168.88.x就是两个世界中间没有路由器转发通信直接失败。这时候你该做的不是继续纠结我改成一一样了呀而是把其中一个IP的第三段改过去或者在VMware虚拟网络编辑器里把NAT模式的网段整体改成和虚拟机一致。我更建议后者因为改虚拟机的IP可能牵扯到网关和DNS配置容易越改越乱。1.3 最隐蔽的坑IP保存了但配置根本没生效还有一种让人抓狂的情况你进入虚拟机用vi改了网卡配置文件保存退出回到secureCRT再连照样超时。跑回虚拟机一看ip addr显示的IP还是旧的。原因很简单Linux的网络配置改动不会自动生效。不同系统激活方式不一样CentOS / RHEL 7及以下systemctl restart networkCentOS 8 / Rocky Linux / AlmaLinuxnmcli con reload nmcli con up ens33或者重启NetworkManagerUbuntu 18.04 使用netplansudo netplan apply最省事也最稳妥的直接sudo reboot改完之后一定要再执行一遍ip addr确认地址真的变了。我见过不少新手照着教程改完配置重启了网络结果因为拼写错误或者配置项写错网卡根本没起来IP还是旧的secureCRT连的自然是个幽灵地址。记住以命令实际输出为准不要以你自己编辑的文件内容为准。2. 虚拟机网络模式选错了IP改到哪儿都连不上2.1 三种网络模式一次讲透VMware里虚拟机网卡有三种工作模式很多人从头到尾没搞明白过。这个问题不解决IP配置得再完美也没用。模式虚拟机IP来源宿主机与虚拟机关系典型场景NAT模式VMware NAT网段默认VMnet8自动分配虚拟机通过宿主机转发上网外部不可直接访问虚拟机最常见的单机使用、本机SSH连接桥接模式与宿主机同一真实局域网由路由器分配虚拟机像一台独立的电脑局域网内其他机器也能访问它需要局域网内互相访问、模拟真实主机仅主机模式VMnet1网段DHCP分配只有宿主机和虚拟机可以互通不能上网隔离调试、不连外网的测试环境话可以这么说桥接模式是搬家到同一个小区邻居之间互相串门很自然NAT模式是你住在房东给你租的公寓里外人找你必须经过物业宿主机转达仅主机模式是你们全家只拉了一条内线电话跟外界彻底不联系。三种模式对应三种IP规划方式改IP之前先确认你的虚拟机到底用的哪种。2.2 NAT模式下secureCRT里该填什么IPNAT模式是VMware默认选项也是新手最容易配错的地方。VMware默认的NAT网段通常是192.168.88.0/24不同版本可能略有差异虚拟机里面的地址可能是192.168.88.128、192.168.88.130之类的。很多人看到网上教程说改成192.168.1.x于是手动把虚拟机IP改成192.168.1.10结果这个网段跟VMware的NAT网段对不上虚拟机直接失去网络连接当然超时。正确姿势是打开VMware菜单栏的编辑→虚拟网络编辑器看NAT模式的网段是多少。然后回到虚拟机里用ip addr看实际分到的IP把这两个信息对上。只要虚拟机能正常上网、能ping通外网NAT模式下的IP就不用你操心直接拿来填进secureCRT即可。如果你非要手动改成静态IP请确保三个值IP地址在NAT网段内比如192.168.88.50子网掩码255.255.255.0网关填VMware NAT网关通常是192.168.88.2。这三者有一个不对SSH就连不上。2.3 桥接模式与仅主机模式各自的坑桥接模式有个特别容易踩的坑如果你用的是笔记本电脑连着Wi-Fi虚拟机桥接模式下经常拿不到IP或者通了也时断时续。因为无线AP通常开启了客户端隔离两个终端之间不允许直接通信。这种情况就不要死磕桥接了临时切NAT模式测试是最快的解决办法。如果确认需要桥接模式虚拟机里的IP必须和宿主机在同一个真实局域网网关指向你的路由器地址。手动配置时必须把网关和DNS都写对不然可能出现能ping通宿主机但SSH超时的怪现象。仅主机模式则相反它只允许宿主机和虚拟机互相访问IP网段由VMnet1决定。你需要确认Windows里的VMnet1网卡和虚拟机IP在同一个网段。这种模式适合练习SSH、测试服务配置但不适合要上网的场景。另外仅仅改了虚拟机IP却忘了看VMnet1的地址是仅主机模式下连接超时的最大原因。2.4 虚拟机的网卡可能根本没连上说一个看起来特别傻、但真实发生过的状况虚拟机的网络适配器设置里已连接和启动时连接两个复选框不知道什么时候被取消了。这样的话虚拟机里面虽然有网卡设备但网络链路是断的IP配置再合理也不可能连上。检查路径VMware菜单虚拟机→设置→网络适配器确认选择了正确的网络模式并且勾选了两个连接选项。我在帮人远程排查时至少有两次最后的答案就是这个——设备管理里看网卡在虚拟机里ip link显示状态却是DOWN一勾上就全通了。3. 三步定位法从ping不通到SSH超时故障究竟出在哪一层3.1 第一步确认虚拟网卡和VMware服务是活着的排查任何网络问题我习惯从最底层往上层查。首先看Windows的网络连接里VMnet1和VMnet8这两个虚拟网卡是否存在并且处于启用状态。如果这里显示网络电缆被拔出或者干脆看不到多半是VMware的虚拟网卡驱动出问题了或者相关服务没跑起来。在Windows下按WinR输入services.msc找到VMware NAT Service、VMware DHCP Service以及VMware Authorization Service确认这些服务的状态是正在运行。如果停用了右键启动如果启动报错卸载VMware后重装一次虚拟网卡驱动基本能解决。虚拟网络这个底层不健康后面排查IP和防火墙都是白费力气。3.2 第二步ping测试判断网络层通不通打开Windows命令行CMD输入ping 虚拟机IP。这一步会直接帮你把问题劈成两半ping不通说明问题在网络层大概率是IP网段不对、网络模式不对或者虚拟网卡配置有问题先去处理前面章节说的事情。ping通了但secureCRT就是超时说明网络层是通的问题出在更高层——也就是防火墙拦截了22端口或者SSH服务本身有毛病。另外有几种ping输出值也值得注意。请求超时表示对方没有任何回应可能被防火墙丢弃目标主机不可达说明连路由都找不到网段配错的可能性很大。如果ping通但有掉包可以试试清理ARP缓存arp -d然后再ping一次。有次我就是因为虚拟机做过克隆网卡MAC地址和ARP缓存里的记录对不上导致IP看着通又时断时续清了缓存立刻稳了。3.3 第三步测试22端口判断SSH服务是否在监听ping通之后下一步测试22端口。在Windows命令行里输入telnet 虚拟机IP 22注意Windows默认可能没装telnet客户端会提示不是内部或外部命令。你可以打开控制面板→程序→启用或关闭Windows功能勾选Telnet客户端或者用PowerShell执行Test-NetConnection -ComputerName 虚拟机IP -Port 22效果一样。这一步的结果价值巨大。如果telnet完全没反应最后提示连接超时基本可以断定是防火墙把入站的22端口数据包丢掉了如果提示无法打开到主机的连接连接被拒绝反而说明网络是通的但SSH服务没启动或者端口不对。connection timed out和connection refused是两码事前者等于敲门没人应后者等于门开着但里面说你找的人不在。我把这个区分讲清楚是因为我见过太多人一看到连接被拒绝就跑去关防火墙方向完全反了折腾半天下载好几百兆的镜像重装系统结果只是sshd服务没启动而已。4. 防火墙和SSH服务两个最容易被忽略的隐形杀手4.1 虚拟机里的防火墙默认就把你挡在外面Linux各发行版默认防火墙策略不一样但很多都默认放行SSH这并不意味着你可以忽略它。尤其是自己手动配置过IP、修改过端口或者用的是某些定制镜像防火墙极可能就是罪魁祸首。查看防火墙状态并临时关闭CentOS / Rocky / AlmaLinux上执行systemctl status firewalld systemctl stop firewalldUbuntu / Debian上执行sudo ufw status sudo ufw disable临时关掉后再用secureCRT试连。如果通了就说明是防火墙拦截。我不建议长期关闭防火墙正确的做法是放行22端口而不是禁掉整个防火墙# CentOS系 firewall-cmd --permanent --add-port22/tcp firewall-cmd --reload # Ubuntu系 sudo ufw allow 22/tcp这样既解决了连接问题又不至于把虚拟机裸奔在网络上。4.2 宿主机Windows防火墙也可能插一脚很多人只盯着虚拟机里的防火墙忘了Windows自己也有一道墙。NAT模式下secureCRT是从宿主机主动发起连接Windows防火墙通常不会拦出站流量一般没事。但在桥接模式下虚拟机的IP就和宿主机处于同一局域网了Windows防火墙入站规则可能拦住来自这个陌生人IP的22端口访问。还有一种情况是第三方安全软件比如各种电脑管家、360防火墙经常会把VMware的虚拟网卡流量或者secureCRT的连接行为当成可疑操作给拦了。验证方法很简单暂时退出安全软件关闭Windows Defender防火墙再试一次连接。如果能连上再逐步放行VMware相关进程不复现即可。改配置前记得把当前的防火墙规则导出来免得放行失败还把自己的网络搞乱。4.3 SSH服务没装、没启动、端口被改结果都是超时Ubuntu最小化安装时默认根本没有openssh-server这是超高频踩坑点。你装完了系统设置好了IPsecureCRT一填就报connection timed out——因为虚拟机里压根没有SSH服务在监听22端口。解决sudo apt update sudo apt install openssh-server -y sudo systemctl enable --now sshCentOS系一般是自带了sshd的但保不齐被精简掉或者服务没起来。检查命令统一是systemctl status sshd如果状态是inactivedead就启动它systemctl start sshd并设置开机自启systemctl enable sshd。还有一个容易踩的坑有人为了让更安全修改了SSH端口比如把sshd_config里的Port改成了2222。那你secureCRT里还填默认的22数据包发过去服务不在线表现就是超时或者被拒。花30秒检查一下grep -E ^Port /etc/ssh/sshd_config如果有输出且不是22就把secureCRT的端口改过去就这么简单。4.4 SELinux在CentOS系里的隐形拦截如果你用的是CentOS、Rocky、AlmaLinux这类系统还有一个容易忽略的家伙叫SELinux。它跑在防火墙底下专门对进程、文件、端口做强制访问控制。有时候你防火墙放行了、sshd也在跑但SELinux的策略不允许sshd绑定某个特殊端口或者不允许虚拟机在特定网络环境下被外部访问。排查命令getenforce如果输出是Enforcing可以临时放低级别测试setenforce 0然后重新连接secureCRT。如果通了说明确实和SELinux有关。长期来看不建议永久关闭SELinux而是应该用semanage port -a -t ssh_port_t -p tcp 2222这类命令把自定义端口加入策略或者直接改用默认端口更省心。新手可以先临时关闭把环境跑通再回头补SELinux的正确配置。5. 虚拟网络重置与一份可以直接抄的排查清单5.1 恢复默认设置为什么能治各种疑难杂症如果前面几步都试过了还不行别急着重装系统最后一个大招是重置VMware的虚拟网络配置。路径VMware菜单编辑→虚拟网络编辑器→右下角恢复默认设置。这一步会清掉之前所有手动改过的虚拟网络配置把VMnet1、VMnet8等虚拟网卡恢复到软件初始状态DHCP服务也会重新初始化。我遇到过的好几个灵异问题——比如虚拟机怎么也拿不到IP、ping通了自己网关但ping不通宿主机、NAT模式下丢包严重——最后都是靠这一招解决的。虚拟网络配置文件和Windows网络栈偶尔会出现状态错乱人眼看不出毛病但重启服务就是不见效恢复默认等于把数据库格式化了重新建效果立竿见影。注意恢复默认设置之后自定义的NAT网段会变回默认值。这时候虚拟机如果用的静态IP大概率又连不上了需要回到虚拟机里把IP改成新网段或者直接改成DHCP自动获取先保证能通再谈优化。5.2 别忘了重启Windows里的VMware服务和恢复默认设置配套的操作是重启VMware相关服务。在services.msc里找到VMware NAT Service、VMware DHCP Service右键重启。有时候虚拟机的网卡已经乱了重启服务就能让NAT和DHCP重新正常工作。顺序上我建议先重启服务再恢复默认设置最后重启虚拟机。一步步来每一步都验证一次不要一口气又是改配置又是重启出了问题不知道哪一步引起的。这算是排查问题的一个通用习惯一次只动一个变量。5.3 一份可以直接照着抄的排查清单老读者都知道我不喜欢给那种云里雾里的方法论直接上能落地的动作。根据实际经验我整理了一份按顺序执行的排查单虚拟机里运行ip addr把当前实际IP记下来。在Windows CMD里ping 这个IP确认网络层通不通。通了就telnet 这个IP 22看22端口是否有响应。22端口超时查虚拟机防火墙临时关闭firewalld/ufw验证。22端口拒绝查sshd服务状态、查sshd_config里的Port必要时重装并启动。ping不通检查VMware虚拟网络编辑器里的网段和虚拟机内配置是否一致检查VMnet1/VMnet8是否启用。以上都不行重启VMware相关服务然后恢复虚拟网络编辑器默认设置。再不行把虚拟机网络模式临时切成NAT甚至重新用VMware默认配置建一个最小虚拟机做对照实验。最后检查secureCRT会话配置协议选SSH、端口填22、主机名填虚拟机的IP用户名不要填错。检查虚拟机是否做过克隆。克隆系统的网卡配置里经常残留原机器的UUID和MAC会导致网络不对删掉重新生成即可。5.4 我的经验之谈文章写到这里我想说点实际的体会。在几乎所有的secureCRT连接超时案例里排名前三的原因分别是虚拟机网络模式没选对或没理解、Linux防火墙拦了入站流量、openssh-server根本没装。排在这之后的才是IP配置、网卡驱动这些更深的问题。很多新手喜欢一上来就折腾静态IP折腾一晚上头昏脑胀最后发现只要把网卡模式改成NAT、把DHCP开着根本不需要手动配IP。如果让我给一个从零到通的最快路径我会说新建虚拟机时网络选NATLinux装好后先ssh localhost确认本机SSH服务正常然后看ip addr里的地址在Windows里ping通再打开secureCRT去连全程不碰手动IP配置。这个顺序能避开至少80%的坑。我自己踩过的最深的一个坑是用了一个从朋友那里拷贝来的虚拟机镜像。折腾了半天怎么都超时最后发现那个镜像里配置的网卡MAC和这台机器VMware分配的MAC不一致虚拟网卡一直处于未激活状态。所以奉劝大家用别人的镜像或者克隆虚拟机之前一定要先检查网卡配置文件里的MAC、UUID删掉让系统重新生成能省下好几个小时的排查时间。希望这份经验能帮你少走点弯路。下次再遇到connection timed out先别急着怀疑人生按这个清单一步步来问题多半在第4步之前就已经解决了。
