Ping 通却 SSH Connection refused？Windows 连 Linux 连踩 4 坑：IP 冲突、掩码、双网口、VLAN 隔离

标签建议：#Linux #SSH #网络排查 #Connection refused #VLAN #ARP #运维

分类建议：运维 / Linux

配图已生成，无需实拍。 封面用 images/00-cover.png。发 CSDN 时把 images 目录下 10 张 PNG 逐张上传（编辑器里拖进去即可），不要用本地相对路径。

目录（建议直接用 CSDN 目录功能生成）

一、引言：ping 通了，SSH 凭什么还 Connection refused

服务器和电脑都配好了 IP，ping 也“通”了，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

黑色网线（通往交换机）

eth0

Port-C

物理网口 2

空着

-

Port-D

物理网口 3

蓝色网线（我以为直连）

eth1

服务器背面物理口丝印不等于内核网卡名 eth0/eth1

最终正确的地址规划如下（排障过程中两端都曾经配错过）：

[root@server ~]# 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，蓝色线，本意是直连 Windows

virbr0（libvirt）和 docker0（Docker）与本次无关，排障时先忽略，避免被虚拟网桥的 192.168.x 带偏。

SSH 服务本身当时是正常的——这也是最容易让人放松警惕的地方：

[root@server ~]# ss -tulnp | grep sshd
tcp   LISTEN  0  128  0.0.0.0:22  0.0.0.0:*  users:(("sshd",pid=1234,fd=3))
tcp   LISTEN  0  128  [::]:22     [::]:*     users:(("sshd",pid=1234,fd=4))

[root@server ~]# firewall-cmd --list-services
dhcpv6-client mdns ssh

[root@server ~]# 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.1

Windows 多网卡时会按路由度量选源 IP。你以为 ping 从有线出去，实际可能从 Wi-Fi 或 VMnet 出去。多网卡场景必须用 ping -S 源IP 锁死出口，否则证据链从第一步就脏了。

2.2 Connection refused / 超时 / 无法访问，分别卡在哪一层

把三种报错钉死，后面四关才不会查错层：

客户端报错

协议语义

卡在哪一层

典型根因

Connection refused

收到 TCP RST：对端明确拒绝 22 端口

L4

连到了一台没开 sshd 的机器（包括你自己）；或防火墙是 REJECT 而不是 DROP

请求超时 / Request timed out

ICMP/TCP 已经发出去，对端没回

L3 及以上

掩码把对端判成跨网段；防火墙 DROP；对端宕机；路由黑洞

无法访问目标主机 / Destination host unreachable

ARP 没人应，本机连对方 MAC 都不知道，包根本发不出去

L2

VLAN 隔离、网线没到同一广播域、对端网卡 down

三种连不上分别卡在 L4 RST、L3 超时、L2 ARP 失败

补充三个容易混的点：

  1. firewalld/iptables REJECT → Connection refused；DROP → 超时。 所以“SSH refused 一定是防火墙”这句本身就不严谨，更何况你可能连的根本不是那台 Linux。

  2. Windows 的「无法访问目标主机」很多时候是本机回的 ICMP，不是服务器回的。看到它，优先查 ARP 表，不要去翻 /etc/ssh/sshd_config。

  3. 第一关里我看到的 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：

操作系统 / 设备

默认 TTL

Linux / Android

64

Windows

128

部分网络设备

255

每过一跳减 1。直连场景下你看到 TTL=128，回包来自 Windows；TTL=64，才像 Linux 内核。时延 <1ms 再叠 TTL=128，要高度怀疑 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 || true

Windows 一键取证（管理员 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" }

定层口诀：

  1. 拔掉网线还能 ping 通 → 100% 在 ping 自己。

  2. arp -a 里没有对端 MAC → 先查 L2，不要查防火墙。

  3. tcpdump 抓不到对端任何帧 → 问题在 L1/L2，sshd 日志不用看。

3.2 第一关：IP 冲突——ping 通的其实是自己（TTL=128）

症状

最初服务器配的是 10.20.1.11，Windows 有线网卡也配了 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 TTL=128
来自 10.20.1.11 的回复: 字节=32 时间<1ms TTL=128

ping TTL=128 且时延小于 1ms，说明回包来自 Windows 自己

根因

