一次 SSH 连接排障全记录：为什么一根网线能折腾一下午-尧图网络科技

AIGC: Label:"1"ContentProducer: 001191110102MACQD9K64018705 ProduceID: 687608750681449_0/project_7672303624038433033-files/SSH连接排障记录-网线直连踩坑全记录.md ReservedCode1:""ContentPropagator: 001191110102MACQD9K64028705 PropagateID:687608750681449#1786428820538ReservedCode2:""

一次 SSH 连接排障全记录：为什么一根网线能折腾一下午

摘要：服务器和电脑明明都配了 IP，ping 也"通"了，但 SSH 就是连不上。本文记录了一次从 IP 冲突、子网掩码不匹配、双网口混淆到最终发现交换机 VLAN 隔离的完整排障过程。每一关看似都解决了，但下一关才真正暴露出来。

一、问题描述

我有一台 Linux 服务器，通过网线直连 Windows 电脑，想用 SSH 客户端连上去。

配置完之后，ping 能通，但 SSH 报Connection refused：

Network error: Connection refused Session stopped

看起来是个简单问题，结果从下午三点折腾到天黑。

二、服务器环境

服务器是 Linux 系统，背面有 4 个物理网口：

端口标识	说明
Mgmt	管理口（未使用）
Port-A	共享网口（未使用）
Port-B	物理网口 1，插了黑色网线
Port-C	空着
Port-D	物理网口 2，插了蓝色网线（我用的这个）

系统中有两个物理网卡接口（通过ip addr查看）：

[root@server ~]# ip addr2: eth0:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1500inet10.20.1.11/20 brd10.20.15.255 scope global eth0# 对应 Port-B（黑色线）3: eth1:<BROADCAST,MULTICAST,UP,LOWER_UP>mtu1500inet172.16.5.63/24 brd172.16.5.255 scope global eth1# 对应 Port-D（蓝色线）

另外还有一个virbr0（虚拟网桥）和docker0（Docker 虚拟网桥），跟本次问题无关。

SSH 服务确认正常运行：

[root@server ~]# ss -tulnp | grep sshdtcp LISTEN01280.0.0.0:220.0.0.0:* users:(("sshd",pid=1234,fd=3))tcp LISTEN0128[::]:22[::]:* users:(("sshd",pid=1234,fd=4))[root@server ~]# firewall-cmd --list-servicesdhcpv6-client mdnsssh# SSH 已放行[root@server ~]# grep PermitRootLogin /etc/ssh/sshd_configPermitRootLoginyes

防火墙没有拒绝规则，SSH 监听在 0.0.0.0:22，PermitRootLogin 也开了。服务端一切正常。

三、Windows 环境

以太网适配器 以太网: 描述: 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 子网掩码: 255.255.255.0 以太网适配器 VMware Network Adapter VMnet1: IPv4 地址: 192.168.202.1 以太网适配器 VMware Network Adapter VMnet8: IPv4 地址: 192.168.40.1

注意：电脑同时有 4 个活跃网卡（以太网 + WiFi + VMnet1 + VMnet8），这在后续排障中制造了不少麻烦。

四、排障过程

第一关：IP 冲突 — ping 通的可能是自己

症状

服务器配了10.20.1.11，Windows 也配了10.20.1.11。ping 能通，但 SSH 连不上。

C:\> ping 10.20.1.11 正在 Ping 10.20.1.11 具有 32 字节的数据: 来自 10.20.1.11 的回复: 字节=32 时间<1ms TTL=128 来自 10.20.1.11 的回复: 字节=32 时间<1ms TTL=128

分析

ping 能通，说明网络层是通的。但 SSH 报Connection refused，说明目标机器上没有 SSH 服务在监听。

关键线索是TTL=128。Linux 系统默认的 TTL 通常是 64，而Windows 默认的 TTL 是 128。这意味着 ping 回来的包不是从 Linux 服务器回来的，而是从 Windows 自己回来的。

两台机器配了同一个 IP，ARP 解析会同时收到两个 MAC 地址的回应，谁先响应就连谁。这里 Windows 自己响应了自己的 ARP 请求，所以 ping 通的是自己。

解决

把 Windows 的 IP 改成不同的地址：172.16.5.100。

教训

ping 通不代表连的是目标机器。看 TTL 值（Linux 通常 64，Windows 通常 128）可以判断 ping 到的是谁。两台机器同 IP 时，ARP 解析会随机指向其中一个。

第二关：子网掩码不匹配

症状

Windows 改成172.16.5.100，但子网掩码一开始设的是255.255.255.0（/24）。服务器的eth1配置的是/20（255.255.240.0）。

[root@server ~]# ip addr show eth1inet10.20.1.11/20 brd10.20.15.255 scope global eth1

分析

掩码不一致会导致两端对"同一个子网"的判断不同：

Windows（/24）：认为172.16.5.0/24是本地子网，只会给这个范围内的 IP 发 ARP
服务器（/20）：认为10.20.0.0/20是本地子网

两边根本不在同一个网段，自然不会互相通信。

