WireGuard 实战：用极简 VPN 打造安全的点对点隧道

WireGuard 是当下最值得上手的现代 VPN 方案：用极少的代码量实现安全的点对点隧道，配置比 OpenVPN/IPSec 简单一个数量级，性能却高出数倍。本文从密钥体系、两端互联实战，到跨云内网组网与安全加固，手把手带你把 WireGuard 用在生产环境。

一、为什么选 WireGuard

传统 VPN 要么配置繁琐（IPSec 的一堆参数），要么性能拉胯（OpenVPN 单线程用户态）。WireGuard 反其道而行：整个协议实现只有约 4000 行代码，内核态运行，握手即用 Noise 协议框架，默认只开放 UDP 端口、无陈旧加密套件。它特别适合做服务器点对点互联、跨云内网打通、以及远程开发机访问内网服务。

二、核心概念：先搞懂三个东西

WireGuard 的模型极其简单，理解下面三点就够了：

• 密钥对：每个节点各自持有一对 Curve25519 私钥/公钥，私钥绝不出本机。
• Peer（对端）：你在配置里声明”要和谁通信”，写入对方公钥、端点地址和 AllowedIPs。
• AllowedIPs：决定”哪些目标 IP 的流量走这条隧道”，既可以做点对点，也可以做全流量出口。

三、点对点实战：让两台服务器直接互联

3.1 在两台机器上各自生成密钥

假设有服务器 A（公网 203.0.113.10）和服务器 B（公网 198.51.100.20），内网地址分别规划为 10.0.0.1 和 10.0.0.2。

# 在两台机器上都执行：生成私钥并推导出公钥
umask 077
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey
cat /etc/wireguard/publickey  # 把对方的公钥抄下来备用

3.2 编写两端配置文件

服务器 A 的 /etc/wireguard/wg0.conf：

[Interface]
Address = 10.0.0.1/24
PrivateKey = <A 的私钥>
ListenPort = 51820

[Peer]
PublicKey = <B 的公钥>
Endpoint = 198.51.100.20:51820
AllowedIPs = 10.0.0.2/32
PersistentKeepalive = 25

服务器 B 镜像配置，仅交换地址与公钥：

[Interface]
Address = 10.0.0.2/24
PrivateKey = <B 的私钥>
ListenPort = 51820

[Peer]
PublicKey = <A 的公钥>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.0.0.1/32
PersistentKeepalive = 25

3.3 启动并验证

# 两端都执行
wg-quick up wg0
systemctl enable wg-quick@wg0   # 开机自启

# 查看隧道状态
wg show
# 从 A ping B 的内网地址
ping 10.0.0.2

如果 wg show 里对端出现 handshake 时间戳且能 ping 通，说明点对点隧道已经建立。若不通，优先检查两端防火墙是否放行了 UDP 51820（见下文安全小节）。

四、跨云内网组网：把分散的 ECS 拉进同一张网

在阿里云、腾讯云各有一台 ECS 时，用 WireGuard 可以把它们组进一个 10.0.0.0/24 虚拟内网，数据库、缓存等只监听内网地址即可，彻底避免公网暴露。每台机器除了自己的 [Interface]，再为每个对端加一个 [Peer] 段即可，AllowedIPs 填对端的内网 IP。这种”全互联（full mesh）”拓扑对 3–10 台节点非常顺手。

组好网后，内网服务想对外暴露可以叠加一层反向代理，例如用 Nginx 反向代理 把 10.0.0.x 上的 Web 服务安全地发布出去，既享受内网低延迟，又不破坏对外安全边界。

五、实际案例：远程开发机安全接入云上内网

把前面的点对点模型落到真实工作流里。最常见的需求是：你在家里或咖啡馆的笔记本，要直接访问云上那台只允许内网连接的 PostgreSQL 或 Redis。做法是把笔记本也配成一个 Peer，AllowedIPs 写成 10.0.0.0/24，这样所有发往内网的流量自动走隧道，而公网访问照常走原来的网关，互不影响。注意此时笔记本侧的 [Interface] 不需要 ListenPort（除非别人也要连你），只作为客户端拨入即可，配置比服务器端更短。

# 笔记本客户端 /etc/wireguard/wg0.conf
[Interface]
Address = 10.0.0.3/24
PrivateKey = <笔记本私钥>

[Peer]
PublicKey = <服务器 A 公钥>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25

另一个高频场景是多分支办公室互联：总部用一台有固定公网 IP 的节点作为”中心”，各分支机构配置 Endpoint 指向总部，AllowedIPs 各自填自己的内网段。比起拉专线或买商用 VPN 网关，这套方案零授权费用、配置可版本化进 Git（私钥除外），扩容时只需在中心和新增节点各加一段 [Peer]。当节点超过十台，建议改用 wg-easy 这类带 Web 管理的封装，或用脚本批量生成，避免手写配置出错。无论哪种规模，先把本文的”点对点两台服务器”跑通，再叠加更多 Peer 是最稳的演进路径。

六、安全加固：别让隧道变成后门

WireGuard 本身很安全，但部署不当仍会出事。几条铁律：

• 私钥权限：配置文件必须 chmod 600，私钥绝不上传仓库或截图外发。
• 防火墙最小化：只放行 WireGuard 的 UDP 端口，源 IP 可限定为对端公网地址。
• AllowedIPs 收窄：点对点场景只写对端单 IP（/32），避免误把全流量导进隧道。
• 持久化保活：一端在 NAT 后时，PersistentKeepalive 让隧道不被中间设备掐断。

# 用 ufw 只放行来自对端公网的 WireGuard 端口
ufw allow from 198.51.100.20 to any port 51820 proto udp
ufw enable

配合 服务器安全加固 的基线（SSH 密钥登录、fail2ban、内核参数调优），整张内网的抗风险能力会再上一个台阶。

七、监控与排障

WireGuard 默认很”安静”，没有流量时你看不到异常，因此可观测性要自己补。几个常用手段：

• wg show all dump：脚本化采集每个 Peer 的最新握手时间、收发字节数，超过阈值（如 3 分钟无握手）即告警。
• ICMP/端口探活：从监控机定时 ping 各节点内网地址，结合 Prometheus 做延迟与丢包面板。
• MTU 问题：跨云若出现大包卡顿，把 Interface 的 MTU 从默认 1420 调到 1380 通常能解。
• AllowedIPs 冲突：同一台机器多个 Peer 的 AllowedIPs 不能重叠，否则路由会打架。

八、生产落地检查清单

把这张清单纳入你的 GitHub Actions 部署校验，或在 Kubernetes 里用 wg-easy / 容器化方案统一管理，就能把”临时打通”升级成”可持续运维”的组网能力。

九、结语

WireGuard 用极简设计把”安全的点对点隧道”这件事做到了极致：几分钟配通两台服务器，几千行代码换来接近物理网卡的吞吐。无论是跨云内网、远程办公还是服务互联，它都值得作为 DevOps 工具箱里的常驻成员。先按本文跑通一台对端，再逐步铺开 full mesh，你会发现原来”组网”可以这么轻。