关键线索是 TTL。Linux 默认 64，Windows 默认 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 解析可能随机指向其中一台，现象会在「通 / 不通 / 通的是另一台」之间跳，这类问题最隐蔽。

解决

把两端地址错开，不要再共用业务网段的同一个主机号：

  • 服务器 eth1：172.16.5.63/24

  • Windows 以太网：172.16.5.100/24

验证

改完再 ping：TTL 若还是 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 改过来的，掩码一度残留 /20：

C:\> ping 172.16.5.63
请求超时。
请求超时。

根因

掩码决定主机对「本地子网」的判断范围：

主机

IP/掩码

本机认为的本地子网

Windows

172.16.5.100/24

172.16.5.0 ～ 172.16.5.255

服务器（错误状态）

172.16.5.63/20

172.16.0.0 ～ 172.16.15.255

两端对「是否同一子网」判断不一致时，主机会把对端 IP 当成跨网段地址，包交给默认网关而不是直接 ARP。直连场景通常没有可用网关，包被丢掉，表现为「请求超时」。

直连必须：同网段、同掩码。只差一位掩码都可能失败。改 IP 时要同时核对三项：地址、掩码、广播地址。

解决

统一 172.16.5.0/24：

nmcli connection modify eth1 ipv4.addresses 172.16.5.63/24
nmcli connection modify eth1 ipv4.method manual
nmcli connection up eth1
ip addr show eth1

Windows 在「以太网属性 → IPv4」里填：

  • IP：172.16.5.100

  • 掩码：255.255.255.0

  • 网关：直连可留空（不要填一个不存在的网关把包拐走）

验证

两边 ip addr / ipconfig 对一下，IP、掩码、广播必须落在同一网段。然后用指定源地址 ping：

C:\> ping -S 172.16.5.100 172.16.5.63

教训

改 IP 不要只改主机号。掩码是子网的边界合同，两端必须签同一份。

3.4 第三关：双网口混淆——Link detected 不代表线在这个口

症状

掩码和 IP 都对了，还是 ping 不通。服务器上两个口都是链路 up：

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

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

背面 Port-B、Port-D 都插着线。蓝色线到底对应 eth0 还是 eth1？它是不是「直连」线？全不确定。

ethtool 两个网口都是 Link detected yes，L1 up 无法区分是哪根线

根因

Link detected: yes 只代表物理层（L1）链路 up，也就是「这根线另一端有电信号」。它不回答三个问题：

  • 这根线是不是我现在要测的那根？

  • 另一端接的是 Windows 还是交换机？

  • 这个物理口对应内核里的 eth0 还是 eth1？

4 个口里有 3 个接了线，任何一根都可以在 ethtool 里显示 yes。

定位方法（三条，从快到准）

方法 1：拔线测试（最直接）

watch -n 1 'ethtool eth0 | grep Link; ethtool eth1 | grep Link'

到机柜后面一根根拔。哪个口从 yes 变成 no，映射就建立了。

方法 2：tcpdump 抓包

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，哪个口才是「你以为的直连口」。

方法 3：LED 闪烁定位（部分网卡支持）

ethtool -p eth1 10

对应物理口的灯闪 10 秒，人到机房看一眼即可。不支持会报 Cannot identify NIC，改用方法 1/2。

教训

Link up ≠ 你的线在这个口。物理口和网卡名的映射必须用拔线、抓包或 LED 实测，不要靠「我记得」。

3.5 第四关：交换机 VLAN 隔离——真正耗掉 2 小时的根因

症状

IP、掩码、端口映射全部确认正确：

  • Windows：172.16.5.100/24

  • 服务器 eth1：172.16.5.63/24

  • 蓝色网线确认在 eth1

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

注意主语：来自 172.16.5.100 的回复。这是 Windows 自己说「我发不出去」，不是 Linux 拒绝你。

这是整场排障最关键的判断点：

错误信息

含义

所在层

请求超时

ARP 多半已经解析，ICMP 已发出，对方没回

L3 及以上

无法访问目标主机

ARP 广播没人应，本机不知道对方 MAC

L2

这时候再查防火墙、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 的条目

服务器同样失败：

[root@server ~]# ip neigh show
172.16.5.100 dev eth1 FAILED

