家庭网络折腾笔记

看了 Sukka 的家庭网络组网方案，我想先把自己准备折腾家庭网络的原因记下来，再决定需要哪些设备。

我希望能看清家里谁在用网、外面哪些连接在访问家里的设备，发现攻击或异常流量时尽早收到提醒。物联网设备的访问范围也需要限制，VPN 和 DNS 要能按需求分流。遇到卡顿时，最好能沿着链路查出原因，知道该调整配置、换线，还是升级设备。

目前先整理需求和验证办法，设备型号、户型、宽带速率和预算留到盘点现网时补齐。我也想排查 App 是否在后台参与 PCDN 或共享带宽，具体行为还要靠流量和终端记录确认。

先让流量能对应到具体设备

只有一张全家上传、下载总量图，还回答不了我关心的问题。我想查到的是：某个时间段里，哪台设备连接了哪个地址，用了多少带宽，是否被防火墙放行。如果目标是 NAS，还想继续确认访问的是哪个服务、有没有登录成功。

这需要把几类记录对应起来。

例如，网关能记录一次连接的源和目标，NAS 的 SMB 日志则可能记录具体文件操作。两者要用时间、地址和会话信息关联起来，不能因为看到连接到 NAS，就认定文件已经被读取。¹²

外部地址可以附上 ASN、运营商和大致地区，帮助理解连接来自哪类网络。不过，IP 归属地无法直接说明背后是谁；代理、VPN 和共享出口都会影响判断。³

网关之外还有观察盲区

同一个 VLAN 里的设备通常直接通过交换机或 AP 通信，不必经过主路由。只在网关上开监控，就可能漏掉电视扫描同网段设备、电脑直接访问 NAS 等行为。需要深入观察这些路径时，可以补交换机端口镜像和流量采集器，或者先启用目标设备的服务日志。镜像哪些端口、是否包含收发两个方向、镜像口是否会过载，都影响覆盖范围。⁴

设备身份最好在 LAN 或 VLAN 入口、SNAT 和代理重新建立连接之前记录。到 WAN 或 VPN 隧道外侧再看，可能只剩网关地址或隧道端点。TUN 本身传递的是 IP 包，并不天然抹掉来源 IP；关键是流量在哪里被转换、在哪里采集。⁵

加密也会限制可见性。TLS、QUIC 和 VPN 的业务内容，不能靠普通抓包直接读出来；DNS 日志只覆盖经过该解析器的查询。设备自带 DoH 或 VPN 时，还需要终端侧记录。DPI 的应用分类可以辅助定位，但不能保证认出手机里具体哪个 App。Suricata 这类检测工具也不直接解密加密流量。⁶

告警要给出可以继续查的线索

我希望尽早发现攻击迹象，但监控无法保证在攻击发生前预知。比较实际的做法，是持续收集证据，在扫描、异常登录或流量变化出现时提醒，再决定是否需要阻断。

先关注这几类事件：

• 新设备加入网络，或者已有设备出现在意料之外的接入位置。
• IoT 设备持续尝试访问电脑、NAS 或管理网段。
• NAS 连续登录失败，或服务日志出现异常账户活动。
• 某台设备在平时空闲的时段持续上传，目标和连接数量明显变化。
• IDS 命中需要关注的规则，或重要设备的日志、监控采集突然中断。

告警里要带设备名、源和目标、时间范围、触发条件、相关流量及日志入口。已被防火墙挡住的零散扫描可以汇总；允许通过的可疑连接、NAS 异常登录和持续上传，更值得及时查看。IDS 负责检测，IPS 可以按策略阻断，两者都需要结合误报和实际影响调整。

对于疑似 PCDN，我会先观察持续上行、多目标连接、空闲时段活动等特征，再在设备上排查进程或容器。暂停可疑程序、保留前后对照，比仅凭某个域名或一次高上传更有说服力。系统更新、云备份、视频和正常 P2P 也可能产生类似表现；例如 Windows 的传递优化本来就可以向其他设备上传更新内容。⁷

处理时可以先对可疑设备限速，必要时临时阻断外联，再关闭确认不需要的带宽共享功能、停用相关程序或容器，观察流量是否恢复。已知域名和地址的拦截规则只能辅助，目标变化或共用 CDN 都会影响效果；不宜仅凭流量特征自动封禁整台设备。

