之前用 cronicle ，优点是可以通过插件扩展出很多种执行器，缺点是连 docker 官方都没支持，得自己写插件实现 nodejs 调用 docker ，之前也自己搓出来了这个插件。

直到某天误操作 rm -rf 了(操作效果类似，但不是 rm -rf)，懒得重新研究文档写插件了，发现了一个新的异步任务调度工具 Dagu

Dagu 本质上是一个 DAG 工具，即有向无环图调度工具，因为是 golang 搓的，它原生支持 docker 所有参数，用 yaml 定义 DAG ，然后逐个节点执行。缺点嘛，就是这东西轻量到可以称之为简陋，没有汉化，甚至没有一个 icon ，执行器方面你得把代码打包成服务(走 HTTP 触发器)或者 docker 镜像它才能调用(或者在 yaml 里搓 shell 脚本)，前者内存常驻和 cronicle 其实无差了，后者还得自建 docker registry ，当然我的话是有搭建 gitea ，它本身带一个简化的软件包管理，支持 docker 镜像托管，搭配上 gitea action 自动构建镜像，用 dagu 去自动拉镜像执行还是挺舒适的。

Dagu 项目地址:https://github.com/dagu-org/dagu

PS:打到这，其实如果有 gitea 了，搭一个 gitea action 让它定时执行也不是不行哈。

@Puteulanus 卧槽亮瞎我狗眼

层主可能需要的是一个 pastebin 。纯静态站点想不太出来输入的数据怎么留到下一次访问，既然客户端重启就重置，那么 localstorage 这种浏览器内的本地存储大概也会被重置，想留下数据就只能靠后端，但是这又是个静态页面，没有后端。还是说层主只需要一个页面，在单次开机周期内能留下数据就行。

pastebin 的话就是专门给你个地方去保存剪贴板里无处安放的数据，因为功能很简单，就算有后端也很轻量，可以考虑在路由器上部署。

另外还有个骚路数，就是让 ai 给你写个 luci 插件，实现一个文本框，里边能保存一些数据，然后数据直接用 openwrt 那个配置管理 uci 存或者/tmp 下或者哪的开个文件存。认证就靠 op 的登录，配一个强密码，主打一个数据和路由器配置共存亡。

@JerryYuan 用这点性能损耗换快照这些功能还是很值的。

@YsHaNg 现在的虚拟机都是靠专门的虚拟化指令集实现的了，效率已经接近 99%了，损耗几乎可以忽略不计了。现在云厂商，再加个最基础的芯片去做虚拟化控制器，甚至都能做出 100%效率的虚拟机了。

建议选一个 pve 或者 esxi 这种，没啥可折腾的虚拟化系统做整个家庭私有云服务的底座，折腾的越少越稳定。同时虚拟化平台还可以提供快照这一粒重要的后悔药。

然后包括 NAS ，还有计算节点都在其上另开虚拟机。磁盘啥的可以直通进虚拟机，部署 NAS 系统可以和物理机一样的。

目前我就是 PVE 做底座，其上部署黑群(存储)+OpenWRT(网络)+Ubuntu(计算)，完全按括号里的拆分，群晖负责一切和存储/备份有关的操作，Ubuntu 负责一切数据处理工作，OpenWRT 负责一切和网络相关的工作。Ubuntu 挂载群晖的 NFS 卷作为 Docker 的持久化卷(Volume)，Openwrt 完成异地组网，VPN 一键回城。

建议还是研究下 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 只会变成无响应，并不能恢复"链接

1.具体要看路由怎么配置的，要确保双向通信的数据包不会走到意外的地方，基本就能通，和节点公网地址变不变没啥关系
2.ddns 脚本建议两边都跑，自动维护两个不同的(二级)域名，有助于增强网络链接的健壮性。一端的解析挂了还能靠另一端拉起来。

所以我选择 VPN 连接，用 VPN 内网地址去登录云服务器。为了给 VPN 备份，主机开放 22 端口，但云服务器的安全组规则会直接封掉 22 端口，一旦 VPN 失效，去控制台临时放行一下 22 端口依然可以正常访问，不会被关在门外。

snippaste 可以复制图片然后 F3 直接贴图的，然后就可以编辑了，编辑完右键复制原图尺寸或者保存图片就可以实现基本不丢失清晰度。就是裁剪似乎只能通过重新截图来实现，不太优雅

@pUC9tNrr 感觉问题不大，散热器体积不小的