解决

把 Windows 的掩码改成255.255.240.0（/20），让两端在同一子网。后来发现掩码虽然对了，但 IP 段仍然不对——因为服务器的eth1实际配的是172.16.5.63/24，不是10.20.1.11/20。最终决定用172.16.5.x网段：

服务器：172.16.5.63/24（eth1）
Windows：172.16.5.100/24

教训

子网掩码必须一致。改 IP 之前先确认两端的网段和掩码完全匹配。用ip addr（Linux）和ipconfig（Windows）仔细核对。

第三关：双网口，分不清线插在哪

症状

服务器背面 Port-B 和 Port-D 都插了线，ethtool显示两个口都Link detected: yes：

[root@server ~]# ethtool eth0 | grep LinkLink detected:yes[root@server ~]# ethtool eth1 | grep LinkLink detected:yes

根本分不清我的线在 Port-B 还是 Port-D，也不确定eth1对应哪个物理口。

分析

Link detected: yes只表示网口检测到了物理链路（link up），不代表你的线就插在这个口上。服务器有 4 个口，其中 Port-A、Port-B、Port-D 都有线，任何一根线都可能对应任何一个 Linux 网卡接口。

尝试的排查方法

看端口标注：服务器背面 Mgmt、Port-A、Port-B、Port-C、Port-D 有标注，但 Linux 内核命名（eth0、eth1）和物理标注的对应关系需要实际验证。
拔线测试：拔掉某根线，看哪个网卡Link detected变成no。
tcpdump 抓包：在 Windows 上持续 ping，在服务器上对两个网卡分别抓包，看哪个口能收到 ICMP 包。

教训

Link detected: yes≠ 你的线在这个口。要确认端口映射，必须用拔线测试或 tcpdump 抓包来验证。服务器背面的物理端口标注和 Linux 内核的网卡命名不是一一对应的，需要实测。

第四关：交换机 VLAN 隔离（真正的坑）

症状

IP 配置确认正确（Windows:172.16.5.100/24，服务器 eth1:172.16.5.63/24），但 ping 报的不再是"请求超时"，而是：

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 的回复: 无法访问目标主机。

注意：不是"请求超时"（Request timed out），而是"无法访问目标主机"（Destination host unreachable）。这两个错误含义完全不同。

深入分析

“无法访问目标主机”是 Windows 本地返回的错误，含义是：ARP 广播发出去了，但没有收到任何 ARP 回复，MAC 地址解析失败。Windows 连包都发不出去，更别提 ICMP 了。

“请求超时”则是：ARP 成功了（知道对方 MAC），ICMP 包也发出去了，但对方没有回复。

用arp -a验证：

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 的条目！

ARP 完全失败。在服务器端也验证：

[root@server ~]# ip neigh show172.16.5.100 dev eth1 FAILED# 服务器也解析不到 Windows 的 MAC172.16.5.63 dev eth1 lladdr... REACHABLE# 自己（本地接口）

双向 ARP 都失败。说明数据包在二层（数据链路层）根本没到对方。

关键证据：tcpdump 抓包

在服务器上对eth1抓包：

[root@server ~]# sudo tcpdump -i eth1 -n -c 500

抓到的不是来自172.16.5.100的包，而是：

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.1 ...

三个关键发现：

STP（802.1s Rapid STP）包：这是管理型交换机才会发的协议。说明eth1连到的不是一个直接的设备，而是一个交换机网络。
172.16.8.233 的 ARP：这个 IP 和我们的 172.16.5.x 不在同一网段，说明交换机上还有其他 VLAN 的设备。
完全没有 172.16.5.100 的任何包：Windows 发出的 ARP 广播根本没有到达服务器的eth1口。

根因定位

服务器的 Port-A、Port-B 连着的线通向楼层的管理型交换机，交换机之间运行着 STP 协议。Port-D 虽然插着我的线，但这根线并不是真正直连到 Port-D 的物理端口——它经过了墙上面板 → 配线架 → 楼层交换机 → 再回到服务器的 Port-D 口。

交换机的端口划分了不同的VLAN：

服务器 Port-A/Port-B 对应的端口在 VLAN X
我的 Windows 对应的端口在 VLAN Y
两个 VLAN 在二层完全隔离，ARP 广播无法跨 VLAN 传播

所以：物理链路是通的（Link detected: yes），Windows 也显示"未识别的网络"（link up），但二层数据包被 VLAN 隔断了，ARP 请求永远到不了对方。

教训

"直连"和"插在同一台服务器上"是两回事。如果网线经过了交换机，VLAN 隔离会让两台机器在二层完全不通信。Link detected: yes只说明物理层链路通，不代表数据链路层（L2）能通信。tcpdump 是排障的终极武器— 抓不到对方的包，就一定是物理层或二层的问题。

五、最终解决

在服务器上拔掉 Port-D 的蓝色网线，拿一根新网线，一头直接插服务器的 Port-D 口，另一头直接插 Windows 的 RJ45 网口。中间不经过任何交换机、墙上面板或配线架。

重新 ping：

