全栈之路
全栈之路

小型网络系列：WireGuard 为什么是日常路径

CsHeng
 约 800 字 预计阅读 4 分钟 

系列导航

  1. 小型网络系列：开篇 - 300-500 Devices 的网络为什么也会复杂
  2. 小型网络系列：RouterOS 和 Switch 的职责边界
  3. 小型网络系列：LAG、VLAN 和 Macvlan 为什么会一起出现
  4. 小型网络系列：PCC 分流逻辑和故障行为
  5. 小型网络系列：WireGuard 为什么是日常路径
  6. 小型网络系列：脚本、Scheduler 和可恢复性

背景

在 Homelab 系列里，我反复提到 NetBird 是 Admin Overlay。

但在这个小型网络系列里，办公室站点互联的主角不是 NetBird，而是 RouterOS 上的 WireGuard。

原因很简单：这里要承载的是日常网络路径，不只是我个人拿 MacBook 从外面管一下设备。

Office-JT、Office-SQ、DC-101 之间有几类真实需求：

  • 技术同事从 Office-JT 访问 DC-101 的非 HTTP 服务，用于日常开发测试
  • 服务名的公共 DNS 记录直接返回 LAN / Internal Address，然后走 DC-101 LAN
  • 运营同事在 Office-JT 和 Office-SQ 之间访问 SMB LAN IP Windows 共享
  • 搬迁后分开的办公室，仍然要延续原来在同一 LAN 里的协作习惯
  • RouterOS 之间还需要一部分管理和可恢复路径

这些需求不是临时救火，而是日常使用。

为什么选 WireGuard

这里选 WireGuard，不是因为它最新，也不是因为它名字好听。

它刚好适合这个规模：

  • 只有 Office-JT、Office-SQ、DC-101 这几个核心 RouterOS Peer
  • 其中两个点有相对稳定的公网可达性，包括 PPPoE 拨号拿到动态公网 IP 后通过 DDNS 维持 Endpoint
  • RouterOS 自带 WireGuard，不需要额外 WRT、Linux VM 或 Overlay Appliance 承载主数据面
  • 站点之间是固定 LAN 路由，不是大量动态个人客户端
  • 排障时可以直接在 RouterOS 里看 Peer、Route、Netwatch 和 Scheduler

这和 NetBird / ZeroTier 的定位不一样。

NetBird 更适合 Portable Devices (Admin) 和额外 Admin Overlay。ZeroTier 在这里更像 Backup Path。它们有价值，但不应该承载办公室日常协作的主路径。

主数据面放在 RouterOS WireGuard 里，路径更短，依赖更少，也更符合 RouterOS 作为主网关的角色。

日常流量有哪些

WireGuard 这条路径当前至少承载三类日常流量。

第一类是技术同事访问 DC-101 的非 HTTP 服务。

这些服务主要服务日常开发测试，不开放公网。它们可能有服务名，但这里不是靠办公室内部 DNS Rewrite，也不是另外维护一套 Split DNS。

更朴素的做法是：公共 DNS 记录本身就直接返回 LAN / Internal Address。

反正不在可信 LAN / WireGuard 网络里，解析到 LAN 地址也访问不了。用户看起来是在访问熟悉的名字，实际路径是：

sequenceDiagram
  participant User as Office-JT User
  participant DNS as Public DNS
  participant JT as Office-JT RouterOS
  participant WG as WireGuard
  participant DC as DC-101 LAN

  User->>DNS: Resolve Service Name
  DNS-->>User: LAN / Internal Address
  User->>JT: Access Non-HTTP Service
  JT->>WG: Route to DC-101 LAN
  WG->>DC: Reach DC-101 Service
sequenceDiagram
  participant User as Office-JT User
  participant DNS as Public DNS
  participant JT as Office-JT RouterOS
  participant WG as WireGuard
  participant DC as DC-101 LAN

  User->>DNS: Resolve Service Name
  DNS-->>User: LAN / Internal Address
  User->>JT: Access Non-HTTP Service
  JT->>WG: Route to DC-101 LAN
  WG->>DC: Reach DC-101 Service
