WireGuard 的密钥生成与角色分配
WireGuard 基于非对称加密，每个端点通过生成私钥来计算对应的公钥。私钥必须严格保密，而公钥可以公开交换。在客户端与服务端配合生成公钥时，VPN客户端核心目标是让双方知晓彼此的身份标识。通常做法是客户端和服务端各自运行独立的密钥生成工具，导出各自的公钥文件。双方互不生成对方的密钥，而是通过安全通道或手动方式交换公钥，避免传输私钥带来的安全风险。
配置文件中的关键字段职责
在 WireGuard 配置文件中，公钥对应 PublicKey 字段。当服务端配置客户端时，需要在客户端条目中填入该客户端的公钥；同样，客户端配置中也需要填入服务端的公钥。此外，PersistentKeepalive（单数形式）参数用于在客户端处于 NAT 后维持连接活跃，防止连接被因无数据交互而中断。该参数应设在客户端侧，而非服务端。注意，UDP 与 TCP 即使使用相同端口号，也属于不同的监听端点，WireGuard 默认使用 UDP，因此配置中的 ListenPort 指的是 UDP 端口。
端点间的非对称密钥交换：公钥互换让信任从零开始。
验证连通性的只读检查方法
在不修改任何路由或网络设置的前提下，可执行只读验证。首先确认两端配置文件中 PublicKey 是否匹配：客户端配置里的服务端公钥应与服务端配置文件顶部 PublicKey 一致，反之亦然。其次，检查 AllowedIPs 配置。该字段不仅决定目的地址选择，还参与接收源地址校验。若配置为 0.0.0.0/0，意味着所有流量都通过隧道，但这并不自动保证局域网路由被正确处理；实际是否进入隧道还受客户端流量选择器和操作系统路由策略影响。分隧道模式下，部分流量可直连，因此不能简单认为配置了全零前缀就吞掉所有本地路由。
常见配置误区澄清
一个常见误解是认为 WireGuard 是中心化的服务器架构，实际上它是完全对等端的模型，每个节点都可以有自己的 ListenPort。另一个误区是将 AllowedIPs 简化为单纯的路由表项，忽略了其在入站流量验证中的作用。此外，有人误以为使用同一 UDP 端口即可在 TCP 和 UDP 间互转，但协议栈独立，监听端点不同，客户端必须明确指定使用 UDP 连接服务端。这些细节直接影响连接稳定性与流量路由行为，配置时需逐一核对。
