JerryYuan

@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 最初就是程序员给老婆做的菜单检索引擎，也是稀碎的文件一大堆😄