当你的业务分布在两个不同地域的机房，数据库主从复制、内部 API 调用、监控回传这些流量如果直接走公网，就会面临窃听与篡改风险。这篇文章将手把手教你如何在两台云服务器（通过虚拟化技术按需提供计算资源的远程服务器）之间，用 WireGuard 搭建一条站点到站点的加密隧道，让两端的内网 IP 可以像在同一个局域网里一样互相访问。整个部署只需要约 15 分钟，全程使用命令行完成，无需购买额外的网络设备。
为什么选择 WireGuard 而不是传统 VPN
在 WireGuard 出现之前，跨机房加密互通通常依赖 OpenVPN 或 IPsec。OpenVPN 基于 TLS（传输层安全协议）实现，用户态处理加解密，吞吐量常见在 200-400 Mbps 量级；IPsec 配置复杂，两端参数稍有出入就无法建立连接。WireGuard 的代码量只有约 4000 行（OpenVPN 超过 10 万行），直接运行在内核态，单核吞吐可以轻松跑满 1 Gbps 网卡，空闲时几乎不消耗 CPU。
除了性能，WireGuard 的运维模型也更简单：
- 配置极简：每个节点只需要一个私钥、一个端口和对端的公钥，双端配置文件加起来不到 20 行。
- 静默设计：没有合法数据包时不对探测做任何响应，端口扫描器无法判断服务是否存在，天然减少了暴露面。
- 无缝漫游：连接靠加密密钥识别而不是固定 IP，一端重启网络或更换出口 IP 后，流量会自动恢复，不需要人工重连。
- 内核级性能：加解密在内核完成，延迟比用户态方案低，适合数据库复制这类对延迟敏感的流量。
如果你的两台服务器一台是 VPS（虚拟专用服务器）、另一台是独立服务器（租用整台物理硬件的服务器），只要系统内核版本在 3.10 以上（CentOS 7 需要先安装 elrepo 内核模块），都可以使用同一套流程。想要先了解不同主机形态的差异，可以参考我们之前整理的服务器栏目的系列文章。
部署前的网络规划
站点到站点组网最关键的不是敲命令，而是先规划好地址，避免和两端的现有内网冲突。假设服务器 A 位于美国机房，公网 IP 为 203.0.113.10；服务器 B 位于香港机房，公网 IP 为 198.51.100.20。我们为隧道预留一个 /24 网段 10.100.0.0/24：A 使用 10.100.0.1，B 使用 10.100.0.2。端点机建议选择两地延迟较低的组合，可以按地域在 VPS（虚拟专用服务器）主机页面挑选节点。
规划时需要确认三件事：第一，10.100.0.0/24 不能与 A、B 两端已有的 Docker、Kubernetes 或局域网网段重叠，否则路由会冲突；第二，双方需要各自在防火墙放行一个 UDP 端口（本文使用 51820），云平台的安全组同样要开放；第三，记录下两端需要通过隧道互访的内网网段，例如 B 端还有一个 172.16.30.0/24 的业务内网，后面写路由时会用到。
安装 WireGuard 并生成密钥
两台服务器执行相同的安装步骤。Ubuntu/Debian 系统运行：
apt update && apt install -y wireguard
CentOS/RHEL/AlmaLinux 系统运行：
yum install -y epel-release elrepo-release yum install -y kmod-wireguard wireguard-tools
接着在每台服务器上分别生成一对密钥。以 A 为例：
wg genkey | tee /etc/wireguard/privatekey | wg pubkey > /etc/wireguard/publickey chmod 600 /etc/wireguard/privatekey cat /etc/wireguard/privatekey /etc/wireguard/publickey
B 端重复同样的命令。最后你会得到 4 个文件内容：A 的私钥、A 的公钥、B 的私钥、B 的公钥。私钥永远只留在本机，配置对端时只需要粘贴对方的公钥。
编写双端配置文件
在 A 端创建 /etc/wireguard/wg0.conf：
[Interface] PrivateKey = A的私钥 Address = 10.100.0.1/24 ListenPort = 51820 [Peer] PublicKey = B的公钥 AllowedIPs = 10.100.0.2/32, 172.16.30.0/24 PersistentKeepalive = 25
在 B 端创建同样的文件，但内容对调：
[Interface] PrivateKey = B的私钥 Address = 10.100.0.2/24 ListenPort = 51820 [Peer] PublicKey = A的公钥 AllowedIPs = 10.100.0.1/32 PersistentKeepalive = 25
这里有两个参数直接决定隧道能否通：AllowedIPs 同时承担”路由表”和”访问控制”两种角色，A 端写入 172.16.30.0/24 后，发往该网段的流量才会进入隧道；PersistentKeepalive = 25 让节点每 25 秒发送一次保活包，这对位于 NAT（网络地址转换）后面的服务器尤其重要，否则 NAT 映射过期后连接会静默中断。
启动隧道并验证连通性
双端分别启动接口并设置开机自启：
wg-quick up wg0 systemctl enable wg-quick@wg0
在 A 端执行 ping 10.100.0.2，如果返回 64 bytes 应答，说明隧道已经打通。再用 wg show 查看握手状态，输出中的 latest handshake 时间戳应小于 2 分钟，transfer 计数会随流量增长。进一步验证路由效果，可以在 A 端 ping B 侧业务内网的某个地址（例如 172.16.30.8），能通就代表站点到站点转发已经生效。
如果握手一直不出现，按以下顺序排查通常能解决大部分问题：
- 云平台安全组和本机防火墙是否都放行了 UDP 51820，这是最高频的故障原因。
- 双端 AllowedIPs 是否互相包含对方的隧道 IP，写错一个数字就会导致单向通。
- MTU 问题：部分云环境外层封装会吃掉字节，把 Interface 段的 MTU 设为 1420 通常可以解决”能 ping 通但大文件传输卡住”的现象。
- 时间同步：握手校验依赖时间窗，时钟偏差过大的机器先装 chronyd 或 ntpdate 校准。
把隧道纳入日常运维
隧道跑起来之后，建议把它当作基础设施的一部分来管理。首先是备份：/etc/wireguard/ 目录下的私钥和配置文件应纳入加密备份流程，私钥一旦丢失只能全量换钥。其次是监控：可以用简单的 cron 脚本每分钟执行 wg show wg0 latest-handshakes，超过 180 秒就触发告警，这比等业务方报障快得多。最后是升级：WireGuard 的握手密钥每 2 分钟左右自动协商轮换，无需人工干预，但内核模块建议跟随发行版安全更新保持最新。
跨机房的加密通道只是网络优化的第一步。如果隧道承载的是网站业务，后续还可以配合TTFB 首字节优化进一步压缩访问延迟；如果节点上跑的是 WordPress，WordPress 运维专栏里有数据库远程复制与缓存配置的完整做法。
总结
WireGuard 用不到 20 行配置就把两台云服务器（通过虚拟化技术按需提供计算资源的远程服务器）连成了一张加密内网：内核态转发保证了吞吐，密钥轮换免去了证书维护，AllowedIPs 一行就完成了路由收敛。我们的建议是先在测试网段跑通全流程，确认握手与转发稳定后再切换生产流量；如果你的业务需要多个机房互联或与独立服务器（租用整台物理硬件的服务器）混布，可以考虑把其中一台升级为枢纽节点，其余站点以星形拓扑接入，管理成本会显著低于两两互联。Hostease 的 VPS（虚拟专用服务器）与独立服务器机型覆盖多个地域，可以作为隧道端点的候选。部署过程中遇到握手失败或 MTU 异常，按文中排查顺序逐项检查，基本都能在几分钟内定位。