阈值先按设备的正常用途建立，避免给摄像头、NAS 和手机套同一条标准。重复事件需要聚合和冷却，日志则要有轮转、保留周期和统一时间。长连接还需要实时计数或周期记录：如果会话结束后才落一条日志，持续跑流量时可能迟迟没有提醒。

用 VLAN 约束物联网设备的访问范围

听说 IoT 设备可能扫描内网，是我想划分 VLAN 的原因之一。这里先把它当作需要限制的风险，不认定家里的设备已经在做这件事。

VLAN 把设备分到不同的二层网络，跨网段能不能访问，还要由防火墙决定。初步可以按用途分组，具体 VLAN ID 和地址段等盘点完现网再定。

跨 VLAN 先采用默认拒绝，再加需要的访问规则，并允许已建立连接的回包。例如，电脑可以主动访问某个 IoT 服务，IoT 可以回应这次连接，但不能因此任意连接电脑。若设备需要主动向 Home Assistant 之类的控制器上报，再增加具体地址和端口的例外。⁸

同一 IoT VLAN 内的设备仍可能互相访问。需要进一步隔离时，要检查交换机 ACL、端口隔离和 AP 客户端隔离的实际覆盖范围，不能只勾一个 Wi-Fi 选项就认为有线、跨 AP 的设备也全部隔离了。⁸

这些规则要同时检查 IPv4 和 IPv6。只限制 IPv4 私有网段，不能证明 IPv6 路径也被限制；同时需要保留 IPv6 正常运行所需的 ICMPv6。⁹

投屏、打印和智能家居发现也要单独验证。mDNS 可以在指定 VLAN 和指定服务间转发，但“能发现设备”和“实际服务端口可以连接”是两步。配置时逐项放行需要的发现和控制流量，避免因为一次投屏失败就撤掉整个隔离策略。¹⁰

VPN 和 DNS 分流要分别验证

我把 VPN 需求先拆开：人在外面回家访问 NAS，是远程接入；家里某些设备或服务使用另一个互联网出口，是出站分流；工作电脑上的企业 VPN，则还有公司客户端自己的路由和 DNS 要求。这几条路径需要分别记录。

现有的 macOS 企业 VPN 与 Clash 共存笔记 已经记录了终端侧的配置。后续增加家庭网关分流时，要检查有没有让同一连接重复经过代理或 VPN。

DNS 分流决定向谁查询，业务分流决定连接从哪里出去。 两者要配合，但配好一项不会自动完成另一项。Mihomo 就把域名解析策略和业务路由规则分开配置。¹¹

验收时，需要同时看解析结果、命中的连接规则和实际出口，分别测试 A、AAAA 及对应的 IPv4、IPv6 连接。还要明确出口故障后的行为：停止访问、切换备用出口，还是允许直连。需要固定走指定出口的服务，拟采用故障后停止访问；其他服务是否允许回退，按用途再定，并通过断开隧道测试确认。

家庭 DNS 暂时按独立服务考虑，由各网段访问它的必要端口。是否需要高可用要结合停机影响决定，不能默认给客户端填一个公共“备用 DNS”就仍然保持相同的过滤和分流策略。

用 L2TP 接入朋友并联机英雄无敌3

这部分先确定使用群晖 VPN Server 的 L2TP/IPsec。计划由我在家里的电脑上开《英雄无敌3》房间，朋友从外面连接 VPN，再通过游戏电脑的内网 IP 加入。NAS 负责 VPN 接入和转发，游戏仍运行在电脑上。

下面按双方使用 Windows 10/11、经典版游戏提供 TCP/IP 联机入口来写。实际游戏版本、DSM 版本和地址还要核对；以下是配置与验收步骤，不代表这些设置已经在家里的设备上生效。

先填好地址和访问范围

VPN 地址池、双方家庭网络和已有 VPN 网段尽量不要重叠。需要处理地址冲突时，先调整地址规划；相同的私网地址在双方各代表一台设备，会让路由选择和排障变得含糊。

