WireGuard 组网常被用来解决一个具体问题：多台云服务器分布在不同机房、不同业务区或不同账号下时，运维人员如何在不暴露管理端口的前提下，建立一条稳定、可审计、延迟可控的加密通道。本文是一份面向中小团队的实践指南，会帮助你判断什么时候适合做站点到站点连接、如何规划地址段、怎样配置双端节点，以及用哪些命令验证链路是否真的可用。
如果业务已经从单台服务器发展到“应用、数据库、备份、监控”分离部署，单纯依赖公网 SSH 白名单往往不够灵活。WireGuard 的价值在于把管理流量从公网业务入口中分离出来，让多台 VPS（虚拟专用服务器）或云服务器（弹性计算实例）通过 10.66.0.0/24 这样的私有网段互通，降低误开放端口、弱口令扫描和跨节点明文传输的风险。
先判断：哪些场景适合站点到站点组网
站点到站点组网不是“给每个人装一个客户端”的远程办公模型，而是让服务器节点之间长期保持私有互通。典型场景是：A 节点运行 Web 服务，B 节点运行数据库，C 节点做备份或监控，三者都在公网有业务入口，但数据库、备份和监控采集只应走私有通道。
在规划前，先把目标写清楚：哪些节点要互通，哪些端口只能在隧道内访问，是否需要某个节点转发更多子网。比如两台服务器之间只同步备份文件，可以只允许 10.66.0.2:22 到 10.66.0.3:22；如果有 4 台以上服务器，建议选一个中心节点做 hub，其他节点只和 hub 建立 peer，避免每台机器都维护 N×N 配置。关于服务器类型和运维场景的基础选择，也可以参考站内的 服务器配置与优化内容，先明确业务负载再决定网络模型。
配置前先规划地址、端口和密钥
开始写配置前，建议把网络规划整理成一张简表。以下示例使用 10.66.0.0/24 作为 WireGuard 内部网段，中心节点为 10.66.0.1，应用节点为 10.66.0.2，备份节点为 10.66.0.3。如果公司内部已经使用同一私网段，就换成没有冲突的地址，例如 10.88.0.0/24。
- 中心节点：公网 IP 固定，监听
51820/udp，WireGuard 地址为10.66.0.1/24。 - 应用节点：只连接中心节点，地址为
10.66.0.2/32，允许访问备份节点的22和监控端口。 - 备份节点：地址为
10.66.0.3/32，仅接受来自应用节点的同步流量。 - MTU（最大传输单元）：跨境或多运营商链路可先设为
1380，卡顿时再测试调整。
WireGuard 每个节点都有一对公私钥，私钥只保存在本机，公钥复制到对端配置。不要把私钥写进共享文档；生产环境建议每 6-12 个月轮换一次 peer 密钥，离职、权限变更或服务器交接时立即轮换。需要了解不同主机方案承载边界时，可以对照 VPS（虚拟专用服务器）主机方案 或 独立服务器（物理专用服务器）方案 的适用场景来规划节点职责。
双节点基础配置：先让一条隧道稳定跑起来
下面以中心节点 node-a 和应用节点 node-b 为例。两台服务器都先安装 WireGuard，并启用内核转发。Debian 或 Ubuntu 系统可使用以下命令；如果镜像较旧，先执行系统更新再安装，避免拿到过期内核模块。
apt update apt install -y wireguard sysctl -w net.ipv4.ip_forward=1 echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-wireguard-forward.conf
然后分别生成密钥。下面的命令在每台服务器各执行一次，不要在一台机器上生成后到处复制私钥。
umask 077 wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key cat /etc/wireguard/public.key
中心节点 /etc/wireguard/wg0.conf 可以这样写。AllowedIPs 同时影响路由匹配和 peer 身份边界；写成 0.0.0.0/0 会把默认流量导入隧道，站点到站点运维场景通常不需要这么做。
[Interface] Address = 10.66.0.1/24 ListenPort = 51820 PrivateKey = CENTER_PRIVATE_KEY MTU = 1380 [Peer] PublicKey = NODE_B_PUBLIC_KEY AllowedIPs = 10.66.0.2/32
应用节点配置则指定中心节点的公网地址和端口。PersistentKeepalive = 25 适合位于 NAT（网络地址转换）后面的节点，它会每 25 秒发送一次保活包，减少 UDP 映射过期导致的偶发断链。
[Interface] Address = 10.66.0.2/32 PrivateKey = NODE_B_PRIVATE_KEY MTU = 1380 [Peer] PublicKey = CENTER_PUBLIC_KEY Endpoint = CENTER_PUBLIC_IP:51820 AllowedIPs = 10.66.0.0/24 PersistentKeepalive = 25
配置保存后启动服务，并设置开机自启。先不要急着改业务服务监听地址，等基础链路确认稳定后，再逐步收紧公网规则。
systemctl enable --now wg-quick@wg0 wg show ip route | grep 10.66 ping -c 4 10.66.0.1
防火墙和服务绑定要同步调整
基础隧道能 ping 通，只说明 ICMP（网络控制消息协议）可达；真正的目标是让 SSH、备份、监控采集等管理流量只在 wg0 接口上流动。比如数据库应绑定到 10.66.0.3 或 127.0.0.1，而不是继续监听公网地址。
如果使用 ufw，中心节点至少需要允许 UDP 监听端口，并允许来自 WireGuard 网段的必要管理流量。下面只是一个起点，实际端口要按业务缩小范围，不要把 10.66.0.0/24 到所有端口全部放开。
ufw allow 51820/udp ufw allow from 10.66.0.0/24 to any port 22 proto tcp ufw allow from 10.66.0.0/24 to any port 9100 proto tcp ufw reload
如果直接使用 nftables 或安全组，逻辑也是一样：公网只允许业务入口和 WireGuard UDP，管理端口只允许 WireGuard 网段。对云服务器（弹性计算实例）来说，还要检查平台侧安全组和系统内防火墙是否同时放行；只改其中一层，常见结果是 wg show 有握手，但 TCP 连接仍超时。
接下来可以把运维入口从公网地址切换到隧道地址。例如原来使用 ssh user@203.0.113.10，改为 ssh user@10.66.0.2。切换完成后，保留一个短时间回滚窗口，确认自动化脚本、备份任务、监控探针都改成新地址，再关闭公网 SSH 或限制到固定办公出口 IP。对于运行网站的节点，站内关于 网站性能与主机优化 的实践也可以配合使用：业务流量走公网优化路径，管理流量走私有加密路径，两者不要混在一起排障。
扩展到多台服务器：优先选择 hub-spoke
当节点数量超过 3 台时，最常见的错误是每新增一台服务器，就和所有旧服务器互相加 peer。这样看似“全互通”，实际会让配置数量快速增长：4 台机器需要维护 12 组方向关系，6 台机器就变成 30 组。更可控的方式是 hub-spoke：中心节点负责汇聚，其他节点只和中心节点建立 WireGuard 连接，跨节点访问由中心节点转发或由业务规则限制。
这种模型的关键是 AllowedIPs 和系统转发。中心节点为每个 spoke 写入独立的 /32 地址，例如 10.66.0.2/32、10.66.0.3/32、10.66.0.4/32。各 spoke 的 peer 指向中心节点，AllowedIPs 写 10.66.0.0/24，表示访问该私有网段时走隧道。之后用防火墙决定谁能访问谁，而不是把所有节点天然放成“完全互信”。
验证与排障：用命令定位问题层级
WireGuard 排障要按层级走：先看服务是否启动，再看握手，再看路由，再看防火墙，最后看应用服务。不要一上来反复重装，因为大多数问题只是公钥填反、AllowedIPs 写错、UDP 端口没放行或服务仍绑定公网地址。
systemctl status wg-quick@wg0：确认配置文件能被解析，若报错包含行号，优先检查等号、空格和密钥是否完整。wg show：查看latest handshake，若长期为空，重点检查对端公网 IP、UDP 端口和安全组。ip route get 10.66.0.3：确认访问目标隧道地址时走wg0，否则检查AllowedIPs。tcpdump -ni any udp port 51820：在中心节点观察是否收到握手包，可区分公网阻断和本机配置问题。ss -lntup：确认目标服务监听在10.66.0.x或0.0.0.0，并结合防火墙限制来源。
如果 wg show 已经看到握手，但业务端口不通，通常不是隧道问题。此时可以从源节点执行 nc -vz 10.66.0.3 22，再到目标节点查看防火墙日志。若 ICMP（网络控制消息协议）通、TCP 不通，重点查端口策略；若所有协议都不通，回到路由和转发；若只有大文件传输卡住，尝试把 MTU（最大传输单元）从 1420 降到 1380 或 1280，并观察丢包变化。
总结：把加密运维通道做成长期资产
总结来看，WireGuard 站点到站点组网的核心不是“把配置跑起来”，而是建立一套可持续维护的私有运维通道。对很多使用 Hostease 服务器的团队来说，这种做法能把运维面和业务面分开，减少误操作带来的暴露风险。建议你至少保留 4 类记录：节点清单、隧道地址、公钥指纹、开放端口。新增或下线服务器时，配置、文档和防火墙规则要同步更新，避免旧 peer 长期残留。
生产环境还可以加入简单的健康检查：每 1 分钟从监控节点 ping 一次关键隧道地址，每 5 分钟检查一次 SSH 或监控端口，并在连续 3 次失败后告警。对于承载 WordPress、外贸站或企业应用的服务器，业务优化可以继续参考 WordPress 运维与优化内容，而服务器之间的备份、监控和管理访问则尽量收敛到 WireGuard 私有网段。
如果你需要为多台云服务器（弹性计算实例）建立加密运维通道，可以考虑先从两台节点的最小配置开始：固定一个私有网段、开放一个 UDP 端口、完成一次握手和 SSH 验证，再扩展到 hub-spoke 拓扑。这样每一步都能验证，出现问题时也能快速定位在密钥、路由、防火墙或应用服务哪一层。