尧图网站建设 
Ping 通却 SSH Connection refusedWindows 连 Linux 连踩 4 坑IP 冲突、掩码、双网口、VLAN 隔离标签建议#Linux #SSH #网络排查 #Connection refused #VLAN #ARP #运维分类建议运维 / Linux配图已生成无需实拍。封面用images/00-cover.png。发 CSDN 时把images目录下 10 张 PNG 逐张上传编辑器里拖进去即可不要用本地相对路径。目录建议直接用 CSDN 目录功能生成一、引言ping 通了SSH 凭什么还 Connection refused二、问题根源分析先分清三种“连不上”再谈 SSH2.1 环境与拓扑4 个物理口、4 张网卡全是陷阱2.2 Connection refused / 超时 / 无法访问分别卡在哪一层2.3 为什么“ping 通”完全不能证明 SSH 能通三、详细解决方案连续踩中的四个坑每一关都是假象3.1 最短证据链先跑这 12 条5 分钟定层3.2 第一关IP 冲突——ping 通的其实是自己TTL1283.3 第二关子网掩码不匹配——被当成跨网段丢掉3.4 第三关双网口混淆——Link detected 不代表线在这个口3.5 第四关交换机 VLAN 隔离——真正耗掉 2 小时的根因3.6 最终解决物理上真·直连中间什么都不要3.7 不能拔线时的替代方案机房现实四、效果验证TTL、ARP、TCP 22 三条证据必须同时成立五、总结与延伸OSI 从下往上抓不到包就不要查 sshd权威参考一、引言ping 通了SSH 凭什么还 Connection refused服务器和电脑都配好了 IPping也“通”了SSH 却死活连不上Xshell / FinalShell 甩过来一句Network error: Connection refused Session stopped这个看似入门级的问题我从下午三点折腾到天黑。连续踩了四个坑IP 冲突、子网掩码不匹配、双网口物理口混淆、交换机 VLAN 二层隔离。每一关看似解决下一关才真正暴露。整场排障最大的教训只有一句每一个“已经通了”的信号都可能是假象。ping通不等于连的是目标机器Link detected: yes不等于二层通插在同一台服务器上也不等于直连。这篇文章按「现象 → 定位过程 → 根因分析 → 解决方案 → 验证结果」完整复盘最后给出一套可直接复用的OSI 七层排障 checklist和Linux / Windows 双端命令速查。下次再遇到「ping 通但 SSH 连不上」按清单走不必再从防火墙和sshd_config盲改起。Ping 通不等于 SSH 通Connection refused 四连坑封面环境说明角色系统 / 工具说明服务端RHEL / CentOS / openEuler 系firewalld NetworkManager命令对其它发行版同样适用客户端Windows 10 / 11有线 Wi-Fi VMware VMnet1/VMnet8 同时在线SSH 客户端Xshell / FinalShell / 系统自带ssh报错语义一致Debian / Ubuntu把firewalld换成ufw即可其余ip/ss/tcpdump/ethtool通用四个假象耗掉一个下午IP 冲突、掩码、双网口、VLAN二、问题根源分析先分清三种“连不上”再谈 SSH很多人一看到 SSH 失败手就伸向sshd_config和防火墙。我下午前两个小时就是这么浪费的。网络问题必须先定层包有没有出门、ARP 有没有成功、TCP 有没有人理。层没定对上层检查全部无效。2.1 环境与拓扑4 个物理口、4 张网卡全是陷阱服务器背面有 4 个物理网口。端口丝印Port-A/B/C/D和内核网卡名eth0/eth1不是一一对应的必须实测不能靠猜。端口标识角色接线状态系统中对应网卡Mgmt专用管理口未使用-Port-A共享网口接线通往楼层交换机-Port-B物理网口 1黑色网线通往交换机eth0Port-C物理网口 2空着-Port-D物理网口 3蓝色网线我以为直连eth1服务器背面物理口丝印不等于内核网卡名 eth0/eth1最终正确的地址规划如下排障过程中两端都曾经配错过[rootserver ~]# ip addr 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 inet 10.20.1.11/20 brd 10.20.15.255 scope global eth0 # Port-B黑色线通往楼层交换机业务网段 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 inet 172.16.5.63/24 brd 172.16.5.255 scope global eth1 # Port-D蓝色线本意是直连 Windowsvirbr0libvirt和docker0Docker与本次无关排障时先忽略避免被虚拟网桥的 192.168.x 带偏。SSH 服务本身当时是正常的——这也是最容易让人放松警惕的地方[rootserver ~]# ss -tulnp | grep sshd tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:((sshd,pid1234,fd3)) tcp LISTEN 0 128 [::]:22 [::]:* users:((sshd,pid1234,fd4)) [rootserver ~]# firewall-cmd --list-services dhcpv6-client mdns ssh [rootserver ~]# grep PermitRootLogin /etc/ssh/sshd_config PermitRootLogin yes四项都正常监听0.0.0.0:22、firewalld 放行ssh、PermitRootLogin yes、没有明显 deny。所以后来证明问题从来不在 SSH 应用层。你在 L7 改配置解决不了 L2 的 VLAN。客户端 Windows 同时有 4 个活跃接口这是第二颗定时炸弹以太网适配器 以太网: 描述: Realtek PCIe GbE Family Controller 物理地址: AA-BB-CC-DD-EE-01 IPv4 地址: 172.16.5.100手动配置 子网掩码: 255.255.255.0 DHCP: 否 无线局域网适配器 WLAN: IPv4 地址: 10.50.38.200 以太网适配器 VMware Network Adapter VMnet1: IPv4 地址: 192.168.202.1 以太网适配器 VMware Network Adapter VMnet8: IPv4 地址: 192.168.40.1Windows 多网卡时会按路由度量选源 IP。你以为 ping 从有线出去实际可能从 Wi-Fi 或 VMnet 出去。多网卡场景必须用ping -S 源IP锁死出口否则证据链从第一步就脏了。2.2 Connection refused / 超时 / 无法访问分别卡在哪一层把三种报错钉死后面四关才不会查错层客户端报错协议语义卡在哪一层典型根因Connection refused收到TCP RST对端明确拒绝 22 端口L4连到了一台没开 sshd 的机器包括你自己或防火墙是REJECT而不是 DROP请求超时/ Request timed outICMP/TCP 已经发出去对端没回L3 及以上掩码把对端判成跨网段防火墙DROP对端宕机路由黑洞无法访问目标主机/ Destination host unreachableARP 没人应本机连对方 MAC 都不知道包根本发不出去L2VLAN 隔离、网线没到同一广播域、对端网卡 down三种连不上分别卡在 L4 RST、L3 超时、L2 ARP 失败补充三个容易混的点firewalld/iptables REJECT → Connection refusedDROP → 超时。所以“SSH refused 一定是防火墙”这句本身就不严谨更何况你可能连的根本不是那台 Linux。Windows 的「无法访问目标主机」很多时候是本机回的 ICMP不是服务器回的。看到它优先查 ARP 表不要去翻/etc/ssh/sshd_config。第一关里我看到的Connection refused真正含义是ping 和 SSH 都打到了Windows 自己。Windows 默认不监听 22协议栈直接 RST。ping 能通、SSH 被拒在「连到自己」这个模型里是完全自洽的。2.3 为什么“ping 通”完全不能证明 SSH 能通ICMP Echo 和 TCP/22 是两条路ping 只证明某台声称拥有该 IP 的设备对 ICMP 做了应答。它不证明那台设备是 Linux更不证明 22 端口可达。TTL 才是“这是谁回的”的指纹。常见默认 TTL操作系统 / 设备默认 TTLLinux / Android64Windows128部分网络设备255每过一跳减 1。直连场景下你看到TTL128回包来自 WindowsTTL64才像 Linux 内核。时延1ms再叠 TTL128要高度怀疑 ping 的是本机。三、详细解决方案连续踩中的四个坑每一关都是假象3.1 最短证据链先跑这 12 条5 分钟定层把下面两边命令各跑一遍再决定查哪一层。不要一上来改sshd_config。Linux 一键取证可直接粘贴#!/usr/bin/env bash # ssh-l2-triage.sh 用法: bash ssh-l2-triage.sh eth1 172.16.5.100 set -euo pipefail IFACE${1:-eth1} PEER${2:-172.16.5.100} echo L1 链路 ethtool $IFACE | egrep Link detected|Speed|Duplex || true echo L3 地址/路由 ip -br addr show $IFACE ip route show dev $IFACE echo L2 邻居 ip neigh show dev $IFACE echo L4 sshd / 防火墙 ss -tulnp | grep -E :22\s || true systemctl is-active sshd 2/dev/null || systemctl is-active ssh 2/dev/null || true firewall-cmd --list-services 2/dev/null || true echo 对端 ARP/ICMP 抓 8 秒 timeout 8 tcpdump -i $IFACE -nn -c 30 host $PEER or arp or stp 2/dev/null || trueWindows 一键取证管理员 PowerShell$src 172.16.5.100 $dst 172.16.5.63 ipconfig /all arp -a ping -n 4 -S $src $dst Test-NetConnection $dst -Port 22 | Format-List Get-NetRoute -AddressFamily IPv4 | Where-Object { $_.DestinationPrefix -like 172.16.5.* -or $_.DestinationPrefix -eq 0.0.0.0/0 }定层口诀拔掉网线还能 ping 通 → 100% 在 ping 自己。arp -a里没有对端 MAC → 先查 L2不要查防火墙。tcpdump抓不到对端任何帧 → 问题在 L1/L2sshd 日志不用看。3.2 第一关IP 冲突——ping 通的其实是自己TTL128症状最初服务器配的是10.20.1.11Windows 有线网卡也配了10.20.1.11复制配置时忘了改。现象就是教科书级的「ping 通、SSH refused」C:\ ping 10.20.1.11 正在 Ping 10.20.1.11 具有 32 字节的数据: 来自 10.20.1.11 的回复: 字节32 时间1ms TTL128 来自 10.20.1.11 的回复: 字节32 时间1ms TTL128ping TTL128 且时延小于 1ms说明回包来自 Windows 自己根因关键线索是 TTL。Linux 默认 64Windows 默认 128。返回 128说明这个包根本不是服务器回的是 Windows 自己回给自己。原理两台机器配了同一个 IP。本机协议栈发现「这个 IP 是我」ICMP 在本地应答包甚至可以不出网卡。你看到的「ping 通」等价于ping 127.0.0.1。SSH 打到本机 22 端口Windows 没人 listen于是Connection refused。判定技巧看到时间1ms且 TTL 与本机系统一致先怀疑 ping 自己。拔掉网线再 ping还能通就 100% 是本机。再看 ARP冲突时 ARP 解析可能随机指向其中一台现象会在「通 / 不通 / 通的是另一台」之间跳这类问题最隐蔽。解决把两端地址错开不要再共用业务网段的同一个主机号服务器 eth1172.16.5.63/24Windows 以太网172.16.5.100/24验证改完再 pingTTL 若还是 128说明还有冲突或源 IP 选错了变成64才真正到达 Linux。教训ping 通不等于连的是目标机器。先看 TTL再谈 SSH。3.3 第二关子网掩码不匹配——被当成跨网段丢掉症状Windows 改成172.16.5.100后掩码随手填了255.255.255.0/24。服务器 eth1 是从10.20.1.11/20改过来的掩码一度残留 /20C:\ ping 172.16.5.63 请求超时。 请求超时。根因掩码决定主机对「本地子网」的判断范围主机IP/掩码本机认为的本地子网Windows172.16.5.100/24172.16.5.0 172.16.5.255服务器错误状态172.16.5.63/20172.16.0.0 172.16.15.255两端对「是否同一子网」判断不一致时主机会把对端 IP 当成跨网段地址包交给默认网关而不是直接 ARP。直连场景通常没有可用网关包被丢掉表现为「请求超时」。直连必须同网段、同掩码。只差一位掩码都可能失败。改 IP 时要同时核对三项地址、掩码、广播地址。解决统一172.16.5.0/24nmcli connection modify eth1 ipv4.addresses 172.16.5.63/24 nmcli connection modify eth1 ipv4.method manual nmcli connection up eth1 ip addr show eth1Windows 在「以太网属性 → IPv4」里填IP172.16.5.100掩码255.255.255.0网关直连可留空不要填一个不存在的网关把包拐走验证两边ip addr/ipconfig对一下IP、掩码、广播必须落在同一网段。然后用指定源地址 pingC:\ ping -S 172.16.5.100 172.16.5.63教训改 IP 不要只改主机号。掩码是子网的边界合同两端必须签同一份。3.4 第三关双网口混淆——Link detected 不代表线在这个口症状掩码和 IP 都对了还是 ping 不通。服务器上两个口都是链路 up[rootserver ~]# ethtool eth0 | grep Link Link detected: yes [rootserver ~]# ethtool eth1 | grep Link Link detected: yes背面 Port-B、Port-D 都插着线。蓝色线到底对应 eth0 还是 eth1它是不是「直连」线全不确定。ethtool 两个网口都是 Link detected yesL1 up 无法区分是哪根线根因Link detected: yes只代表物理层L1链路 up也就是「这根线另一端有电信号」。它不回答三个问题这根线是不是我现在要测的那根另一端接的是 Windows 还是交换机这个物理口对应内核里的 eth0 还是 eth14 个口里有 3 个接了线任何一根都可以在 ethtool 里显示 yes。定位方法三条从快到准方法 1拔线测试最直接watch -n 1 ethtool eth0 | grep Link; ethtool eth1 | grep Link到机柜后面一根根拔。哪个口从 yes 变成 no映射就建立了。方法 2tcpdump 抓包Windows 持续ping -t -S 172.16.5.100 172.16.5.63服务器上分网卡抓# 终端 1 tcpdump -i eth0 -n icmp # 终端 2 tcpdump -i eth1 -n icmp哪个口能抓到源地址172.16.5.100的 ICMP哪个口才是「你以为的直连口」。方法 3LED 闪烁定位部分网卡支持ethtool -p eth1 10对应物理口的灯闪 10 秒人到机房看一眼即可。不支持会报Cannot identify NIC改用方法 1/2。教训Link up ≠ 你的线在这个口。物理口和网卡名的映射必须用拔线、抓包或 LED实测不要靠「我记得」。3.5 第四关交换机 VLAN 隔离——真正耗掉 2 小时的根因症状IP、掩码、端口映射全部确认正确Windows172.16.5.100/24服务器 eth1172.16.5.63/24蓝色网线确认在 eth1ping 的报错却变成了另一种C:\ ping -S 172.16.5.100 172.16.5.63 正在 Ping 172.16.5.63 从 172.16.5.100 具有 32 字节的数据: 来自 172.16.5.100 的回复: 无法访问目标主机。 来自 172.16.5.100 的回复: 无法访问目标主机。注意主语来自 172.16.5.100 的回复。这是 Windows 自己说「我发不出去」不是 Linux 拒绝你。这是整场排障最关键的判断点错误信息含义所在层请求超时ARP 多半已经解析ICMP 已发出对方没回L3 及以上无法访问目标主机ARP 广播没人应本机不知道对方 MACL2这时候再查防火墙、SSH、路由都是在上层空转。验证ARP 表为空C:\ arp -a 接口: 172.16.5.100 --- 0xc Internet 地址 物理地址 类型 172.16.5.255 ff-ff-ff-ff-ff-ff 静态 224.0.0.22 01-00-5e-00-00-16 静态 # 没有 172.16.5.63 的条目服务器同样失败[rootserver ~]# ip neigh show 172.16.5.100 dev eth1 FAILED双向 ARP 都 FAILED意味着二层广播域里根本没有对方。VLAN 的本质就是切开广播域ARP Request 是广播跨不过 802.1Q 边界。关键证据tcpdump[rootserver ~]# tcpdump -i eth1 -n -c 500抓到的内容让「直连」这个假设当场破产14:32:05.123456 ARP, Request who-has 172.16.8.233 tell 172.16.8.1 14:32:05.234567 ARP, Reply 172.16.8.233 is-at aa:bb:cc:dd:ee:ff 14:32:05.345678 STP 802.1s, Rapid STP, CIST Flags [Learn, Forward, Agreement] 14:32:05.456789 STP 802.1s, Rapid STP, CIST Flags [Learn, Forward] 14:32:06.567890 DHCP, Request from aa:bb:cc:dd:ee:ff 14:32:06.678901 mDNS from 172.16.5.1tcpdump 抓到 STP BPDU 且没有来自 Windows 的包三个发现每一个都在打脸STP802.1s Rapid STP只有管理型交换机才发 BPDU。普通跳线直连两台主机不可能出现 STP。出现172.16.8.233的 ARP跟我们的172.16.5.x不是同一网段说明线背后是一张有多个 VLAN 的交换网络。完全没有来自172.16.5.100的任何包Windows 发出的 ARP 广播根本没到 eth1。我以为的直连对比实际经过墙面板配线架和不同 VLAN 的路径顺着蓝色网线往机柜里捋真实路径是Windows 网口 ↓ 墙面 RJ45 面板 ↓ 弱电间配线架 ↓ 楼层管理型交换机某个 VLAN ↓ 另一根跳线 ↓ 服务器 Port-Deth1另一个 VLAN两端交换机端口划在不同 VLAN。物理链路是通的Link detected: yes数据链路层被逻辑切断。ARP 过不去ICMP 出不去SSH 更无从谈起。教训「插在同一台服务器上」不等于直连。中间只要经过交换机就要考虑 VLAN、端口隔离、STP。tcpdump是网络排障的终极武器抓不到对方的包问题一定在物理层或数据链路层。看到 Destination host unreachable 而不是 Request timed out优先查 ARP 和 VLAN而不是防火墙。3.6 最终解决物理上真·直连中间什么都不要拔掉 Port-D 上那根「以为直连」的蓝色网线找一根成品跳线一头直接插服务器 Port-D一头直接插 Windows 的 RJ45中间不经过墙面板、配线架、交换机再 pingC:\ ping 172.16.5.63 正在 Ping 172.16.5.63 具有 32 字节的数据: 来自 172.16.5.63 的回复: 字节32 时间1ms TTL64 来自 172.16.5.63 的回复: 字节32 时间1ms TTL64TTL64Linux 内核。这一次 ping 到的才是目标机器。[rootserver ~]# ip neigh show 172.16.5.100 dev eth1 lladdr AA:BB:CC:DD:EE:01 REACHABLESSH 一次登录成功login as: root root172.16.5.63s password: Last login: Tue Aug 11 13:45:22 2026 from 172.16.5.100TTL64、ARP REACHABLE、SSH 登录成功三条证据同时成立3.7 不能拔线时的替代方案机房现实不是每次都能拖一根新跳线穿过过道。不能物理直连时目标仍然是同一个二层广播域做法适用注意把两端交换机口划进同一 Access VLAN有交换机管理权限确认不是 PVLAN / 端口隔离中间加一台傻瓜交换机不划分 VLAN临时联调不要再接入楼层汇聚走已通的业务网 eth010.20.1.11做 SSH只想登录、不坚持直连网段确认防火墙与安全组放行 22带外Mgmt 口 / iLO / iDRAC / BMC生产机房标准姿势管理口通常在独立网段生产环境更推荐带外管理而不是靠一根「我记得是直连」的蓝色线。四、效果验证TTL、ARP、TCP 22 三条证据必须同时成立「看起来能 ping 了」不够。三条同时成立才允许宣布 SSH 链路正常检查项通过标准命令ICMP 身份TTL64Linux且拔线后立刻不通ping -S 172.16.5.100 172.16.5.63二层邻居双方 ARP 为动态可达Windowsarp -aLinuxip neigh show为REACHABLETCP/22端口通而不是 RST / 超时PowerShellTest-NetConnection 172.16.5.63 -Port 22Windows 端口验证示例C:\ Test-NetConnection 172.16.5.63 -Port 22 ComputerName : 172.16.5.63 RemoteAddress : 172.16.5.63 RemotePort : 22 TcpTestSucceeded : TrueLinux 侧再确认连接来源是有线网段而不是 Wi-Fi 或 VMnetss -tnp | grep :22 # 应看到 172.16.5.100:* ESTAB sshd四轮排障对照发文时建议做成表格图阅读完成率更高轮次表面症状实际根因耗时1ping 通但 SSH refused两台同 IPping 到自己TTL128SSH RST 来自 Windows约 30 分钟2ping 请求超时/24 与 /20 不一致被判跨网段约 20 分钟3链路 up 但不通信物理口与 eth 名映射不明约 15 分钟4ARP FAILED / 无法访问目标主机网线经交换机两端不同 VLAN约 2 小时四个最能误导人的假象建议直接做成文末金句「ping 能通」≠ 网络正常—— 可能是 ping 自己TTL 会出卖它。「Link detected: yes」≠ 网络通了—— 只代表 L1 upL2 可以被 VLAN 切断。「未识别的网络」≠ 网线没插好—— 这往往说明 link 已经 up只是没拿到 DHCP/网关。「无法访问目标主机」≠ 对方防火墙拦截—— 这是 ARP 失败比防火墙更底层。五、总结与延伸OSI 从下往上抓不到包就不要查 sshdOSI 从物理层到应用层自下而上排障抓不到包不要查 sshd为什么花了这么久我一开始盯着 SSH 配置和防火墙L4/L7问题其实在 L2。如果第一小时就抓 ARP至少能少走一小时冤枉路。另一条教训是不要相信「我记得」——我记得那根蓝色线是直连 Windows 的实际上它经过了墙面板、配线架和楼层交换机。机房里任何「以为」都要用工具验证。下次 5 分钟自查10 条两端 IP 是否冲突改一下本机 IP 再 ping看 TTL 是不是 64。两端子网掩码是否完全一致两端是否在同一网段广播地址对不对多网卡是否用了ping -S指定源地址arp -a/ip neigh show里有没有对端 MAC报错是「请求超时」还是「无法访问目标主机」后者查 L2。ethtool是否 yes网卡灯是否在闪这根「直连线」中间是否经过墙面板、配线架或交换机tcpdump能否抓到对端 ARP/ICMP抓不到就是 L1/L2。服务端是否监听0.0.0.0:22防火墙放行的是 ssh 服务而不是只放了 pingLinux 速查目的命令查看 IP/掩码/状态ip addr物理链路ethtool 网卡名网卡灯闪烁定位ethtool -p 网卡名 10抓全部tcpdump -i 网卡名 -nn只抓 ARPtcpdump -i 网卡名 arp -n只抓 ICMPtcpdump -i 网卡名 icmp -n -c 5抓包落盘tcpdump -i 网卡名 -w capture.pcapARP 表ip neigh show清空 ARPip neigh flush all路由ip route监听端口ss -tulnp | grep sshd防火墙服务firewall-cmd --list-servicesSSH 登录日志tail -f /var/log/securesshd 状态systemctl status sshdWindows 速查目的命令所有网卡ipconfig /all指定源 IP pingping -S 本机IP 目标IP持续 pingping -t 目标IPARP 表arp -a清空 ARPnetsh interface ip delete arpcache路由表route print路径tracert 目标IP测 TCP 22Test-NetConnection 目标IP -Port 22临时关防火墙仅定位netsh advfirewall set allprofiles state off立刻开回去netsh advfirewall set allprofiles state on临时关防火墙只用于对比「是不是本机策略在 DROP/REJECT」测完必须打开。生产环境不要用这个当常规手段。一句话物理链路通不等于网络层通。一根经过交换机的网线VLAN 可以在二层把通信切干净而所有物理层指示灯都告诉你「一切正常」。最可靠的直连就是一根线从 A 到 B中间什么都没有。抓不到对方的包就一定是底层问题——不要在防火墙和 SSH 配置上浪费下一个下午。权威参考tcpdump man pageethtool(8)ip-address(8) / ip-neighbour(8)sshd_config(5)firewalld 文档RFC 826 - An Ethernet Address Resolution ProtocolRFC 792 - Internet Control Message ProtocolIEEE 802.1Q VLANMicrosoft Docs: pingMicrosoft Docs: Test-NetConnection Ping 通却 SSH Connection refused？Windows 连 Linux 连踩 4 坑：IP 冲突、掩码、双网口、VLAN 隔离
Ping 通却 SSH Connection refusedWindows 连 Linux 连踩 4 坑IP 冲突、掩码、双网口、VLAN 隔离标签建议#Linux #SSH #网络排查 #Connection refused #VLAN #ARP #运维分类建议运维 / Linux配图已生成无需实拍。封面用images/00-cover.png。发 CSDN 时把images目录下 10 张 PNG 逐张上传编辑器里拖进去即可不要用本地相对路径。目录建议直接用 CSDN 目录功能生成一、引言ping 通了SSH 凭什么还 Connection refused二、问题根源分析先分清三种“连不上”再谈 SSH2.1 环境与拓扑4 个物理口、4 张网卡全是陷阱2.2 Connection refused / 超时 / 无法访问分别卡在哪一层2.3 为什么“ping 通”完全不能证明 SSH 能通三、详细解决方案连续踩中的四个坑每一关都是假象3.1 最短证据链先跑这 12 条5 分钟定层3.2 第一关IP 冲突——ping 通的其实是自己TTL1283.3 第二关子网掩码不匹配——被当成跨网段丢掉3.4 第三关双网口混淆——Link detected 不代表线在这个口3.5 第四关交换机 VLAN 隔离——真正耗掉 2 小时的根因3.6 最终解决物理上真·直连中间什么都不要3.7 不能拔线时的替代方案机房现实四、效果验证TTL、ARP、TCP 22 三条证据必须同时成立五、总结与延伸OSI 从下往上抓不到包就不要查 sshd权威参考一、引言ping 通了SSH 凭什么还 Connection refused服务器和电脑都配好了 IPping也“通”了SSH 却死活连不上Xshell / FinalShell 甩过来一句Network error: Connection refused Session stopped这个看似入门级的问题我从下午三点折腾到天黑。连续踩了四个坑IP 冲突、子网掩码不匹配、双网口物理口混淆、交换机 VLAN 二层隔离。每一关看似解决下一关才真正暴露。整场排障最大的教训只有一句每一个“已经通了”的信号都可能是假象。ping通不等于连的是目标机器Link detected: yes不等于二层通插在同一台服务器上也不等于直连。这篇文章按「现象 → 定位过程 → 根因分析 → 解决方案 → 验证结果」完整复盘最后给出一套可直接复用的OSI 七层排障 checklist和Linux / Windows 双端命令速查。下次再遇到「ping 通但 SSH 连不上」按清单走不必再从防火墙和sshd_config盲改起。Ping 通不等于 SSH 通Connection refused 四连坑封面环境说明角色系统 / 工具说明服务端RHEL / CentOS / openEuler 系firewalld NetworkManager命令对其它发行版同样适用客户端Windows 10 / 11有线 Wi-Fi VMware VMnet1/VMnet8 同时在线SSH 客户端Xshell / FinalShell / 系统自带ssh报错语义一致Debian / Ubuntu把firewalld换成ufw即可其余ip/ss/tcpdump/ethtool通用四个假象耗掉一个下午IP 冲突、掩码、双网口、VLAN二、问题根源分析先分清三种“连不上”再谈 SSH很多人一看到 SSH 失败手就伸向sshd_config和防火墙。我下午前两个小时就是这么浪费的。网络问题必须先定层包有没有出门、ARP 有没有成功、TCP 有没有人理。层没定对上层检查全部无效。2.1 环境与拓扑4 个物理口、4 张网卡全是陷阱服务器背面有 4 个物理网口。端口丝印Port-A/B/C/D和内核网卡名eth0/eth1不是一一对应的必须实测不能靠猜。端口标识角色接线状态系统中对应网卡Mgmt专用管理口未使用-Port-A共享网口接线通往楼层交换机-Port-B物理网口 1黑色网线通往交换机eth0Port-C物理网口 2空着-Port-D物理网口 3蓝色网线我以为直连eth1服务器背面物理口丝印不等于内核网卡名 eth0/eth1最终正确的地址规划如下排障过程中两端都曾经配错过[rootserver ~]# ip addr 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 inet 10.20.1.11/20 brd 10.20.15.255 scope global eth0 # Port-B黑色线通往楼层交换机业务网段 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 inet 172.16.5.63/24 brd 172.16.5.255 scope global eth1 # Port-D蓝色线本意是直连 Windowsvirbr0libvirt和docker0Docker与本次无关排障时先忽略避免被虚拟网桥的 192.168.x 带偏。SSH 服务本身当时是正常的——这也是最容易让人放松警惕的地方[rootserver ~]# ss -tulnp | grep sshd tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:((sshd,pid1234,fd3)) tcp LISTEN 0 128 [::]:22 [::]:* users:((sshd,pid1234,fd4)) [rootserver ~]# firewall-cmd --list-services dhcpv6-client mdns ssh [rootserver ~]# grep PermitRootLogin /etc/ssh/sshd_config PermitRootLogin yes四项都正常监听0.0.0.0:22、firewalld 放行ssh、PermitRootLogin yes、没有明显 deny。所以后来证明问题从来不在 SSH 应用层。你在 L7 改配置解决不了 L2 的 VLAN。客户端 Windows 同时有 4 个活跃接口这是第二颗定时炸弹以太网适配器 以太网: 描述: Realtek PCIe GbE Family Controller 物理地址: AA-BB-CC-DD-EE-01 IPv4 地址: 172.16.5.100手动配置 子网掩码: 255.255.255.0 DHCP: 否 无线局域网适配器 WLAN: IPv4 地址: 10.50.38.200 以太网适配器 VMware Network Adapter VMnet1: IPv4 地址: 192.168.202.1 以太网适配器 VMware Network Adapter VMnet8: IPv4 地址: 192.168.40.1Windows 多网卡时会按路由度量选源 IP。你以为 ping 从有线出去实际可能从 Wi-Fi 或 VMnet 出去。多网卡场景必须用ping -S 源IP锁死出口否则证据链从第一步就脏了。2.2 Connection refused / 超时 / 无法访问分别卡在哪一层把三种报错钉死后面四关才不会查错层客户端报错协议语义卡在哪一层典型根因Connection refused收到TCP RST对端明确拒绝 22 端口L4连到了一台没开 sshd 的机器包括你自己或防火墙是REJECT而不是 DROP请求超时/ Request timed outICMP/TCP 已经发出去对端没回L3 及以上掩码把对端判成跨网段防火墙DROP对端宕机路由黑洞无法访问目标主机/ Destination host unreachableARP 没人应本机连对方 MAC 都不知道包根本发不出去L2VLAN 隔离、网线没到同一广播域、对端网卡 down三种连不上分别卡在 L4 RST、L3 超时、L2 ARP 失败补充三个容易混的点firewalld/iptables REJECT → Connection refusedDROP → 超时。所以“SSH refused 一定是防火墙”这句本身就不严谨更何况你可能连的根本不是那台 Linux。Windows 的「无法访问目标主机」很多时候是本机回的 ICMP不是服务器回的。看到它优先查 ARP 表不要去翻/etc/ssh/sshd_config。第一关里我看到的Connection refused真正含义是ping 和 SSH 都打到了Windows 自己。Windows 默认不监听 22协议栈直接 RST。ping 能通、SSH 被拒在「连到自己」这个模型里是完全自洽的。2.3 为什么“ping 通”完全不能证明 SSH 能通ICMP Echo 和 TCP/22 是两条路ping 只证明某台声称拥有该 IP 的设备对 ICMP 做了应答。它不证明那台设备是 Linux更不证明 22 端口可达。TTL 才是“这是谁回的”的指纹。常见默认 TTL操作系统 / 设备默认 TTLLinux / Android64Windows128部分网络设备255每过一跳减 1。直连场景下你看到TTL128回包来自 WindowsTTL64才像 Linux 内核。时延1ms再叠 TTL128要高度怀疑 ping 的是本机。三、详细解决方案连续踩中的四个坑每一关都是假象3.1 最短证据链先跑这 12 条5 分钟定层把下面两边命令各跑一遍再决定查哪一层。不要一上来改sshd_config。Linux 一键取证可直接粘贴#!/usr/bin/env bash # ssh-l2-triage.sh 用法: bash ssh-l2-triage.sh eth1 172.16.5.100 set -euo pipefail IFACE${1:-eth1} PEER${2:-172.16.5.100} echo L1 链路 ethtool $IFACE | egrep Link detected|Speed|Duplex || true echo L3 地址/路由 ip -br addr show $IFACE ip route show dev $IFACE echo L2 邻居 ip neigh show dev $IFACE echo L4 sshd / 防火墙 ss -tulnp | grep -E :22\s || true systemctl is-active sshd 2/dev/null || systemctl is-active ssh 2/dev/null || true firewall-cmd --list-services 2/dev/null || true echo 对端 ARP/ICMP 抓 8 秒 timeout 8 tcpdump -i $IFACE -nn -c 30 host $PEER or arp or stp 2/dev/null || trueWindows 一键取证管理员 PowerShell$src 172.16.5.100 $dst 172.16.5.63 ipconfig /all arp -a ping -n 4 -S $src $dst Test-NetConnection $dst -Port 22 | Format-List Get-NetRoute -AddressFamily IPv4 | Where-Object { $_.DestinationPrefix -like 172.16.5.* -or $_.DestinationPrefix -eq 0.0.0.0/0 }定层口诀拔掉网线还能 ping 通 → 100% 在 ping 自己。arp -a里没有对端 MAC → 先查 L2不要查防火墙。tcpdump抓不到对端任何帧 → 问题在 L1/L2sshd 日志不用看。3.2 第一关IP 冲突——ping 通的其实是自己TTL128症状最初服务器配的是10.20.1.11Windows 有线网卡也配了10.20.1.11复制配置时忘了改。现象就是教科书级的「ping 通、SSH refused」C:\ ping 10.20.1.11 正在 Ping 10.20.1.11 具有 32 字节的数据: 来自 10.20.1.11 的回复: 字节32 时间1ms TTL128 来自 10.20.1.11 的回复: 字节32 时间1ms TTL128ping TTL128 且时延小于 1ms说明回包来自 Windows 自己根因关键线索是 TTL。Linux 默认 64Windows 默认 128。返回 128说明这个包根本不是服务器回的是 Windows 自己回给自己。原理两台机器配了同一个 IP。本机协议栈发现「这个 IP 是我」ICMP 在本地应答包甚至可以不出网卡。你看到的「ping 通」等价于ping 127.0.0.1。SSH 打到本机 22 端口Windows 没人 listen于是Connection refused。判定技巧看到时间1ms且 TTL 与本机系统一致先怀疑 ping 自己。拔掉网线再 ping还能通就 100% 是本机。再看 ARP冲突时 ARP 解析可能随机指向其中一台现象会在「通 / 不通 / 通的是另一台」之间跳这类问题最隐蔽。解决把两端地址错开不要再共用业务网段的同一个主机号服务器 eth1172.16.5.63/24Windows 以太网172.16.5.100/24验证改完再 pingTTL 若还是 128说明还有冲突或源 IP 选错了变成64才真正到达 Linux。教训ping 通不等于连的是目标机器。先看 TTL再谈 SSH。3.3 第二关子网掩码不匹配——被当成跨网段丢掉症状Windows 改成172.16.5.100后掩码随手填了255.255.255.0/24。服务器 eth1 是从10.20.1.11/20改过来的掩码一度残留 /20C:\ ping 172.16.5.63 请求超时。 请求超时。根因掩码决定主机对「本地子网」的判断范围主机IP/掩码本机认为的本地子网Windows172.16.5.100/24172.16.5.0 172.16.5.255服务器错误状态172.16.5.63/20172.16.0.0 172.16.15.255两端对「是否同一子网」判断不一致时主机会把对端 IP 当成跨网段地址包交给默认网关而不是直接 ARP。直连场景通常没有可用网关包被丢掉表现为「请求超时」。直连必须同网段、同掩码。只差一位掩码都可能失败。改 IP 时要同时核对三项地址、掩码、广播地址。解决统一172.16.5.0/24nmcli connection modify eth1 ipv4.addresses 172.16.5.63/24 nmcli connection modify eth1 ipv4.method manual nmcli connection up eth1 ip addr show eth1Windows 在「以太网属性 → IPv4」里填IP172.16.5.100掩码255.255.255.0网关直连可留空不要填一个不存在的网关把包拐走验证两边ip addr/ipconfig对一下IP、掩码、广播必须落在同一网段。然后用指定源地址 pingC:\ ping -S 172.16.5.100 172.16.5.63教训改 IP 不要只改主机号。掩码是子网的边界合同两端必须签同一份。3.4 第三关双网口混淆——Link detected 不代表线在这个口症状掩码和 IP 都对了还是 ping 不通。服务器上两个口都是链路 up[rootserver ~]# ethtool eth0 | grep Link Link detected: yes [rootserver ~]# ethtool eth1 | grep Link Link detected: yes背面 Port-B、Port-D 都插着线。蓝色线到底对应 eth0 还是 eth1它是不是「直连」线全不确定。ethtool 两个网口都是 Link detected yesL1 up 无法区分是哪根线根因Link detected: yes只代表物理层L1链路 up也就是「这根线另一端有电信号」。它不回答三个问题这根线是不是我现在要测的那根另一端接的是 Windows 还是交换机这个物理口对应内核里的 eth0 还是 eth14 个口里有 3 个接了线任何一根都可以在 ethtool 里显示 yes。定位方法三条从快到准方法 1拔线测试最直接watch -n 1 ethtool eth0 | grep Link; ethtool eth1 | grep Link到机柜后面一根根拔。哪个口从 yes 变成 no映射就建立了。方法 2tcpdump 抓包Windows 持续ping -t -S 172.16.5.100 172.16.5.63服务器上分网卡抓# 终端 1 tcpdump -i eth0 -n icmp # 终端 2 tcpdump -i eth1 -n icmp哪个口能抓到源地址172.16.5.100的 ICMP哪个口才是「你以为的直连口」。方法 3LED 闪烁定位部分网卡支持ethtool -p eth1 10对应物理口的灯闪 10 秒人到机房看一眼即可。不支持会报Cannot identify NIC改用方法 1/2。教训Link up ≠ 你的线在这个口。物理口和网卡名的映射必须用拔线、抓包或 LED实测不要靠「我记得」。3.5 第四关交换机 VLAN 隔离——真正耗掉 2 小时的根因症状IP、掩码、端口映射全部确认正确Windows172.16.5.100/24服务器 eth1172.16.5.63/24蓝色网线确认在 eth1ping 的报错却变成了另一种C:\ ping -S 172.16.5.100 172.16.5.63 正在 Ping 172.16.5.63 从 172.16.5.100 具有 32 字节的数据: 来自 172.16.5.100 的回复: 无法访问目标主机。 来自 172.16.5.100 的回复: 无法访问目标主机。注意主语来自 172.16.5.100 的回复。这是 Windows 自己说「我发不出去」不是 Linux 拒绝你。这是整场排障最关键的判断点错误信息含义所在层请求超时ARP 多半已经解析ICMP 已发出对方没回L3 及以上无法访问目标主机ARP 广播没人应本机不知道对方 MACL2这时候再查防火墙、SSH、路由都是在上层空转。验证ARP 表为空C:\ arp -a 接口: 172.16.5.100 --- 0xc Internet 地址 物理地址 类型 172.16.5.255 ff-ff-ff-ff-ff-ff 静态 224.0.0.22 01-00-5e-00-00-16 静态 # 没有 172.16.5.63 的条目服务器同样失败[rootserver ~]# ip neigh show 172.16.5.100 dev eth1 FAILED双向 ARP 都 FAILED意味着二层广播域里根本没有对方。VLAN 的本质就是切开广播域ARP Request 是广播跨不过 802.1Q 边界。关键证据tcpdump[rootserver ~]# tcpdump -i eth1 -n -c 500抓到的内容让「直连」这个假设当场破产14:32:05.123456 ARP, Request who-has 172.16.8.233 tell 172.16.8.1 14:32:05.234567 ARP, Reply 172.16.8.233 is-at aa:bb:cc:dd:ee:ff 14:32:05.345678 STP 802.1s, Rapid STP, CIST Flags [Learn, Forward, Agreement] 14:32:05.456789 STP 802.1s, Rapid STP, CIST Flags [Learn, Forward] 14:32:06.567890 DHCP, Request from aa:bb:cc:dd:ee:ff 14:32:06.678901 mDNS from 172.16.5.1tcpdump 抓到 STP BPDU 且没有来自 Windows 的包三个发现每一个都在打脸STP802.1s Rapid STP只有管理型交换机才发 BPDU。普通跳线直连两台主机不可能出现 STP。出现172.16.8.233的 ARP跟我们的172.16.5.x不是同一网段说明线背后是一张有多个 VLAN 的交换网络。完全没有来自172.16.5.100的任何包Windows 发出的 ARP 广播根本没到 eth1。我以为的直连对比实际经过墙面板配线架和不同 VLAN 的路径顺着蓝色网线往机柜里捋真实路径是Windows 网口 ↓ 墙面 RJ45 面板 ↓ 弱电间配线架 ↓ 楼层管理型交换机某个 VLAN ↓ 另一根跳线 ↓ 服务器 Port-Deth1另一个 VLAN两端交换机端口划在不同 VLAN。物理链路是通的Link detected: yes数据链路层被逻辑切断。ARP 过不去ICMP 出不去SSH 更无从谈起。教训「插在同一台服务器上」不等于直连。中间只要经过交换机就要考虑 VLAN、端口隔离、STP。tcpdump是网络排障的终极武器抓不到对方的包问题一定在物理层或数据链路层。看到 Destination host unreachable 而不是 Request timed out优先查 ARP 和 VLAN而不是防火墙。3.6 最终解决物理上真·直连中间什么都不要拔掉 Port-D 上那根「以为直连」的蓝色网线找一根成品跳线一头直接插服务器 Port-D一头直接插 Windows 的 RJ45中间不经过墙面板、配线架、交换机再 pingC:\ ping 172.16.5.63 正在 Ping 172.16.5.63 具有 32 字节的数据: 来自 172.16.5.63 的回复: 字节32 时间1ms TTL64 来自 172.16.5.63 的回复: 字节32 时间1ms TTL64TTL64Linux 内核。这一次 ping 到的才是目标机器。[rootserver ~]# ip neigh show 172.16.5.100 dev eth1 lladdr AA:BB:CC:DD:EE:01 REACHABLESSH 一次登录成功login as: root root172.16.5.63s password: Last login: Tue Aug 11 13:45:22 2026 from 172.16.5.100TTL64、ARP REACHABLE、SSH 登录成功三条证据同时成立3.7 不能拔线时的替代方案机房现实不是每次都能拖一根新跳线穿过过道。不能物理直连时目标仍然是同一个二层广播域做法适用注意把两端交换机口划进同一 Access VLAN有交换机管理权限确认不是 PVLAN / 端口隔离中间加一台傻瓜交换机不划分 VLAN临时联调不要再接入楼层汇聚走已通的业务网 eth010.20.1.11做 SSH只想登录、不坚持直连网段确认防火墙与安全组放行 22带外Mgmt 口 / iLO / iDRAC / BMC生产机房标准姿势管理口通常在独立网段生产环境更推荐带外管理而不是靠一根「我记得是直连」的蓝色线。四、效果验证TTL、ARP、TCP 22 三条证据必须同时成立「看起来能 ping 了」不够。三条同时成立才允许宣布 SSH 链路正常检查项通过标准命令ICMP 身份TTL64Linux且拔线后立刻不通ping -S 172.16.5.100 172.16.5.63二层邻居双方 ARP 为动态可达Windowsarp -aLinuxip neigh show为REACHABLETCP/22端口通而不是 RST / 超时PowerShellTest-NetConnection 172.16.5.63 -Port 22Windows 端口验证示例C:\ Test-NetConnection 172.16.5.63 -Port 22 ComputerName : 172.16.5.63 RemoteAddress : 172.16.5.63 RemotePort : 22 TcpTestSucceeded : TrueLinux 侧再确认连接来源是有线网段而不是 Wi-Fi 或 VMnetss -tnp | grep :22 # 应看到 172.16.5.100:* ESTAB sshd四轮排障对照发文时建议做成表格图阅读完成率更高轮次表面症状实际根因耗时1ping 通但 SSH refused两台同 IPping 到自己TTL128SSH RST 来自 Windows约 30 分钟2ping 请求超时/24 与 /20 不一致被判跨网段约 20 分钟3链路 up 但不通信物理口与 eth 名映射不明约 15 分钟4ARP FAILED / 无法访问目标主机网线经交换机两端不同 VLAN约 2 小时四个最能误导人的假象建议直接做成文末金句「ping 能通」≠ 网络正常—— 可能是 ping 自己TTL 会出卖它。「Link detected: yes」≠ 网络通了—— 只代表 L1 upL2 可以被 VLAN 切断。「未识别的网络」≠ 网线没插好—— 这往往说明 link 已经 up只是没拿到 DHCP/网关。「无法访问目标主机」≠ 对方防火墙拦截—— 这是 ARP 失败比防火墙更底层。五、总结与延伸OSI 从下往上抓不到包就不要查 sshdOSI 从物理层到应用层自下而上排障抓不到包不要查 sshd为什么花了这么久我一开始盯着 SSH 配置和防火墙L4/L7问题其实在 L2。如果第一小时就抓 ARP至少能少走一小时冤枉路。另一条教训是不要相信「我记得」——我记得那根蓝色线是直连 Windows 的实际上它经过了墙面板、配线架和楼层交换机。机房里任何「以为」都要用工具验证。下次 5 分钟自查10 条两端 IP 是否冲突改一下本机 IP 再 ping看 TTL 是不是 64。两端子网掩码是否完全一致两端是否在同一网段广播地址对不对多网卡是否用了ping -S指定源地址arp -a/ip neigh show里有没有对端 MAC报错是「请求超时」还是「无法访问目标主机」后者查 L2。ethtool是否 yes网卡灯是否在闪这根「直连线」中间是否经过墙面板、配线架或交换机tcpdump能否抓到对端 ARP/ICMP抓不到就是 L1/L2。服务端是否监听0.0.0.0:22防火墙放行的是 ssh 服务而不是只放了 pingLinux 速查目的命令查看 IP/掩码/状态ip addr物理链路ethtool 网卡名网卡灯闪烁定位ethtool -p 网卡名 10抓全部tcpdump -i 网卡名 -nn只抓 ARPtcpdump -i 网卡名 arp -n只抓 ICMPtcpdump -i 网卡名 icmp -n -c 5抓包落盘tcpdump -i 网卡名 -w capture.pcapARP 表ip neigh show清空 ARPip neigh flush all路由ip route监听端口ss -tulnp | grep sshd防火墙服务firewall-cmd --list-servicesSSH 登录日志tail -f /var/log/securesshd 状态systemctl status sshdWindows 速查目的命令所有网卡ipconfig /all指定源 IP pingping -S 本机IP 目标IP持续 pingping -t 目标IPARP 表arp -a清空 ARPnetsh interface ip delete arpcache路由表route print路径tracert 目标IP测 TCP 22Test-NetConnection 目标IP -Port 22临时关防火墙仅定位netsh advfirewall set allprofiles state off立刻开回去netsh advfirewall set allprofiles state on临时关防火墙只用于对比「是不是本机策略在 DROP/REJECT」测完必须打开。生产环境不要用这个当常规手段。一句话物理链路通不等于网络层通。一根经过交换机的网线VLAN 可以在二层把通信切干净而所有物理层指示灯都告诉你「一切正常」。最可靠的直连就是一根线从 A 到 B中间什么都没有。抓不到对方的包就一定是底层问题——不要在防火墙和 SSH 配置上浪费下一个下午。权威参考tcpdump man pageethtool(8)ip-address(8) / ip-neighbour(8)sshd_config(5)firewalld 文档RFC 826 - An Ethernet Address Resolution ProtocolRFC 792 - Internet Control Message ProtocolIEEE 802.1Q VLANMicrosoft Docs: pingMicrosoft Docs: Test-NetConnection