目标是让朋友访问游戏电脑所需的游戏通信，同时拒绝访问 NAS 服务、路由器管理页面、其他家庭设备和其他 VPN 客户端，也不借用我家的出口上网。**只给客户端添加游戏电脑的 /32 路由，是分流配置，不能代替服务端访问控制。**朋友能够修改自己的路由表。

第一步 准备群晖账号和 L2TP 接入

1. 在 DSM 的“控制面板 → 用户与群组”中，为每位朋友建立独立的普通账号，例如 h3-friend-a，不要加入 administrators。
2. 检查这些账号的共享文件夹权限及应用权限，撤掉不需要的访问，尤其检查默认用户组继承的权限。若某项应用权限会影响 VPN 登录，再按实际提示核对，不用管理员账号绕过。
3. 在“VPN Server → 权限”中，只为这些账号启用 L2TP/IPsec 接入，其他 VPN 协议按需关闭；检查是否存在新用户默认获准接入的设置。
4. 在“VPN Server → L2TP/IPsec”检查服务已启用，记下当前动态地址池、连接数上限和 IPsec 预共享密钥。沿用现有可用配置；修改预共享密钥会影响所有使用它的客户端。
5. 各人的账号密码分别保存，预共享密钥通过私密渠道交付，不写进笔记、截图或脚本。预共享密钥与每个人的账号密码是两项凭据。

VPN Server 的用户权限管理控制的是谁可以登录 VPN，并不等于已经限制其能访问哪些 LAN 设备。¹²

若目前已经能从外网连回家，保持现有端口映射。只有入口尚未打通时，才按群晖文档检查 L2TP/IPsec 使用的 UDP 500、1701、4500 及路由器、防火墙配置；这里不向公网新增游戏、DSM 或 SMB 的端口映射。DDNS 只负责名称解析，不能解决运营商 CGNAT 或未处理的多层 NAT。¹³

第二步 确认服务端隔离策略

这里需要先区分两个层次：NAS 自己收到的请求，以及 NAS 替朋友转发到局域网的请求。对于同一 LAN 上的 NAS 和游戏电脑，解密后的流量可能直接经过交换机，主路由的跨 VLAN 规则未必会被经过。

在 Linux 的常规路由路径中，这两类流量分别经过 INPUT 和 FORWARD。因此，不能只在游戏电脑上放行程序，或者只设置 DSM 的共享权限，就认为其他设备也被保护了。¹⁴

我准备采用下面的服务端策略。它是需要落实到实际设备的规则表，不是 DSM 界面中已经存在的一组开关。

这些是隧道解密后的规则，不应把建立 L2TP/IPsec 所需的外层握手一起挡住。规则还需要排在已有宽泛放行之前；最终拒绝要覆盖受控接口，不能仅拒绝预期地址池，否则来源不符合预期的包可能绕过。

**群晖普通防火墙界面不能直接当成任意 LAN 目标的访问控制界面。**若实际版本没有能管理这段转发流量的功能，就需要在 NAS 的实际转发链上实现规则，或者让这段流量必经一台能持久管理策略的防火墙。给 NAS 单独划一个 VLAN 也不自动完成这件事：仍要检查经过的路径、NAT 后看到的来源，以及该 VLAN 内还有哪些设备。

在决定具体规则前，可以在 NAS 的本地管理通道中运行以下只读命令，保存接口、路由、NAT 和现有规则。iptables、ip6tables 的读取通常需要管理员或 root 权限，应通过可恢复的本地管理入口取得权限；权限不足不代表没有规则。输出保留在自己的管理记录里，不包含账号密码和预共享密钥：

1
2
3
4
5
6
7
8

ip address
ip route
iptables -S INPUT
iptables -S FORWARD
iptables -t nat -S
iptables -nvL INPUT --line-numbers
iptables -nvL FORWARD --line-numbers
ip6tables -S

不同 DSM 版本可用的命令和防火墙实现可能不同。需要把朋友的一次登录、分配地址与新增接口对应起来。不要未经确认就用 ppp+ 匹配：它会匹配所有以 ppp 开头的接口，可能同时包含其他 VPN 或 PPPoE，编号也可能随重连变化。¹⁵

