AIGC: Label:1ContentProducer: 001191110102MACQD9K64018705 ProduceID: 687608750681449_0/project_7672303624038433033-files/SSH连接排障记录-网线直连踩坑全记录.md ReservedCode1:ContentPropagator: 001191110102MACQD9K64028705 PropagateID:687608750681449#1786428820538ReservedCode2:一次 SSH 连接排障全记录为什么一根网线能折腾一下午摘要服务器和电脑明明都配了 IPping 也通了但 SSH 就是连不上。本文记录了一次从 IP 冲突、子网掩码不匹配、双网口混淆到最终发现交换机 VLAN 隔离的完整排障过程。每一关看似都解决了但下一关才真正暴露出来。一、问题描述我有一台 Linux 服务器通过网线直连 Windows 电脑想用 SSH 客户端连上去。配置完之后ping 能通但 SSH 报Connection refusedNetwork error: Connection refused Session stopped看起来是个简单问题结果从下午三点折腾到天黑。二、服务器环境服务器是 Linux 系统背面有 4 个物理网口端口标识说明Mgmt管理口未使用Port-A共享网口未使用Port-B物理网口 1插了黑色网线Port-C空着Port-D物理网口 2插了蓝色网线我用的这个系统中有两个物理网卡接口通过ip addr查看[rootserver ~]# ip addr2: eth0:BROADCAST,MULTICAST,UP,LOWER_UPmtu1500inet10.20.1.11/20 brd10.20.15.255 scope global eth0# 对应 Port-B黑色线3: eth1:BROADCAST,MULTICAST,UP,LOWER_UPmtu1500inet172.16.5.63/24 brd172.16.5.255 scope global eth1# 对应 Port-D蓝色线另外还有一个virbr0虚拟网桥和docker0Docker 虚拟网桥跟本次问题无关。SSH 服务确认正常运行[rootserver ~]# ss -tulnp | grep sshdtcp LISTEN01280.0.0.0:220.0.0.0:* users:((sshd,pid1234,fd3))tcp LISTEN0128[::]:22[::]:* users:((sshd,pid1234,fd4))[rootserver ~]# firewall-cmd --list-servicesdhcpv6-client mdnsssh# SSH 已放行[rootserver ~]# grep PermitRootLogin /etc/ssh/sshd_configPermitRootLoginyes防火墙没有拒绝规则SSH 监听在 0.0.0.0:22PermitRootLogin 也开了。服务端一切正常。三、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.11Windows 也配了10.20.1.11。ping 能通但 SSH 连不上。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 TTL128分析ping 能通说明网络层是通的。但 SSH 报Connection refused说明目标机器上没有 SSH 服务在监听。关键线索是TTL128。Linux 系统默认的 TTL 通常是 64而Windows 默认的 TTL 是 128。这意味着 ping 回来的包不是从 Linux 服务器回来的而是从 Windows 自己回来的。两台机器配了同一个 IPARP 解析会同时收到两个 MAC 地址的回应谁先响应就连谁。这里 Windows 自己响应了自己的 ARP 请求所以 ping 通的是自己。解决把 Windows 的 IP 改成不同的地址172.16.5.100。教训ping 通不代表连的是目标机器。看 TTL 值Linux 通常 64Windows 通常 128可以判断 ping 到的是谁。两台机器同 IP 时ARP 解析会随机指向其中一个。第二关子网掩码不匹配症状Windows 改成172.16.5.100但子网掩码一开始设的是255.255.255.0/24。服务器的eth1配置的是/20255.255.240.0。[rootserver ~]# 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/24eth1Windows172.16.5.100/24教训子网掩码必须一致。改 IP 之前先确认两端的网段和掩码完全匹配。用ip addrLinux和ipconfigWindows仔细核对。第三关双网口分不清线插在哪症状服务器背面 Port-B 和 Port-D 都插了线ethtool显示两个口都Link detected: yes[rootserver ~]# ethtool eth0 | grep LinkLink detected:yes[rootserver ~]# 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 成功了知道对方 MACICMP 包也发出去了但对方没有回复。用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 完全失败。在服务器端也验证[rootserver ~]# ip neigh show172.16.5.100 dev eth1 FAILED# 服务器也解析不到 Windows 的 MAC172.16.5.63 dev eth1 lladdr... REACHABLE# 自己本地接口双向 ARP 都失败。说明数据包在二层数据链路层根本没到对方。关键证据tcpdump 抓包在服务器上对eth1抓包[rootserver ~]# 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 ...三个关键发现STP802.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: yesWindows 也显示未识别的网络link up但二层数据包被 VLAN 隔断了ARP 请求永远到不了对方。教训直连和插在同一台服务器上是两回事。如果网线经过了交换机VLAN 隔离会让两台机器在二层完全不通信。Link detected: yes只说明物理层链路通不代表数据链路层L2能通信。tcpdump 是排障的终极武器— 抓不到对方的包就一定是物理层或二层的问题。五、最终解决在服务器上拔掉 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 show172.16.5.100 dev eth1 lladdr AA-BB-CC-DD-EE-01 REACHABLE# Windows MAC 已解析打开 SSH 客户端连接172.16.5.63login as: root root172.16.5.63s password: Last login: Tue Aug 11 13:45:22 2026 from 172.16.5.100成功了。六、复盘总结为什么花了这么久整个过程经历了四轮排障每一轮解决后才暴露下一轮的问题轮次问题表面症状实际根因耗时1IP 冲突ping 通但 SSH refused两台机器同 IPping 到自己~30min2掩码/网段不匹配ping 超时跨网段切换时配置反复出错~20min3双网口混淆链路通但不通信不确定线插在哪个物理口~15min4交换机 VLAN 隔离ARP 完全失败网线经过交换机VLAN 隔离~2h最容易误导人的现象ping 能通≠ 网络正常— IP 冲突时 ping 的是自己TTL128Link 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 sshdWindows 端:: 查看所有网卡状态和 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 / 生成树标准
