局域网唯独当前电脑连不上群晖 NAS？Ping 报“一般故障 (General failure)”的深度排查实录

在日常折腾家庭实验室（HomeLab）与局域网服务时，经常会遇到各种奇奇怪怪的网络连通性问题。今天遇到了一个非常典型且极具迷惑性的“灵异现象”：局域网内所有设备都能正常访问群晖 NAS，唯独当前使用的这台主力 Windows 电脑死活连不上；但这台电脑访问局域网内的主路由、旁路由、PVE 宿主机却又全部正常。

经过层层剖析，最终从 Windows 内核过滤驱动（WFP）顺藤摸瓜查到了安全软件的底层 SQLite 数据库，不仅一举破案，还顺带揪出了一个容易被忽视的内网穿透与远程桌面（RDP）安全隐患。特将完整排查思路与解决过程记录如下。

一、诡异的故障现象

先梳理一下家庭局域网（脱敏网段以 192.168.10.0/24 为例）的基础拓扑：

• 爱快主路由：192.168.10.1（连通正常）
• PVE 虚拟化宿主机：192.168.10.2（连通正常）
• OpenWrt 旁路由网关：192.168.10.251（连通正常）
• 群晖 NAS：192.168.10.3（手机、平板、软路由、其他电脑访问均正常）
• 当前主力 Windows 电脑：192.168.10.100（唯独无法访问群晖 192.168.10.3）

具体表现为：在当前电脑（192.168.10.100）上无论是通过浏览器访问群晖 DSM 后台（5000 端口），还是通过资源管理器挂载 SMB 共享文件夹（445 端口），全部连接失败。

二、第一阶段：二层 ARP 与三层 Ping 排查（发现端倪）

遇到同网段单点不通，首先怀疑的是二层交换隔离、ARP 缓存污染、或者本机静态路由冲突。打开 PowerShell 进行基础排查：

1. 检查本机 ARP 邻居表

Get-NetNeighbor -IPAddress 192.168.10.* | Format-Table -AutoSize

输出结果：

ifIndex IPAddress      LinkLayerAddress  State     PolicyStore
------- ---------      ----------------  -----     -----------
18      192.168.10.251 BC-24-11-XX-XX-1A Reachable ActiveStore
18      192.168.10.25  D8-43-AE-XX-XX-B9 Stale     ActiveStore
18      192.168.10.3   BC-24-11-XX-XX-A3 Stale     ActiveStore

可以看到，本机网卡已经成功通过 ARP 解析到了群晖 192.168.10.3 的正确 MAC 地址（BC-24-11-XX-XX-A3），说明局域网二层链路是通的，并不存在 VLAN 隔离或 AP 隔离。

2. 批量 Ping 扫描同网段 IP

紧接着对同网段 IP 进行 Ping 和端口连通性测试，结果出现了极为关键的线索：

--- Ping 192.168.10.1 ---
Reply from 192.168.10.1: bytes=32 time=3ms TTL=64

--- Ping 192.168.10.2 ---
Reply from 192.168.10.2: bytes=32 time=3ms TTL=64

--- Ping 192.168.10.3 ---
Pinging 192.168.10.3 with 32 bytes of data:
General failure.
General failure.

--- Ping 192.168.10.4 ---
Request timed out.

--- Ping 192.168.10.251 ---
Reply from 192.168.10.251: bytes=32 time=4ms TTL=64

使用 Test-NetConnection 192.168.10.3 -Port 5000 测试时，PowerShell 同样抛出了底层状态码告警：

警告: TCP connect to (192.168.10.3 : 5000) failed
警告: Ping to 192.168.10.3 failed with status: 11050

💡 关键突破口：为什么是 General failure（一般故障 / 状态码 11050） 而不是 Request timed out（请求超时）？

在 Windows TCP/IP 协议栈中，如果目标主机不开机或丢包，返回的是 Request timed out（如上方的 192.168.10.4）。而针对某一个特定 IP 瞬间返回 General failure (11050)，说明数据包根本就没有发出本机网卡，而是在本机操作系统的网络层/传输层被直接阻断丢弃了！

三、第二阶段：顺藤摸瓜排查 WFP 内核过滤驱动

在 Windows 系统中，能够让单个 IP 直接报 General failure 的只有两类机制：

1. 本机某张已断开连接的虚拟网卡恰好绑定了相同的静态 IP（排查 Get-NetIPAddress 后排除）；
2. WFP（Windows Filtering Platform，Windows 过滤平台）防火墙或第三方安全驱动拦截。

首先排查了 Windows Defender 防火墙的出站阻断规则（Get-NetFirewallRule -Action Block -Direction Outbound），并未发现针对 192.168.10.3 的策略。于是立即使用 driverquery 检查当前系统中正在运行的网络过滤驱动：

driverquery /v | findstr /i "callout wfp filter ndis bridge nat"

在驱动列表中，一行正在运行的内核驱动进入了视野：

hrwfpdrv  Huorong Network Security  Kernel  Auto  Running  C:Windowssystem32DRIVERShrwfpdrv.sys

这台电脑上安装了火绒安全软件（Huorong Security），其网络防护模块正是通过 hrwfpdrv.sys 挂载在 Windows WFP 过滤层上的！