如果所有 L2TP 用户共用一个地址池，把整池限制成“只访问游戏电脑”也会限制我自己的 L2TP 账号。想继续用 L2TP 管理 NAS，就需要能可靠区分会话的服务端策略或独立实例；不能假定建一个朋友用户组就会获得独立地址池。另一种安排是 L2TP 专供游戏，自己通过本地网络或已有 OpenVPN 管理，但切换前要确认原有管理连接仍可用。

这一段必须按实际 DSM 版本、接口和既有规则生成配置，不能把通用 iptables 命令当成已验证的群晖脚本。保存基线、保留本地管理入口，不清空系统规则，也不全局修改默认策略。服务端规则和后面的负向测试未完成前，只能记为 VPN 接入可用，不能记为“朋友已被限制在游戏电脑”。

第三步 朋友在 Windows 建立连接并分流

先由我用自己的测试账号验证服务端规则，再让朋友接入。Windows 的“设置 → 网络和 Internet → VPN → 添加 VPN”中填写：

保存后，先断开连接，在创建该 VPN 的同一个 Windows 用户下打开 PowerShell。下面只修改 H3-Home，不要用它改公司 VPN：¹⁶

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 先确认连接确实存在，并记下原来的 SplitTunneling 状态
Get-VpnConnection -Name 'H3-Home'

# 普通上网保留本地出口，只增加游戏电脑的目标路由
Set-VpnConnection -Name 'H3-Home' -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName 'H3-Home' -DestinationPrefix '192.168.50.20/32'

# 重新连接 VPN 后查看实际地址和路由
ipconfig
route print -4

如果路由已经存在，不要重复添加。上述命令按当前用户的 VPN 配置编写；若使用的是所有用户连接，需要管理员权限，并在对应 VPN 命令中一致使用 -AllUserConnection。¹⁷

检查游戏电脑的 /32 路由是否指向 VPN，其他上网流量是否仍走朋友原来的出口。这个连接直接使用游戏电脑 IP，不需要为了联机把朋友的全部 DNS 改成我家的 DNS；若连接后出现解析异常，再检查 VPN 下发的解析器和接口选择。

若 L2TP 连不上，先核对账号权限、预共享密钥、公网入口、端口和 NAT。Windows 的 NAT-T 兼容问题要按错误现象及微软说明处理，不默认修改所有人的注册表。¹⁸

第四步 放行游戏程序并建立房间

双方先核对游戏版本、补丁和 Mod。HD Mod 与育碧 HD Edition 不同；这里不要求为联机安装 HotA 或改变原来的玩法。经典版 LAN/TCP/IP 联机需要的 DirectPlay，可以在 Windows“启用或关闭 Windows 功能 → 旧版组件 → DirectPlay”中启用。具体入口随版本略有差别。¹⁹

在我开房的游戏电脑上，先检查 Windows 防火墙实际看到的来源。如果 NAS 保留了 VPN 客户端源地址，可以使用 VPN 地址池作为来源范围；如果 NAS 做了 SNAT，电脑可能只看到 NAS 的内网 IP。这时 Windows 规则要使用实际来源，朋友身份和访问目标的限制仍由 NAS 转发规则承担。

如果保留 VPN 源地址，还要检查游戏电脑的回程：到朋友 VPN 地址的路由应能经 NAS 返回，可以由家庭网关的静态路由或游戏电脑的主机路由实现。先用 route print -4 核对实际路径，再决定在哪一层补路由，不直接照抄示例改变现网。

如果电脑只看到 NAS 地址，则还要检查已有的“本地子网允许”规则。它们可能已经允许这批转发流量访问 SMB、远程桌面等服务；新增游戏程序规则不会撤销这些旧权限，需要收窄相关服务的来源范围，并通过负向测试确认。

下面是在房主电脑上、以管理员身份运行的示例。先把路径改成实际运行游戏的程序，不要填启动器；HD 或 HotA 的可执行文件名可能不同：

1
2
3
4
5
6
7
8

$h3GameExe = 'C:\Games\Heroes3\Heroes3.exe'
$h3VpnSource = '10.27.30.0/24'  # 仅在实际保留 VPN 源地址时使用
if (-not (Test-Path -LiteralPath $h3GameExe)) {
    throw '请先填写实际游戏程序路径'
}