sequenceDiagram
  participant User as Office-JT User
  participant DNS as Public DNS
  participant JT as Office-JT RouterOS
  participant WG as WireGuard
  participant DC as DC-101 LAN

  User->>DNS: Resolve Service Name
  DNS-->>User: LAN / Internal Address
  User->>JT: Access Non-HTTP Service
  JT->>WG: Route to DC-101 LAN
  WG->>DC: Reach DC-101 Service

这里避免了一个问题：内部非 HTTP 服务不需要绕公网入口，也不需要把所有协议都塞进 HTTP Gateway。

更核心的是安全域边界。公网只暴露 HTTP 服务，非 HTTP 内部服务留在 LAN / WireGuard 里。这样技术同事日常开发测试能访问到需要的资源，但这些协议不直接面向公网。

第二类是运营同事访问 SMB LAN IP Windows 共享。

这个需求很典型，也很现实。最早大家在一起办公，Windows 共享就是 LAN 内工具路径。后面办公室搬迁分开，人的工作习惯没有跟着网络拓扑一起重做。用 WireGuard 把 Office-JT 和 Office-SQ 的 LAN 连起来，可以让这条协作路径继续存在。

它不是一个完美的现代协作平台，但迁移成本低，用户习惯稳定。

第三类是部分管理流量。

RouterOS、PVE、Switch、WRT 都有自己的管理入口。日常管理不应该只依赖公网入口或个人 Overlay。站点 RouterOS 之间的 WireGuard 让一些基础管理路径留在内部网络里。

为什么不是 NetBird

NetBird 在我的网络里很重要，但它解决的是另一类问题。

它更适合：

  • Mobile Devices / MacBook 从外部访问管理网络
  • Admin 设备按 ACL 访问 Homelab / Hometown / Office 资源
  • WRT Peer 作为额外管理入口
  • 在主路径出问题时保留第二条进入方式

但 Office-JT / Office-SQ / DC-101 的日常流量，不应该依赖 WRT 上的 NetBird Peer。

原因有几个：

  • WRT 是额外 Admin Layer，不是办公室主网关
  • 日常用户流量应该留在 RouterOS 主数据面
  • SMB 这类 LAN IP 访问更像站点互联，不像个人 Overlay
  • RouterOS 自带 WireGuard，少一层运行时依赖
  • 故障时更容易判断是 RouterOS Peer、Route 还是具体服务问题

这不是说 NetBird 不好，而是不要把不同用途的 Overlay 混成一层。

路由边界

WireGuard 路由边界需要明确。

Office-JT 的 LAN 是 192.168.8.0/21，Office-SQ 的管理地址在 192.168.2.101，DC-101 的管理地址是 172.16.2.101。站点之间通过 WireGuard 互通时，RouterOS 需要知道哪些网段应该走 Tunnel，哪些流量仍然交给 PCC 出 WAN。

这也是为什么 PCC 篇里强调：PCC 不是所有流量的第一答案。

内部站点流量应该先被识别成 LAN / WireGuard 目标，再进入对应 Site Route。否则访问 DC-101 的服务、访问 SMB LAN IP 共享，都可能被错误地当作普通公网访问处理。

日常路径大概是：