C:\> ping 172.16.5.63 正在 Ping 172.16.5.63 具有 32 字节的数据: 来自 172.16.5.63 的回复: 字节=32 时间<1ms TTL=64 来自 172.16.5.63 的回复: 字节=32 时间<1ms TTL=64

TTL=64，Linux 服务器！这次 ping 到的是真正的目标机器。

[root@server ~]# ip neigh show172.16.5.100 dev eth1 lladdr AA-BB-CC-DD-EE-01 REACHABLE# Windows MAC 已解析

打开 SSH 客户端，连接172.16.5.63：

login as: root root@172.16.5.63's password: Last login: Tue Aug 11 13:45:22 2026 from 172.16.5.100

成功了。

六、复盘总结

为什么花了这么久

整个过程经历了四轮排障，每一轮解决后才暴露下一轮的问题：

轮次	问题	表面症状	实际根因	耗时
1	IP 冲突	ping 通但 SSH refused	两台机器同 IP，ping 到自己	~30min
2	掩码/网段不匹配	ping 超时	跨网段切换时配置反复出错	~20min
3	双网口混淆	链路通但不通信	不确定线插在哪个物理口	~15min
4	交换机 VLAN 隔离	ARP 完全失败	网线经过交换机，VLAN 隔离	~2h

最容易误导人的现象

"ping 能通"≠ 网络正常— IP 冲突时 ping 的是自己（TTL=128）
"Link detected: yes"≠ 网络通了— 物理层通不代表二层通
"未识别的网络"≠ 网线没插好— 这其实说明 link up 了，只是没有 DHCP/网关
"无法访问目标主机"≠ 对方防火墙拦截— 这是 ARP 失败，比防火墙更底层

排障思路总结

遇到网络不通时，按 OSI 七层模型从底向上排查：

第1层 物理层 → 网线插对了吗？灯亮了吗？ethtool Link detected？ 第2层 数据链路层 → MAC 能解析吗？arp -a / ip neigh show 有对端条目吗？ 第3层 网络层 → IP 在同一子网吗？掩码一致吗？路由对吗？ 第4层 传输层 → 端口在监听吗？ss -tulnp / netstat -tlnp 第7层 应用层 → SSH 服务跑了吗？配置对吗？日志有报错吗？

每一层不通，上面所有的检查都没有意义。必须先确保底层通了，再查上层。

七、关键排障命令备忘

服务器端（Linux）

# 查看网卡 IP、掩码、状态ipaddr# 查看物理链路状态ethtool<网卡名># 抓包 — 排障终极武器sudotcpdump-i<网卡名>-n# 抓所有包sudotcpdump-i<网卡名>arp-n# 只抓 ARPsudotcpdump-i<网卡名>icmp-c5# 只抓 ICMP，抓5个就停# 查看 ARP 表（二层是否通）ipneigh show# 防火墙 SSH 是否放行firewall-cmd --list-services# SSH 服务日志（是否有过成功/失败连接）grepsshd /var/log/secure|tail-20# SSH 服务是否运行ss-tulnp|grepsshd systemctl status sshd

Windows 端

:: 查看所有网卡状态和 IP ipconfig /all :: 指定源 IP ping（排除多网卡路由干扰） ping -S <本机IP> <目标IP> :: 查看 ARP 表 arp -a :: 持续 ping ping -t <目标IP> :: 查看路由表 route print :: 临时关闭 Windows 防火墙（测试完记得开回来） netsh advfirewall set allprofiles state off netsh advfirewall set allprofiles state on

八、一句话总结

“物理链路通"不等于"网络层通”。网线经过交换机时，VLAN 隔离可以在二层完全切断通信，而所有物理层的指示灯都告诉你"一切正常"。最可靠的直连，就是一根线从 A 到 B，中间什么都没有。遇到问题时，tcpdump 抓包是排障的终极武器— 抓不到对方的包，就一定是底层的问题，不要在上层浪费时间。

链接

Linux 侧工具文档

https://www.tcpdump.org/manpages/tcpdump.1.html （tcpdump 手册）
https://man7.org/linux/man-pages/man8/ethtool.8.html （ethtool 手册）
https://man7.org/linux/man-pages/man8/ip-address.8.html （ip addr 手册）
https://man7.org/linux/man-pages/man8/ip-neighbour.8.html （ip neigh / ARP 表手册）
https://man.openbsd.org/sshd_config （sshd_config 配置手册）
https://firewalld.org/documentation/ （firewalld 官方文档）
Windows 侧命令文档 7. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ping （ping） 8. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/arp （arp） 9. https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig （ipconfig） 10. https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/netsh-advfirewall-firewall-control-firewall-behavior （netsh advfirewall 防火墙开关）

协议标准 11. https://www.rfc-editor.org/rfc/rfc826 （RFC 826 · ARP 协议） 12. https://www.rfc-editor.org/rfc/rfc792 （RFC 792 · ICMP 协议） 13. https://1.ieee802.org/tsn/802-1q/ （IEEE 802.1Q · VLAN / 生成树标准）