四、第三阶段：深挖火绒底层数据库，真相大白

为了确认是不是火绒在暗中拦截了 192.168.10.3，直接检查火绒位于 C:ProgramDataHuorongSysdiag 目录下的 SQLite 数据库（user.db 与 log.db）。

检索 user.db 中的 TmpBlack_60（临时黑名单表），果然抓到了“真凶”：

=== TmpBlack_60 (火绒临时封禁黑名单表) ===
CREATE TABLE TmpBlack_60(id INTEGER PRIMARY KEY AUTOINCREMENT, raddr TEXT UNIQUE, func TEXT, time INTEGER)

(18, '192.168.10.144', 'RDP', 1792499785)
(19, '192.168.10.3',   'RDP', 1792500581)

再查看 log.db 中 HrLogV3_60 表的详细拦截日志，整个事件的前因后果彻底清晰：

{
  "fid": 53,
  "detail": {
    "laddr": "192.168.10.100",
    "detection": "RDP",
    "raddr": "192.168.10.3",
    "rport": 50864,
    "blocked": 1,
    "lport": 3389,
    "closeport": 0,
    "time": 60,
    "timeunit": 0
  }
}

🤔 为什么群晖 NAS（192.168.10.3）会攻击本机的 3389 远程桌面？

看到这里可能会觉得奇怪：群晖只是一台老老实实的 NAS，怎么会去暴力破解 Windows 电脑的 3389（RDP 远程桌面）端口呢？

串联起网络架构后恍然大悟：

1. 为了在外网偶尔连接家里的电脑，在群晖 NAS（192.168.10.3）上部署了内网穿透客户端（如 frpc / Lucky 端口转发 / 反向代理），把公网端口转发到了内网这台 Windows 电脑的 192.168.10.100:3389；
2. 公网上的自动化扫描器/黑客全天候在扫描公网端口，并对该端口发起高频的 RDP 弱口令暴力破解；
3. 由于流量是由群晖（192.168.10.3）在应用层/NAT 层转发给当前电脑的，当前电脑的 Windows 系统看到的TCP 连接源 IP 全部变成了群晖的内网 IP 192.168.10.3；
4. 当公网爆破触发多次 Windows 登录失败后，本机火绒安全软件的「远程登录防护（RDP 暴破拦截）」立刻介入，误以为 192.168.10.3 是攻击者，直接将群晖 IP 拉入 TmpBlack_60 临时黑名单封禁 60 分钟！
5. 一旦被火绒拉入 IP 黑名单，hrwfpdrv.sys 驱动会在本机底层阻断与 192.168.10.3 的一切进出流量（包括 ICMP Ping 和所有 TCP 端口），于是就出现了“全屋设备都能连群晖，唯独这台电脑连不上且 Ping 报一般故障”的现象。

五、解决办法与安全加固建议

1. 立即解除封禁（秒恢复）

1. 打开右下角的火绒安全软件；
2. 依次进入 防护中心 → 网络防护 → 远程登录防护（或右上角菜单 → 安全设置 → 网络防护 → 远程登录防护 / IP 黑名单）；
3. 在临时封禁的 IP 黑名单列表中，找到群晖的 IP（192.168.10.3）并点击移除/解封，无需重启电脑，群晖网页后台与 SMB 共享即可瞬间恢复访问。

2. 治标 vs 治本（切勿盲目加白名单！）

很多人遇到这种情况的第一反应是：“既然火绒误封了群晖 IP，那我把 192.168.10.3 加进火绒的 IP 信任区（白名单）不就行了？”

⚠️ 千万注意：如果内网穿透仍然将公网流量直接转发到本机 3389 端口，千万不要直接把转发节点的 IP 加入火绒白名单！

• 因为一旦你将 192.168.10.3 加入火绒白名单，意味着公网黑客通过群晖转发过来的所有 RDP 暴力破解请求，火绒将全部放行、不再拦截，你的 Windows 远程桌面将直接暴露在公网无限次撞库风险之下！

推荐的根治方案：

1. 关闭 3389 公网直通映射：在群晖的 FRP（frpc）或 Lucky 转发规则中，立即停用将公网端口直接裸映射到内网电脑 3389 的规则；
2. 改用虚拟局域网组网（最推荐）：远程桌面连接建议使用 Tailscale、ZeroTier 或 WireGuard 组建加密虚拟局域网，不向公网暴露任何 3389 端口；
3. 使用 FRP 的 STCP（安全访问端）模式：如果必须使用 FRP 穿透 RDP，请将类型从普通 tcp 改为 stcp（Secret TCP），要求访问端也必须持有密钥才能建立隧道，彻底杜绝公网扫描器爆破。

六、小结

排查网络故障时，错误提示的细微差别往往藏着最核心的线索：

• Request timed out（请求超时）：代表数据包已发出，但在链路上丢包或对端未响应；
• General failure（一般故障，状态码 11050）：代表数据包在本机协议栈内部就被拦截或路由失败（重点排查本机 WFP 安全驱动、防火墙黑名单、虚拟网卡静态 IP 冲突）。

通过这一线索顺藤摸瓜，只需几分钟即可精准定位问题根源。