双向 ARP 都 FAILED，意味着二层广播域里根本没有对方。VLAN 的本质就是切开广播域：ARP Request 是广播，跨不过 802.1Q 边界。

关键证据：tcpdump

[root@server ~]# 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.1

tcpdump 抓到 STP BPDU 且没有来自 Windows 的包

三个发现，每一个都在打脸：

  1. STP（802.1s Rapid STP）：只有管理型交换机才发 BPDU。普通跳线直连两台主机，不可能出现 STP。

  2. 出现 172.16.8.233 的 ARP：跟我们的 172.16.5.x 不是同一网段，说明线背后是一张有多个 VLAN 的交换网络。

  3. 完全没有来自 172.16.5.100 的任何包：Windows 发出的 ARP 广播根本没到 eth1。

我以为的直连对比实际经过墙面板配线架和不同 VLAN 的路径

顺着蓝色网线往机柜里捋，真实路径是：

Windows 网口
   ↓
墙面 RJ45 面板
   ↓
弱电间配线架
   ↓
楼层管理型交换机（某个 VLAN）
   ↓
另一根跳线
   ↓
服务器 Port-D（eth1，另一个 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

  • 中间不经过墙面板、配线架、交换机

再 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 show
172.16.5.100 dev eth1 lladdr AA:BB:CC:DD:EE:01 REACHABLE

SSH 一次登录成功：

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

TTL=64、ARP REACHABLE、SSH 登录成功三条证据同时成立

3.7 不能拔线时的替代方案（机房现实）

不是每次都能拖一根新跳线穿过过道。不能物理直连时，目标仍然是同一个二层广播域：

做法

适用

注意

把两端交换机口划进同一 Access VLAN

有交换机管理权限

确认不是 PVLAN / 端口隔离

中间加一台傻瓜交换机（不划分 VLAN）

临时联调

不要再接入楼层汇聚

走已通的业务网 eth0（10.20.1.11）做 SSH

只想登录、不坚持直连网段

确认防火墙与安全组放行 22

带外：Mgmt 口 / iLO / iDRAC / BMC

生产机房标准姿势

管理口通常在独立网段

生产环境更推荐带外管理，而不是靠一根「我记得是直连」的蓝色线。

四、效果验证：TTL、ARP、TCP 22 三条证据必须同时成立

「看起来能 ping 了」不够。三条同时成立，才允许宣布 SSH 链路正常：

检查项

通过标准

命令

ICMP 身份

TTL=64（Linux），且拔线后立刻不通

ping -S 172.16.5.100 172.16.5.63

二层邻居

双方 ARP 为动态可达

Windows arp -a；Linux ip neigh show 为 REACHABLE

TCP/22

端口通，而不是 RST / 超时

PowerShell：Test-NetConnection 172.16.5.63 -Port 22

Windows 端口验证示例：

C:\> Test-NetConnection 172.16.5.63 -Port 22

ComputerName     : 172.16.5.63
RemoteAddress    : 172.16.5.63
RemotePort       : 22
TcpTestSucceeded : True

Linux 侧再确认连接来源是有线网段，而不是 Wi-Fi 或 VMnet：

ss -tnp | grep ':22'
# 应看到 172.16.5.100:*  ESTAB  sshd

四轮排障对照（发文时建议做成表格图，阅读完成率更高）：

轮次

表面症状

实际根因

耗时

1

ping 通但 SSH refused

两台同 IP，ping 到自己（TTL=128），SSH RST 来自 Windows

约 30 分钟

2

ping 请求超时

/24 与 /20 不一致，被判跨网段

约 20 分钟

3

链路 up 但不通信

物理口与 eth 名映射不明

约 15 分钟

4

ARP FAILED / 无法访问目标主机

网线经交换机，两端不同 VLAN

约 2 小时

四个最能误导人的假象，建议直接做成文末金句：

  1. 「ping 能通」≠ 网络正常 —— 可能是 ping 自己，TTL 会出卖它。

  2. 「Link detected: yes」≠ 网络通了 —— 只代表 L1 up，L2 可以被 VLAN 切断。

  3. 「未识别的网络」≠ 网线没插好 —— 这往往说明 link 已经 up，只是没拿到 DHCP/网关。

  4. 「无法访问目标主机」≠ 对方防火墙拦截 —— 这是 ARP 失败，比防火墙更底层。