New-NetFirewallRule -Name 'H3-L2TP-TCP' -DisplayName 'Heroes3 from game VPN TCP' -Direction Inbound -Action Allow -Program $h3GameExe -Protocol TCP -RemoteAddress $h3VpnSource -Profile Any
New-NetFirewallRule -Name 'H3-L2TP-UDP' -DisplayName 'Heroes3 from game VPN UDP' -Direction Inbound -Action Allow -Program $h3GameExe -Protocol UDP -RemoteAddress $h3VpnSource -Profile Any

规则只为该程序放行来自指定范围的流量，没有向公网开放游戏端口。检查旧的游戏放行项和拒绝项，避免已有宽泛允许扩大范围，或已有显式拒绝挡住新规则；Windows 的显式拒绝优先于允许，不能用“一条拒绝所有，再添加允许游戏”来模拟有顺序的路由器规则。²⁰

随后我在游戏的“多人游戏 → TCP/IP”中创建房间，朋友连接 L2TP 后使用 192.168.50.20 加入。NAS 地址不是房主地址。房间不自动出现在列表中时，先尝试按 IP 查找，不把整个家庭网络桥接出去。

如果能够找到房间却进不去，或进入后卡住，要继续检查 DirectPlay、游戏版本、程序路径、回程路由和 NAT。若实际游戏要求房主向朋友发起新的反向连接，应把对应通信加入服务端策略，并在朋友电脑上只放行游戏程序所需的来源；不要直接允许所有 LAN 主机访问 VPN 客户端。多人游戏如果要求朋友之间直接通信，也与“只能访问房主电脑”的严格目标存在冲突，需要按实际版本测试后再决定是否增加例外。

第五步 同时验证联机和隔离

第一轮先由我在手机热点或其他外网用测试电脑完成，再邀请朋友测试。所有示例地址换成实际值。

**负向测试必须保证流量真的进入 VPN。**只配置游戏 /32 路由时，NAS 打不开可能只是没有路由，不能证明服务端成功拦截。可以在自己的受控测试电脑上临时添加 NAS 的 VPN 路由，再检查已知开启的服务端口和服务端拒绝计数：

1
2
3
4
5
6
7
8
9

# 仅用于隔离验收，若这条路由原本已存在则不要重复添加
Add-VpnConnectionRoute -ConnectionName 'H3-Home' -DestinationPrefix '192.168.50.10/32'

# 按需重连后，先用 route print -4 确认路由确实走 VPN
Test-NetConnection -ComputerName '192.168.50.10' -Port 5001
Test-NetConnection -ComputerName '192.168.50.10' -Port 445

# 测完移除本次添加的测试路由
Remove-VpnConnectionRoute -ConnectionName 'H3-Home' -DestinationPrefix '192.168.50.10/32'

5001 和 445 只是示例；NAS 服务端口若改过，要替换为实际端口。再用相同办法测试网关和另一台有已知服务的设备。只有确认请求已进入隧道、命中服务端拒绝规则，才能把失败归因于隔离，而不是目标服务没开或路由错误。

还要在 VPN 重连、VPN Server 重启、DSM 防火墙重新应用配置、NAS 重启后重复关键测试。手工添加的规则可能被重载影响；定时任务过一段时间补回规则，也不能证明中间没有放行窗口。如果要长期持续保证隔离，需要可靠的规则持久化及启动顺序，或使用能持久管理策略的必经防火墙。

结束联机和撤销配置

朋友暂时不用时，在 VPN Server 断开该连接并撤销账号的 L2TP 权限；以后不再使用则禁用账号。仅修改密码不应被当成已经断开现有会话，需再查连接列表。

测试期间新增的 Windows 规则可以按名称单独撤销，不影响其他防火墙规则：

1
2
3
4
5

# 在房主电脑上删除本节新增的游戏规则
Remove-NetFirewallRule -Name 'H3-L2TP-TCP','H3-L2TP-UDP'

# 在朋友电脑上删除本节新增的游戏路由
Remove-VpnConnectionRoute -ConnectionName 'H3-Home' -DestinationPrefix '192.168.50.20/32'

NAS 端的规则按实施前的基线逐项撤销，不全局清空防火墙。撤销隔离前先停止朋友接入；只有确认已有客户端断开，才恢复对应策略。

