介绍分流场景整个通信过程，并重点叙述公钥/密钥以及 Tunnel IP Addresses 用在了哪个环节？

Gemini 总结 WireGuard

在分流场景下，整个通信过程就像是一场“多层加密的跨城速递”。为了清晰说明公钥/私钥和 Tunnel IP 的作用，我们将整个过程拆解为四个关键动作。

第一阶段：客户端发包 (加密与身份确认)

当你点击手机上的 NAS 链接时，手机内部发生了以下动作：

路由定向： 系统发现目的地 192.168.1.50 命中分流名单，于是将数据交给 WireGuard 接口。
构造内层包 (Inner Packet)：
- 源地址 (Source IP)： 填入 **Tunnel IP (10.0.0.2)**。这是你在 VPN 世界的身份证。
- 目的地址 (Dest IP)： 192.168.1.50。
密钥握手与加密： * WireGuard 使用客户端私钥 ($C_{priv}$) 和预存的服务端公钥 ($S_{pub}$) 进行椭圆曲线乘法（Diffie-Hellman），生成一个临时对称密钥。
- 使用这个对称密钥对内层包进行加密。
- 重点： 这一步确保了只有持有 $S_{priv}$ 的服务器能拆开这封信。

加密后的数据被包裹在一个普通的 UDP 包里，开始在互联网穿行。

构造外层包 (Outer Packet)：
- 外层源地址： 手机当前的 5G/Wi-Fi 公网 IP。
- 外层目的地址： 服务端的公网 Endpoint 地址。
Tunnel IP 的状态： 此时 Tunnel IP 被“深埋”在加密数据中，互联网上的任何路由器都看不见它。

这是 Tunnel IP 和公钥结合最紧密的环节。

解密校验：
- 服务端收到包，尝试用自己的 $S_{priv}$ 和预存的 $C_{pub}$ 生成相同的对称密钥进行解密。
- 解密成功 意味着发送者必然持有 $C_{priv}$。此时服务端确认了：对方的确是“手机”这个 Peer。
隧道 IP 审计 (AllowedIPs 检查)：
- 服务端拆开信封，露出 **Tunnel IP (10.0.0.2)**。
- 服务端查看自己的配置：“手机这个 Peer 的公钥，被允许使用 10.0.0.2 吗？”
- 如果 AllowedIPs 匹配成功，服务端才准许包进入家庭内网。这就是 Cryptokey Routing（加密路由机制）。

最后一段路： 服务端将包发给 NAS。NAS 看到的是来自 10.0.0.2 的请求。
回程响应： NAS 发出回信（目的地：10.0.0.2）。
隧道寻址： 服务端截获回信，在 Peer 列表中搜索 10.0.0.2 属于哪个公钥。发现属于 **$C_{pub}$**，于是反向重复加密流程，将回信送回手机。

元素	用在哪？	核心功能
私钥 (Private Key)	己方设备	用于证明“我是我”，并参与生成加密密钥。
公钥 (Public Key)	对方设备	作为“账号 ID”，用于解密确认对方身份。
Tunnel IP	内层数据包头	1. 告诉服务端解密后该找谁审计； 2. 告诉内网设备该回信给谁。
AllowedIPs	路由与审计表	1. 决定哪些流量入隧道； 2. 决定哪个公钥准许使用哪个 Tunnel IP。

你可以把 公钥/私钥 理解为 “数字签名章”，而 Tunnel IP 理解为 “内部工作证”。

整个分流过程中，你的“地面”物理流量（如刷视频）完全不涉及这些环节，只有去往“地下专用通道”的包才会触发这套机制。

你现在的 OpenWrt 防火墙区域（Zones）是否已经将 WireGuard 接口加入到了 LAN 区域或者做了单独的转发规则？