Ubuntu WireGuard 安全加固：AllowedIPs、防火墙、DNS 泄漏与密钥轮换
WireGuard 能连通不等于配置安全。本文从 AllowedIPs、防火墙、DNS、密钥权限、PersistentKeepalive 和故障排查入手，给出 Ubuntu WireGuard 上线后的安全检查清单。
Jacky Wang
4 分钟阅读
AllowedIPs 同时影响路由与访问判断
Ubuntu 官方文档强调，AllowedIPs 在发送方向作为路由选择，在接收方向也用于判断某个 Peer 是否可以声称相应的源地址。
这意味着它不只是“哪些流量走 VPN”的便捷配置。把客户端设为 0.0.0.0/0 会尝试把所有 IPv4 流量送入隧道；给服务端 Peer 配置过宽的网段，也可能让对方获得超出预期的路由范围。
最小权限做法是：
- 远程维护单台服务器时，只声明所需的隧道地址或内部网段；
- 只有在明确需要全局出口 VPN 时，才使用默认路由；
- 多 Peer 配置中避免网段重叠；
- 修改后同时检查
wg show、ip route和实际可访问资源。
VPN 流量是双向的，必须配合防火墙
Ubuntu 的安全提示指出：接入远端网络后，远端设备也可能反向连接你的设备，除非防火墙明确阻止。 因此，不要把“来自 wg0”直接等同于“完全可信”。可以为 VPN 客户端使用独立网段，并用 nftables 或 ufw 只开放必要端口。例如，开发人员可能只需要访问 SSH、内部 Git 和监控服务，而不需要扫描整个内网。 服务端还应区分三类规则：WireGuard UDP 监听端口、从wg0 进入本机的流量，以及经服务器转发到其他网段的流量。能完成握手却无法访问内网，常常不是 WireGuard 加密失败，而是转发或防火墙规则缺失。
全隧道配置还要处理 DNS 泄漏
当AllowedIPs = 0.0.0.0/0 时，目标通常是让所有互联网流量经过 VPN。但如果 DNS 查询仍发给本地网络提供的解析器，访问的域名可能继续暴露。
Ubuntu 的默认网关示例使用 resolvectl 把指定 DNS 服务器和默认 DNS 域绑定到 WireGuard 接口。上线前应分别验证公网出口 IP、DNS 解析器和 IPv6 行为。如果你只配置了 IPv4 全隧道，却保留可直出的 IPv6，仍可能出现绕过预期路径的流量。
私钥权限与轮换流程
WireGuard 私钥应像 SSH 私钥一样处理。官方 Quick Start 在生成密钥前使用umask 077，目的是避免文件被其他本地用户读取。
生产环境还需要一套可执行的轮换流程：
- 为每个设备生成独立密钥，不共享一个客户端私钥；
- 记录公钥与设备的对应关系，而不是保存明文私钥副本；
- 设备丢失时，从所有相关 Peer 配置中删除其公钥；
- 新旧密钥短暂并存，验证新连接后再撤销旧密钥；
- 检查配置文件权限、备份位置和自动化日志是否泄露私钥。
PreSharedKey。它为指定 Peer 额外增加一层对称密钥保护，但也带来另一项需要安全分发和轮换的秘密。是否使用应由威胁模型决定，而不是把它当成默认勾选项。
PersistentKeepalive 只在需要时开启
处于 NAT 或状态防火墙后的 Peer，可能需要定期发送保活包，才能继续接收外部发来的流量。WireGuard Quick Start 给出的常见间隔是 25 秒，同时明确建议：不需要时不要开启。 它不是连接健康检查，也不会修复错误的路由、密钥或防火墙。盲目启用只会增加不必要流量，并掩盖真正的网络问题。一套上线后检查清单
每次新增 Peer 或调整网段后，至少完成以下验证：wg show是否出现近期握手与双向传输；ip addr与ip route是否符合预期；AllowedIPs是否为最小必要范围且没有重叠；- 未授权端口是否被防火墙阻止；
- 需要转发时，
ip_forward是否启用并持久化； - 全隧道场景下，公网 IP、DNS 和 IPv6 是否都走预期路径；
- 客户端私钥是否唯一、文件权限是否足够严格；
- 服务重启和系统重启后，
wg-quick@wg0是否正常恢复； - 日志和监控是否只记录必要元数据，没有输出私钥。
AllowedIPs、接口地址、路由、IP 转发和代理 ARP。watch wg 可以帮助观察握手与字节变化，但它只能告诉你隧道状态，不能代替端到端的权限测试。
结论
WireGuard 的安全优势来自精简协议和现代密码学，但安全边界最终由AllowedIPs、路由、防火墙、DNS 与密钥运维共同决定。正确的上线标准不是“手机能连上”，而是只有授权流量能够通过，而且设备丢失、密钥轮换和服务器重启都有清晰的处理路径。