网络卡顿时逐段缩小范围

我希望性能尽可能好，也希望知道实际限制在哪里。先画出从设备到目标的路径，再逐段测，比只看一次公网测速更有用。

下面是待验证的组网草图。跨 VLAN 路由暂定由网关承担；如果以后改由三层交换机转发，隔离规则和采集位置也要随之调整。

可以用 iperf3 建立内网基准。下面只是在两台自己的测试主机上运行的示例，把 SERVER_IP 替换为服务端地址：

1
2
3
4
5
6
7

# 服务端主机
iperf3 -s

# 客户端主机依次测试
iperf3 -c SERVER_IP -t 30
iperf3 -c SERVER_IP -t 30 -R
iperf3 -c SERVER_IP -t 30 -P 4

依次记录单流、反向和四条并发流的结果；-R 是反方向发送，另外的 --bidir 才是同时双向测试。多流更快只能说明单流还受其他因素限制，不能据此认定线材或链路完全没有问题。²¹

端口协商到 2.5GbE，也不代表持续传输就一定正常。测速时要看两端和交换机的错误计数增量，区分 CRC/FCS 错误与一般丢弃；后者也可能来自队列或处理能力。发现问题后，每轮只替换一根线、一个端口或一个测试端，保留可比较的结果。²²

还要在上传和下载负载下同时观察延迟。测速数字很高，满载时视频会议仍然卡顿，可能和排队有关；可以比较到网关、内网服务器和多个公网目标的表现，再考虑 QoS 或 SQM。单个公网目标的 ICMP 丢包不足以证明自家链路有问题。Flent 的 RRUL 测试就是把吞吐和负载下延迟放在一起观察。²³

按这些要求筛设备和安排下一步

现在回头看，设备选型要问的不只是端口有没有万兆，还包括：正常连接能否记录、长期连接能否及时更新、日志可以保存多久、采集是否抽样、是否支持导出，以及开启实际要用的功能后还能达到什么吞吐。

以 UniFi 为例，2026 年 10 月查到的官方文档将 UCG Ultra 的 Traffic Flows 列为仅记录被阻止的连接；UCG Max、UCG Fiber 等才列出允许和阻止的连接记录，完整功能还受版本和存储条件影响。官方 IPFIX 导出注明是采样数据，活动日志导出也不等于全部会话日志都能实时导出。因此，要满足这篇笔记的需求，不能直接沿用旧文章的入门网关推荐。¹

主网关、网管交换机、AP、DNS 和日志采集服务可以分别承担职责。第一阶段先利用设备已有的统计和日志；发现明确盲区后，再考虑增加流量分析或 IDS 采集器。监控服务要限制访问，日志存储故障也不应拖垮主路由；如果采集器放在 NAS 上，NAS 自己故障时会丢失哪些记录，也要提前考虑。

接下来按下面的顺序推进：

1. 盘点现网。 记下光猫、路由器、交换机、AP、NAS、网卡和线材，标出端口连接关系、协商速率、宽带上下行，以及远程接入可用的地址条件。
2. 建立基准。 给设备补名称和地址对应关系，记录当前内网、Wi-Fi、公网和 NAS 的表现，收集正常时段的流量。
3. 先验证一组隔离。 选一台 IoT 设备迁入独立 VLAN，检查不能访问的服务确实被限制、需要的控制与发现仍可用，再逐步迁移。
4. 逐类验证 VPN 和 DNS。 从少量域名和设备开始，对照查询路径、业务出口、IPv6 以及故障回退行为。
5. 接通并试验告警。 用受控的连接尝试、短时上传和测试账户登录失败，确认能收到包含设备与目标信息的通知；同时确认停止采集也能被发现。

第一份需要补齐的材料，是家里现有设备和连线的拓扑图。有了这张图和有线基准，才能判断哪些能力现有设备就能补上，哪些确实需要购买或更换。

资料与相关笔记

通用组网资料的核对日期为 2026 年 10 月 26 日，L2TP 联机步骤补充于 2026 年 10 月 27 日。具体产品的功能、日志范围和默认策略以实际安装版本为准。

• Sukka 的家庭网络组网方案
• 在 macOS 上让企业 VPN 与 Clash 共存