小型网络系列：开篇 - 300-500 Devices 的网络为什么也会复杂
系列导航
- 小型网络系列：开篇 - 300-500 Devices 的网络为什么也会复杂
- 小型网络系列：RouterOS 和 Switch 的职责边界
- 小型网络系列：LAG、VLAN 和 Macvlan 为什么会一起出现
- 小型网络系列：PCC 分流逻辑和故障行为
- 小型网络系列：WireGuard 为什么是日常路径
- 小型网络系列：脚本、Scheduler 和可恢复性
背景
这个系列我先不叫“企业网络”，也不打算把它写成企业最佳实践。
真实规模大概是 300-500 Devices，最多的时候不到 250 人。按我的理解，这更适合叫小型网络，离那种真正中大型组织网络还有距离。它有复杂度，但复杂度主要来自线路、站点、远程访问、管理路径和历史取舍，而不是来自严格的组织层级、部门边界或合规要求。
所以这套东西的口径会比较朴素：
- 这是一个小型互联网公司网络
Office-JT是主要办公地点Office-SQ和DC-101通过 WireGuard 连到主办公网络- RouterOS 是核心路由和策略承载点
- Switch、Bonding、VLAN、Macvlan、PCC 都是在解决现实接入问题
- WRT / NetBird / ZeroTier 更偏 Admin Overlay 和 Backup Path，不是办公室日常主数据面
- 运营同事也会通过 WireGuard 访问 SMB LAN IP Windows 共享，延续搬迁前在同一个 LAN 里的协作方式
- 无线接入靠 Ubiquiti UniFi PoE AC AP，没开无线 Mesh，2.4G / 5G 拆成两个 SSID
我也不是专职网管。这套网络很多地方都不是教科书式的“企业级拆分”，更像是一个技术同事顺手把它维护到能稳定工作的状态。说难听点有点草台，说好听点就是很实用。
为什么“小型”也会复杂
如果只看人数和设备数，它确实不大。
但网络复杂度不只来自人数。只要同时出现下面几件事，小型网络也会很快复杂起来：
- 当前实际已经是 3 条 WAN 接入，需要同时承载办公流量
- 有的线路是 PPPoE，有的线路是静态地址，有的线路质量和用途不一样
- 后续还要预留继续增加 Modem 的可能
- RouterOS CHR 在 PVE Host 里，Switch 到 RouterOS 之间需要复用链路，不能每条 WAN 都独占一根 PVE 物理网口
- 两个 1G 电口可以提供最多 2G 全双工的 WAN UP/DOWN 承载，Bonding 不只是冗余，也是在解决带宽上限
- 远端办公室和 DC 不是偶尔管理，而是要稳定承载日常访问
- 内部用户访问某些 DC 非 HTTP 服务时，希望看起来仍然是访问服务名，但实际走 LAN / WireGuard 路径
- 搬迁后分开的办公室，仍然要让运营同事继续用原来的 SMB Windows 共享路径协作
- 网络设备、PVE、WRT、Overlay Peer 都需要保留管理入口
- 故障时不能靠“我人在现场插键盘”作为唯一恢复方案
这就是我想写这个系列的原因。
它不是一个庞大企业网络，但它已经超过了“一个路由器加一个交换机就结束”的复杂度。
flowchart LR users["Office-JT Users
300-500 Devices / Peak <250 People"] sw["Managed Switch
LAG / VLAN Carrier
192.168.8.90"] ros["Office-JT RouterOS
Gateway / PCC / WireGuard
192.168.8.1/21"] wan["Multi-WAN
3 Inputs / Future Modems
route1 / route2 / route3"] sq["Office-SQ
WireGuard Site
192.168.2.101"] dc["DC-101
WireGuard LAN
172.16.2.101"] pve["Office-JT PVE
192.168.8.100"] users --> sw sw --> ros ros --> wan ros <-->|WireGuard| sq ros <-->|WireGuard| dc ros --> pve
flowchart LR users["Office-JT Users
300-500 Devices / Peak <250 People"] sw["Managed Switch
LAG / VLAN Carrier
192.168.8.90"] ros["Office-JT RouterOS
Gateway / PCC / WireGuard
192.168.8.1/21"] wan["Multi-WAN
3 Inputs / Future Modems
route1 / route2 / route3"] sq["Office-SQ
WireGuard Site
192.168.2.101"] dc["DC-101
WireGuard LAN
172.16.2.101"] pve["Office-JT PVE
192.168.8.100"] users --> sw sw --> ros ros --> wan ros <-->|WireGuard| sq ros <-->|WireGuard| dc ros --> pve
flowchart LR users["Office-JT Users
300-500 Devices / Peak <250 People"] sw["Managed Switch
LAG / VLAN Carrier
192.168.8.90"] ros["Office-JT RouterOS
Gateway / PCC / WireGuard
192.168.8.1/21"] wan["Multi-WAN
3 Inputs / Future Modems
route1 / route2 / route3"] sq["Office-SQ
WireGuard Site
192.168.2.101"] dc["DC-101
WireGuard LAN
172.16.2.101"] pve["Office-JT PVE
192.168.8.100"] users --> sw sw --> ros ros --> wan ros <-->|WireGuard| sq ros <-->|WireGuard| dc ros --> pve
flowchart LR users["Office-JT Users
300-500 Devices / Peak <250 People"] sw["Managed Switch
LAG / VLAN Carrier
192.168.8.90"] ros["Office-JT RouterOS
Gateway / PCC / WireGuard
192.168.8.1/21"] wan["Multi-WAN
3 Inputs / Future Modems
route1 / route2 / route3"] sq["Office-SQ
WireGuard Site
192.168.2.101"] dc["DC-101
WireGuard LAN
172.16.2.101"] pve["Office-JT PVE
192.168.8.100"] users --> sw sw --> ros ros --> wan ros <-->|WireGuard| sq ros <-->|WireGuard| dc ros --> pve
这套网络在解决什么
Office-JT 是主要办公地点，所以它的问题最多。
主网关是 RouterOS CHR，LAN 侧是 192.168.8.1/21。Switch 管理地址是 192.168.8.90，PVE 是 192.168.8.100。这些 LAN 地址可以公开讲，因为它们只是内网拓扑语义；真正需要避免暴露的是公网 IP、真实域名、MAC 和具体地点。
它当前至少要解决几类问题：
- 普通办公设备稳定出网
- Multi-WAN 之间按策略分流
- 部分线路故障或质量变化时可以切换 PCC 模式
Office-SQ和DC-101通过 WireGuard 保持站点互通- 技术同事访问
DC-101的非 HTTP 服务时，走 WireGuard Peer 到DC-101LAN，用于日常开发测试 - 运营同事在
Office-JT/Office-SQ之间访问 SMB LAN IP Windows 共享，作为日常协作路径 - 对内使用服务名访问 DC 资源时，公共 DNS 记录可以直接返回 LAN / Internal Address，而不是把内部访问绕到公网入口
- 管理入口和 Backup Path 要和日常办公流量区分开
这里最容易误解的是最后几项。
DC-101 不是只给我个人远程管理用的点。对技术同事来说，有些非 HTTP 服务是日常开发测试会访问的资源。它们可以使用服务名，对应的公共 DNS 记录本身就返回 LAN 地址，再经由 WireGuard 到 DC-101。
这里不是办公室内部 DNS Rewrite，也不是维护一套 Split DNS。反正不在可信 LAN / WireGuard 网络里，解析到 LAN 地址也访问不了。真正的边界还是网络可达性：公网只暴露 HTTP 服务，非 HTTP 内部服务留在 LAN / WireGuard 里，不开放公网。
Office-JT 和 Office-SQ 之间的 SMB 访问也类似。它不是为了炫技做跨站访问，而是为了延续历史工具路径：最早大家在一起办公，Windows 共享就是 LAN 内协作方式；后面搬迁把办公室拆开之后，WireGuard 让这条路径不需要立刻重做成另一套系统。
HTTP 服务入口可以有另一套公网边界，但非 HTTP 内部服务更适合放在站点互联路径里解决。
VLAN 不是部门隔离
这套网络里有 VLAN，但它当前不是为部门隔离设计的。
Office-JT 的 Switch 到 RouterOS 之间有一个 LAG1，RouterOS 侧是 bonding1。LAN 仍然在基础 bonding1 / br-lan 上，几条 WAN 则通过 VLAN 复用到 RouterOS：
| VLAN | 角色 | RouterOS 侧路径 |
|---|---|---|
10 |
PPPoE WAN | vlan10 -> macvlan10 -> pppoe-out1 |
20 |
PCC route2 | vlan20 -> macvlan20 |
30 |
PCC route3 | vlan30 -> macvlan30 |
所以这里的 VLAN 主要在解决两个问题：
- 当前 3 条 WAN 从 Switch 侧接入后，如何复用同一组 Bonding 链路送到 RouterOS，并给后续 Modem 预留空间
- RouterOS 上如何为不同 WAN 保留独立的 L2 / Macvlan 身份
它不是在做“研发部一个 VLAN、财务部一个 VLAN、访客一个 VLAN、服务器一个 VLAN”的细分模型。LAN 侧 192.168.8.0/21 这个大子网也不是精心设计出来的广播域治理结果，而是延续了快 10 年的初始设计。懒得改是一部分原因，另一部分原因是实际在线规模也就是 300-500 Devices，暂时还没逼到必须重做地址规划。
为什么不做？
原因也不复杂。公司本身是相对宽松的互联网公司，没有强到必须按部门拆广播域和访问边界的机密隔离压力。我也不是专职网管，维护目标首先是让网络稳定、可理解、可恢复，而不是追求一套看起来很企业级的细分网络治理。
当然，严格说这不是没有成本。
广播域治理、访客隔离、东西向访问控制、安全审计，这些能力会弱一些。但在当前阶段，复杂度和收益不匹配。把 VLAN 先用于 Multi-WAN 和 Bonding 复用，是更现实的取舍。
PCC 为什么要单独写
PCC 是这个系列里很重要的一篇，甚至可能不止一篇。
Office-JT 的 PCC 不是一句“多线负载均衡”就能解释完。它实际有几组可切换的模式：
| 模式 | 含义 |
|---|---|
0:1:1 |
不使用 route1，只在 route2 / route3 之间分流 |
1:1:1 |
route1 / route2 / route3 等比例分流 |
1:2:2 |
route1 权重低，route2 / route3 权重更高 |
2:3:3 |
三条线路都用，但 route2 / route3 权重更高 |
RouterOS 里的实现不是临时手改规则，而是有一组脚本去切换 pcc-mark-N/ Bucket Rules。
核心边界是：
pcc-mark-<denominator>/<bucket>-route<route>负责 PCC Bucketpcc-routing-route<route>负责后续 Routing Mark- 切换脚本只禁用
^pcc-mark-这层 Bucket Rules - 切换脚本启用当前模式对应的
pcc-mark-N/ pcc-routing-*不应该被 PCC 模式切换脚本误伤
这个边界很关键。
因为 PCC 的风险不只是“流量有没有平均分”。更麻烦的是：当一条 WAN 质量变化、某条线路需要临时降权、或者 PPPoE 需要避开时，脚本必须只切 Bucket Layer，而不能把后面的 Routing Layer 一起打乱。
所以后面写 PCC 时，我会基于 Office-JT 的实际脚本讲，而不是泛泛讲 RouterOS PCC 的概念。
WireGuard 是日常路径，不是临时救火
在 Homelab 系列里，NetBird 是很重要的 Admin Overlay。
但在这个小型网络系列里，主角会换成 WireGuard。
原因是 Office-JT、Office-SQ、DC-101 之间的关系更像站点互联，而不是我个人拿 MacBook 从外面临时访问一下。RouterOS 内部承载 WireGuard，既能跑日常用户流量，也能承担一部分管理职能。
这和 WRT / NetBird / ZeroTier 的位置不一样：
- WireGuard：办公室站点之间的日常路径
- WRT Peer：额外 Admin Layer
- NetBird Peer：Portable Devices (Admin) 访问和管理辅助
- ZeroTier Peer：Backup Path
所以这套网络不能简单套用 Homelab 的分层。
Homelab 里我更关心“主网关要稳，WRT 承载透明代理和 Admin Overlay”。办公室这里更关心“RouterOS / Switch / WireGuard / PCC 如何把日常网络跑稳”。WRT 仍然存在，但它不应该抢走主数据面的叙事。
最后的结论
300-500 Devices、最多的时候不到 250 人，我会把它叫小型网络。
但“小型”不等于“简单”。
只要它开始同时处理 Multi-WAN、PCC、Switch Bonding、VLAN、Macvlan、WireGuard 站点互联、公共 DNS 返回内网地址和远程管理路径，它就已经是一套需要认真记录取舍的网络。
这套网络最核心的特点不是企业级，而是实用：
- VLAN 先服务当前 3 条 WAN 接入、后续 Modem 预留和 Bonding 复用
- PCC 解决不同 WAN 之间的可切换分流
- WireGuard 承载站点之间的日常访问
- 公共 DNS 直接给出 Internal Address，访问能力仍然受 LAN / WireGuard 安全域限制
- WRT / NetBird / ZeroTier 保留为 Admin Layer 和 Backup Path
- 复杂度只在有收益的地方出现
它不完美，也不优雅，但在这个规模和管理方式下，它是更容易长期维护的形态。
后续准备怎么写
后面几篇我会按决策拆开写。
第一篇先把问题范围定住：这是小型网络，不是企业网络；它复杂，是因为接入、线路、站点和管理路径叠在一起。
完整章节已经放在顶部系列导航里。这个系列会先拆 RouterOS / Switch 的职责边界，再拆 LAG / VLAN / Macvlan，之后单独写 PCC。PCC 那篇会更偏实现细节，因为分流脚本和故障行为都值得展开讲。