OPNsense WireGuard 站点互联：双端隧道、规则与 MTU

原文：OPNsense 项目 / Deciso 官方文档，WireGuard Site-to-Site Setup；源页未列个人作者。中文翻译与整理：未完纪。全文核对日期：2026-10-05。本篇是配置教程，未在实际防火墙上部署或测试。

WireGuard 使用公钥与私钥建立 VPN，配置方式比传统 IPsec 更精简。下面按照官方示例，把两个站点中不同的 LAN 网段连在一起。原文的前提是两台 OPNsense 的 WAN 都有公网 IPv4 地址；如果环境涉及运营商 NAT、动态地址、IPv6 或高可用，还需要应用后文的附加条件。

地址规划与安装

两个 LAN 与传输网应有清晰、不重叠的地址规划。按原文，在 System → Firmware → Plugins 安装 os-wireguard，刷新管理界面后进入 VPN → WireGuard。插件提供方式与菜单会随 OPNsense 版本变化；本篇核查的是当前文档页面，并未锁定某个安装镜像或插件版本。

编辑补充：操作会改变路由与防火墙通行范围，先保存配置备份并保留本地控制台或其他恢复入口。教程不是批量修改生产防火墙的脚本。

建立两端 WireGuard 实例

进入 Instances，点击加号并打开高级模式。分别填入下表；两端各自点击 Generate new keypair 生成密钥对，保存并应用。

MTU 示例值必须结合实际 WAN 与路径 MTU 检查，不能保证适合叠加其他隧道的网络。在 HA 环境中，原文要求每个实例设置 Depend on (CARP)，使 WireGuard 与 CARP 状态配合。

把对端登记为 Peer

在 Peers 页面点击加号，启用高级模式，按下表分别建立远端记录：

保存并应用后，回到 A 实例，把 Peers 设为 wgopn-site-b；回到 B 实例，把 Peers 设为 wgopn-site-a，再次保存并应用。Allowed IPs 包含对端隧道的单个地址和远端 LAN；不要随意改成 0.0.0.0/0，否则会改变路由与地址允许范围。它也不能替代后面的防火墙访问规则。

Shared Secret 留空表示原例不额外配置预共享密钥，不表示省略公钥认证。若启用额外预共享密钥，应以安全方式配置同一个值到两端，不能把私钥、预共享密钥放进文章、截图或工单。本文没有真实密钥。

动态公网地址、域名与 NAT 的附加条件

如果只有一个站点的 WAN 地址动态变化，可以在具有静态地址的那一端把 Endpoint Address 留空，让动态地址一端主动发起连接，静态地址一端响应。静态地址端的 WAN 规则也需接受来源地址变化；原文建议允许任意来源 IP 到该 WireGuard UDP 端口，实际部署应结合可行的源范围限制与网络策略审视这个扩大范围。

使用主机名作为 Endpoint 时，原文说明 WireGuard 在隧道启动时解析一次。若两端都用 DynDNS，地址租约变化后连接可能停止。可在 System → Settings → Cron 中设置定期任务，选择 Renew DNS for WireGuard on stale connections，更新失效连接的 DNS 结果。本文没有创建或运行此任务。

站点位于 NAT 后方时，在 NAT 后的那一端设置 keepalive。原文给出的间隔是 25 秒，用于在空闲时维持 UDP 映射；这是与网络拓扑相关的配置，不需要给所有直连公网场景无条件添加。

允许外层 WireGuard 流量

到每端的 Firewall → Rules → WAN 添加入站规则，保存并应用。两条规则均为 Pass、WAN、In、IPv4、UDP，目的端口均为 51820：

这里放行的是 WireGuard 的外层 UDP 数据报，还没有授权隧道中的 LAN 主机相互访问。

配置 MSS 归一化

两端都进入 Firewall → Settings → Normalization 新建规则。原例选择接口 WireGuard (Group)，Direction、Protocol、Source、Destination 与 Destination port 均为 Any；分别用 WireGuard MSS Clamping Site A 和 Site B 作为描述。

Max mss 按 WireGuard MTU 计算：IPv4 TCP 至少减去 40 字节，因此 MTU 为 1420 时用 1380 或更小；PPPoE 例中 MTU 为 1412 时，相应上限为 1372。IPv6 TCP 则至少减去 60 字节。后者算式是对原文规则的明确展开。

原文提醒，不配置这一部分时可能出现 ICMP、UDP 正常，但部分加密 TCP 会话无法工作的情况。MSS 调整针对 TCP 段大小，不会替你解决所有 UDP 大包或路径 MTU 问题，也不是仅凭“ping 能通”就能省略的检查。

启用隧道并查看握手

两端进入 VPN → WireGuard → Settings，启用 WireGuard 并应用，然后查看 VPN → WireGuard → Diagnostics。按原文预期，第一批流量经过之后，Send、Received 计数应有变化，Handshake 应出现数值。

以上是部署后应检查的现象，不是本次已经得到的测试结果。握手建立只证明两端的 WireGuard 通信取得进展，仍需检查下一节的内层访问、回程路由和目标主机自身防火墙。

放行内层站点流量

原文最后给两个 LAN 完整互通权限。四条规则均为 Pass / In / IPv4，Protocol、Source port、Destination port 均为 Any：

每条保存并应用。原文 B 站点的导航句曾写成“LAN A”，但紧随的字段表明确标为 LAN B；本译稿按站点拓扑和字段表纠正这一处，不应在 B 站点误选 A 的接口。

生产配置应以业务需要缩小允许的源、目的主机及协议端口；上表完整互通是为了说明规则方向，不是最小权限模板。扩展额外网络时，要同时更新 Peer 的 Allowed IPs 和相应防火墙规则。扩展双栈时，按原文加入 IPv6 GUA 或 ULA 网段（常见前缀为 /64）并建立 IPv6 规则，同时检查前述 IPv6 MSS 条件。

验证与边界

部署者可在维护窗口验证两端握手、双向 LAN 流量、应用端口以及较大 TCP 传输，并核查只有预期地址能够通过。若只能单向访问，沿“本端 LAN 规则—隧道—远端 WireGuard 规则—目标主机—回程”逐段检查。后一条排查路径是编辑补充，不是声称原文已覆盖所有故障。

本次静态审查检查了双端地址、Peer 公钥方向、Allowed IPs、WAN 来源限制及 MSS 算式。没有运行命令、扫描地址、测吞吐或修改设备。没有发现示例中含有真实秘密；无法据此证明具体部署不存在漏洞。

来源与授权：OPNsense 官方原文，维护/发布方 OPNsense 项目 / Deciso。Copyright © 2016–2026, Deciso B.V.。原页未显示足以确认单篇文档/图片的开放许可证，未用项目代码许可证替代文档授权。图为未完纪原创技术示意，未删除原图署名。