居然花了一晚上和一整天的时间来配置这个，真的是大出所料，在最浅显的地方栽了最大的跟头

因为之前配置的时候都太痛快了，5分钟，然后放路由，就ok了，结果这次就结结实实翻车了！

先说最大的原因：墙，无视墙的存在，必然被墙反噬，本来简单的事情也变得复杂。

注意事项，普通配其实很简单，但是出乎意料的还有MTU等着你，因为VPS被强制改了MTU，所以这里还有一个坑，普通的不会遇到这个情况。

记录一下过程：

首先，OPNSense老版本的需要安装插件os-wireguard，但新版本已经内置wireguard了，完全不用安装

左边栏看一下，有就OK，不用安装

image-20251217140635467

然后我们先去WireGuard的Instances，初始是空白的，那就按+号添加一个新的实例

image-20251217140952967

需要填写以下几项

image-20251217141111022

  • Name：WG-LC

  • Instance是0，表示这个实例会是wg0这个网卡

  • 按齿轮Gen出sever的 Public key和Private key

  • LIsten port：51821 采用非标端口，是UDP类型的端口

  • Tunnel address：表明wg0网卡所在的网段，10.100.100.1是服务器的地址

    然后填完点击Save就OK了

    返回后，选中Enable WireGuard，然后Apply，就会启动服务了。

    image-20251217141311489

接着去gen客户端配置：

image-20251217141608725

到 Peer generator，填入以下内容

  • Name：客户端名称，起个ZRR，好认
  • Address：会自动按序列生成，这里是10.100.100.2/32
  • Allowed IPs：这里非常关键，一定不能填0.0.0.0，那相当于所有路由都走这个wg隧道了，所以一定要指定自己要走的路由，首先是wg0的网段10.100.100.0/24，然后是内网的192.168.99.0/24
  • 然后一定要把Config的配置给拷贝出来备用
  • 最后点击 Store and generate nexe的按钮，不要点Apply那个

然后就OK了，回到 Peers 页看看，多了一个ZRR的对端，就没问题

image-20251217142110721

继续，需要配置接口和防火墙规则

左边栏，Interfaces –> Assignments

image-20251217142807893

会多出一个interface，wg0的，Description写大写的WG0，必须是这个，不要起其它的名字，WG0 –> wg0相呼应对照，不要乱写

点击Add

image-20251217142908316

会变成三个并排，如果加多个实例，就WG1、WG2这么排下去，一目了然

image-20251217143151970

接着去WG0的interfaces

image-20251217143824101

选中：

  • Enable 激活这个interface
  • Lock 阻止这个interface被误删
  • 其它都保持缺省

image-20251217144020653

然后点击Save，然后Apply changes，让配置生效，就可以了

去Firewall，Rules, WG0，会看到有13条继承的规则，我们新加一条

image-20251217144326205

新加入的规则，Source选择WG0 net，这样10.100.100.0/24会被带入，其它保持缺省，Save即可

image-20251217144449895

那会看到多了一条规则

image-20251217144641182

然后我们来看看Rules还有一个WireGuard(Group)

image-20251217144718915

点开看，里面只有继承的规则，而且写了这里面没有规则，那么所有进入的连接都会被拒绝，直到里面添加了规则

image-20251217144812007

这玩意是干什么用的呢？

成组配置，比如说你有WG0、WG1、WG2、WG3若干个实例，那么相同的防火墙规则可以放入这个Group规则中，就不用配多次了

生成最终配置的时候，组配置优先，然后是实例自己的单独配置，组合起来合成最终的配置，所以虽然组缺省是block策略，最后合起来就不是block了

我们这个不管，不配。

然后到Rules，WAN我们需要放行防火墙

image-20251217145258252

添加一条规则：

image-20251217145531222

image-20251217145626067

image-20251217150003603

填入以下几项：

  • Protocol：UDP
  • Destination：WAN address 这个如果你WAN口有多个地址，那就随便哪个都能连接上
  • Destination port range：51821
  • Description：Allow wireguard in 这个可以不填，填上是为了分清楚51821是谁开的

然后Save、Apply即可。

这样通常就ok了，我们这里有个超常情况，那就是MTU，如果以上步骤，客户端填入之前拷贝的配置能用，就完结了

不用看以下内容。

我们还不行，因为机房改了MTU，所以必须适配

image-20251217150623262

我们需要加一条，MTU=1420才可以

为啥呢？MTU正常是1500。

1420 字节的 MTU 是 WireGuard 隧道上一个非常常见的推荐值，因为它能确保原始 1500 字节的 IP 包在经过 WireGuard 的 80 字节加密和头部封装后，不会在传输层（如通过 1500 MTU 的以太网）发生分片（Fragmentation）。

完结了，完全没有预料到墙是禁止墙内直连墙外的wg服务器的，握手阶段就直接进行了打断。所以换了三台服务器还是不行，严重怀疑OPNSense配置错乱，之前配Nginx stream就是这样，然后想清理配置，最后的最后是找了一台新加披的服务器，一测就通了！

于是，遥远的东方，墙遥遥领先。