JerryYuan

建议还是研究下 IPv6 公网地址，直连的带宽和延迟不是转发能比拟的(可以多配置一条转发的路由备用)

回到题主的问题，所谓的 A 网络主机访问 B 网络主机实际包含两步，A 网络主机请求 B 网络主机，B 网络主机处理请求响应 A 网络主机(这一层很容易被忽视)

所以按题主配置，ping 包传输的整个链路应该是:

去程:
* A 网络主机→A 路由器 LAN(ICMP Request)
* A 路由器 LAN→A 路由器 WG0(ICMP Request)
* A 路由器 WAN→中转节点 WAN(wg 协议)
* 中转节点 WG0→中转节点 WG0(ICMP Request ，中转节点 wg0 也许能抓到，抓不到跳过也行)
* 中转节点 WAN→B 路由器 WAN(wg 协议)
* B 路由器 WG0→B 路由器 br-lan(ICMP Request)
* B 路由器 br-lan→B 网络主机(ICMP Request)

回程:
* B 网络主机→B 路由器 br-lan(ICMP Echo)
* B 路由器 br-lan→B 路由器 wg0(ICMP Echo)
* B 路由器 WAN→中转节点 WAN(WG 协议)
* 中转节点 wg0→中转节点 wg0(ICMP Echo)
* 中转节点 WAN→A 路由器 WAN(wg 协议)
* A 路由器 WG0→A 路由器 br-lan(ICMP Echo)
* A 路由器 br-lan→A 主机(ICMP Echo)

捋清楚完整的预期数据通路以后，就可以分段配置每一台设备，让数据包按预期流转。
这里引入一个调试技巧，即在整体不通时，在每一段两端的网络适配器抓包看看数据包走到哪一步就迷路了，找到迷路的那一步，对照发送的一侧适配器所在主机的路由表看看实际走到哪条路由上去了，一般修正这个路由表配置，数据包就能继续往前走了。所有链路都抓包确认成功以后，网络应该也就通了。

类似的场景，我是 docker 会解析 v6 导致不走梯子，加了个 AdGuardHome ，把 v6 解析过滤掉，明显就稳定多了。。。

@JerryYuan 当然自己学一下焊接还是性价比最高的

找个修手机的，给 50 块钱焊一个不包好坏的插座，看丝印应该是有对应的元件但是厂家没有出料。

创建索引应该简单写个 python 脚本，一律转成纯文本，丢进去分词做倒排索引就行了。目测是 chatgpt 能接受的强度

elasticsearch 最初就是程序员给老婆做的菜单检索引擎，也是稀碎的文件一大堆😄

@TashinV 从 openwrt 里边拷出来改下就行，里边有几个依赖 luci 配置的东西，可以改成用 wg-quick 啥的去操作。脚本本身已经够用了，没必要自己搓一个了。(如果 unifi 里边和 Linux 的逻辑一致的话)

@JerryYuan 恢复连接需要通过 ddns 拿到更新后的节点地址，并更新到 wg 的 peer 配置上去，这也是 openwrt 里边那个 wireguard_watchdog.sh 在做的事情。

@TashinV 需要跑，persistentKeepalive 那个是维持'链接'用的，相当于定时互相 ping 一下
wireguard 有个特性，就是只会在建立连接时解析域名，完成解析以后会缓存地址直到重启才会重新解析。
维持链接并不能保证地址不会变，地址一旦变了，keepalive 只会变成无响应，并不能恢复"链接