flowchart LR
  jtUser["Office-JT Users"]
  sqUser["Office-SQ Users"]
  jtROS["Office-JT RouterOS
192.168.8.1"]
  sqROS["Office-SQ RouterOS
192.168.2.101"]
  dcROS["DC-101 RouterOS
172.16.2.101"]
  smb["SMB Windows Shares
LAN IP Access"]
  dcSvc["DC-101 Non-HTTP Services"]

  jtUser --> jtROS
  sqUser --> sqROS
  jtROS <-->|WireGuard Site Path| sqROS
  jtROS <-->|WireGuard Site Path| dcROS
  sqROS -->|WireGuard via Office-JT / Site Path| smb
  jtROS --> dcSvc
flowchart LR
  jtUser["Office-JT Users"]
  sqUser["Office-SQ Users"]
  jtROS["Office-JT RouterOS
192.168.8.1"]
  sqROS["Office-SQ RouterOS
192.168.2.101"]
  dcROS["DC-101 RouterOS
172.16.2.101"]
  smb["SMB Windows Shares
LAN IP Access"]
  dcSvc["DC-101 Non-HTTP Services"]

  jtUser --> jtROS
  sqUser --> sqROS
  jtROS <-->|WireGuard Site Path| sqROS
  jtROS <-->|WireGuard Site Path| dcROS
  sqROS -->|WireGuard via Office-JT / Site Path| smb
  jtROS --> dcSvc
flowchart LR
  jtUser["Office-JT Users"]
  sqUser["Office-SQ Users"]
  jtROS["Office-JT RouterOS
192.168.8.1"]
  sqROS["Office-SQ RouterOS
192.168.2.101"]
  dcROS["DC-101 RouterOS
172.16.2.101"]
  smb["SMB Windows Shares
LAN IP Access"]
  dcSvc["DC-101 Non-HTTP Services"]

  jtUser --> jtROS
  sqUser --> sqROS
  jtROS <-->|WireGuard Site Path| sqROS
  jtROS <-->|WireGuard Site Path| dcROS
  sqROS -->|WireGuard via Office-JT / Site Path| smb
  jtROS --> dcSvc

图里故意没有画真实服务名、真实域名或公网地址。公开文章只需要说明路径和边界，不需要泄露入口细节。

可恢复性

WireGuard 是日常路径，所以它不能只靠“配置好了应该会通”。

Office-JT 和 Office-SQ 侧都有 Watchdog 思路：通过 Netwatch 观察 Peer 可达性，如果 Peer 被判定 Down，就重启对应 WireGuard Peer。

这个动作很小：

  • 不重写整套配置
  • 不改动 Route
  • 不切换到 WRT Overlay
  • 只对当前 Peer 做 Disable / Enable

它解决的是 RouterOS WireGuard Peer 偶发卡住、Endpoint 状态异常这类小故障。

这也符合小型网络的维护方式：不要一上来做复杂控制系统，先把最常见的可恢复动作固化下来。

这个方案的取舍

WireGuard 作为日常路径也有成本。

它默认更偏站点级互信，不像 NetBird ACL 那样天然适合按个人设备、用户、Peer 细分权限。对于一个相对宽松的小型互联网公司，这个成本目前可以接受；如果未来真的需要部门级隔离、审计和细粒度访问控制，就不能只靠现在这套 LAN 互通模型。

另一个成本是内部路径会延续历史包袱。

比如 SMB LAN IP Windows 共享。它能快速延续协作路径，但它不是最现代、最云化、最易审计的方式。这里选择它，是因为它符合当前人的工作流，而不是因为它是所有场景的最优解。

所以这篇不是在说“办公室跨站都应该直接 WireGuard 打通 LAN”，而是在说：对这个规模、这几个站点、这些日常需求来说，RouterOS WireGuard 是更合适的主路径。

最后的结论

WireGuard 在小型网络系列里的定位，是办公室站点之间的日常路径。

它承载的是：

  • Office-JT / Office-SQ 的日常站点互联
  • 运营同事访问 SMB LAN IP Windows 共享
  • 技术同事访问 DC-101 非 HTTP 开发测试服务
  • 公共 DNS 返回 LAN / Internal Address 后的访问路径
  • 一部分 RouterOS 管理和恢复动作

NetBird / ZeroTier / WRT Peer 仍然存在，但它们更像 Admin Overlay 和 Backup Path。

后面写脚本、Scheduler 和可恢复性。日常路径确定之后，真正重要的是让这些 RouterOS 状态不要只靠手工记忆。

更新于 2026-05-29 
CC BY-NC-SA 4.0
运维网络RouterOS
返回 | 主页

目录