五、总结与延伸：OSI 从下往上，抓不到包就不要查 sshd

OSI 从物理层到应用层自下而上排障，抓不到包不要查 sshd

为什么花了这么久： 我一开始盯着 SSH 配置和防火墙（L4/L7），问题其实在 L2。如果第一小时就抓 ARP，至少能少走一小时冤枉路。另一条教训是不要相信「我记得」——我记得那根蓝色线是直连 Windows 的，实际上它经过了墙面板、配线架和楼层交换机。机房里任何「以为」，都要用工具验证。

下次 5 分钟自查（10 条）：

  1. 两端 IP 是否冲突？改一下本机 IP 再 ping，看 TTL 是不是 64。

  2. 两端子网掩码是否完全一致？

  3. 两端是否在同一网段？广播地址对不对？

  4. 多网卡是否用了 ping -S 指定源地址？

  5. arp -a / ip neigh show 里有没有对端 MAC？

  6. 报错是「请求超时」还是「无法访问目标主机」？后者查 L2。

  7. ethtool 是否 yes？网卡灯是否在闪？

  8. 这根「直连线」中间是否经过墙面板、配线架或交换机？

  9. tcpdump 能否抓到对端 ARP/ICMP？抓不到就是 L1/L2。

  10. 服务端是否监听 0.0.0.0:22？防火墙放行的是 ssh 服务而不是只放了 ping？

Linux 速查

目的

命令

查看 IP/掩码/状态

ip addr

物理链路

ethtool 网卡名

网卡灯闪烁定位

ethtool -p 网卡名 10

抓全部

tcpdump -i 网卡名 -nn

只抓 ARP

tcpdump -i 网卡名 arp -n

只抓 ICMP

tcpdump -i 网卡名 icmp -n -c 5

抓包落盘

tcpdump -i 网卡名 -w capture.pcap

ARP 表

ip neigh show

清空 ARP

ip neigh flush all

路由

ip route

监听端口

ss -tulnp | grep sshd

防火墙服务

firewall-cmd --list-services

SSH 登录日志

tail -f /var/log/secure

sshd 状态

systemctl status sshd

Windows 速查

目的

命令

所有网卡

ipconfig /all

指定源 IP ping

ping -S 本机IP 目标IP

持续 ping

ping -t 目标IP

ARP 表

arp -a

清空 ARP

netsh interface ip delete arpcache

路由表

route print

路径

tracert 目标IP

测 TCP 22

Test-NetConnection 目标IP -Port 22

临时关防火墙（仅定位）

netsh advfirewall set allprofiles state off

立刻开回去

netsh advfirewall set allprofiles state on

临时关防火墙只用于对比「是不是本机策略在 DROP/REJECT」，测完必须打开。生产环境不要用这个当常规手段。

一句话： 物理链路通不等于网络层通。一根经过交换机的网线，VLAN 可以在二层把通信切干净，而所有物理层指示灯都告诉你「一切正常」。最可靠的直连，就是一根线从 A 到 B，中间什么都没有。抓不到对方的包，就一定是底层问题——不要在防火墙和 SSH 配置上浪费下一个下午。

权威参考

  1. tcpdump man page

  2. ethtool(8)

  3. ip-address(8) / ip-neighbour(8)

  4. sshd_config(5)

  5. firewalld 文档

  6. RFC 826 - An Ethernet Address Resolution Protocol

  7. RFC 792 - Internet Control Message Protocol

  8. IEEE 802.1Q VLAN

  9. Microsoft Docs: ping

  10. Microsoft Docs: Test-NetConnection

# java
Logo
DAMO开发者矩阵

DAMO开发者矩阵，由阿里巴巴达摩院和中国互联网协会联合发起，致力于探讨最前沿的技术趋势与应用成果，搭建高质量的交流与分享平台，推动技术创新与产业应用链接，围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐

cover

AI边缘计算技术路线总结：从芯片选型到AI终端落地的完整指南

avatar DAMO开发者矩阵
cover

极客互动｜企业微信聚合聊天，一站式私域运营解决方案

avatar DAMO开发者矩阵
cover

高精度行星减速机国产品牌怎么选？钧晟动力科技（嘉兴）有限公司行业分析与合作参考

avatar DAMO开发者矩阵