- 先说明问题场景：为什么要用 WireGuard 命令行
- 快速流程概览（先看全局思路）
- 准备工作与必要命令
- 配置要点（命令行思路说明）
- 典型命令序列（文字描述 + 关键示例）
- 常见故障与排查思路
- 1. 接口未创建或未 UP
- 2. 密钥或对端公钥配置错误
- 3. 路由与 AllowedIPs 设置不当
- 4. NAT/防火墙阻断
- 5. MTU 和分片问题
- 6. DNS 解析不正确
- 实战案例：VPS 做出口代理但内网无法访问某服务
- 性能与安全注意事项
- 快速检查清单（排查时逐项过一遍）
- 结语风格收尾（技术人味）
先说明问题场景：为什么要用 WireGuard 命令行
在家用路由器、VPS 或容器中部署 WireGuard，很多时候不会直接使用 GUI，而是通过命令行完成。命令行方式更灵活、可脚本化，便于在自动化部署、容器镜像或调试时精确控制。本文聚焦于在常见 Linux 环境下，用命令行快速完成配置流程，并排查常见连通性问题。
快速流程概览（先看全局思路）
部署 WireGuard 的核心步骤可以概括为：生成密钥 → 配置接口参数（IP、MTU） → 配置对等方信息（Endpoint、AllowedIPs、PersistentKeepalive）→ 启动接口并验证路由与防火墙。遇到问题时，从链路层、IP 层、路由表、NAT/防火墙及 DNS 五个维度逐步排查。
准备工作与必要命令
常用命令包括：wg、wg-quick、ip、iptables/nft、sysctl、journalctl。掌握这几条命令能覆盖绝大多数场景的运维和排错需求。
配置要点（命令行思路说明）
1) 密钥管理：利用 WireGuard 自带或 openssl 生成公私钥对，私钥保存在本地、不要泄露；公钥在对端交换。
2) 接口配置：给 WireGuard 接口分配私有网段地址，例如 10.0.0.1/24，注意不要与本地已有网段冲突。
3) MTU：默认 1420 在多数场景适用，但在 VPN over VPN 或隧道链路有时需调低以避免分片导致的性能问题。
4) AllowedIPs：决定了哪些目的地址会被走隧道，设置为 0.0.0.0/0 意味全部流量走隧道；按需精细化可避免路由冲突。
5) PersistentKeepalive：NAT 环境下建议设置为 25 秒，保持 UDP 打洞。
典型命令序列（文字描述 + 关键示例）
下面给出典型的命令行步骤示意，便于在没有 GUI 的环境中复用。示例为说明用法，实际密钥和 IP 请替换。
# 生成密钥（示意）
wg genkey | tee privatekey | wg pubkey > publickey
创建接口并分配地址
ip link add dev wg0 type wireguard
ip address add dev wg0 10.0.0.1/24
wg set wg0 private-key ./privatekey listen-port 51820
添加对等节点信息
wg set wg0 peer allowed-ips 10.0.0.2/32 endpoint 1.2.3.4:51820 persistent-keepalive 25
启动接口
ip link set up dev wg0
另外，使用 wg-quick 可以把上面配置写成配置文件并一键管理，适合长期使用和 systemd 集成。
常见故障与排查思路
排错时遵循“从物理/链路到应用”的顺序：
1. 接口未创建或未 UP
检查 ip link show wg0，确认接口存在且状态为 UP。若没有，检查 ip link add、ip link set 命令是否报错，或 wg-quick 是否有权限问题（需要 root）。
2. 密钥或对端公钥配置错误
使用 wg show wg0 检查当前对等方的公钥和传输统计信息。若握手计数为 0 且没有接收/发送包，确认私钥与对端配置的公钥是否正确匹配。
3. 路由与 AllowedIPs 设置不当
AllowedIPs 决定哪些目标通过隧道。误把本地网段包含进去会导致“自我路由”或路由环。用 ip route 查看路由表，确认目标地址指向 wg0。如果设置 0.0.0.0/0，注意默认路由被替换后的流量走向。
4. NAT/防火墙阻断
如果对端在 NAT 后面，必须有 PersistentKeepalive 或在 NAT 路由器上做端口映射。还要检查本机与 VPS 上的防火墙规则（iptables/nft），确保 UDP 端口允许通过，并且没有误用 DROP 规则。
5. MTU 和分片问题
若遇到断断续续、HTTPS 页面加载慢或大文件传输失败，可能是 MTU 导致的碎片丢失。尝试逐步降低 MTU，看能否恢复稳定性。
6. DNS 解析不正确
即便隧道建立，DNS 没有正确推送或配置也会导致看似“断网”。查看 /etc/resolv.conf 或 systemd-resolved 状态，确认是否需要将 DNS 指向隧道内的解析器或使用公共 DNS。
实战案例：VPS 做出口代理但内网无法访问某服务
问题表现：客户端通过 WireGuard 成功连上 VPS，但访问 VPS 本地某服务（例如 192.168.1.100）失败。排查步骤：
1）确认客户端到 VPS 的隧道可通（wg show、ping）。2）在 VPS 上检查 IP 转发是否启用（sysctl net.ipv4.ip_forward = 1）。3）若需要 NAT，确认 iptables 的 POSTROUTING 规则是否存在并正确使用 masquerade。4）检查服务监听地址与防火墙是否允许来自 wg 子网的连接。
性能与安全注意事项
WireGuard 设计非常轻量，但部署时仍需注意：
- 密钥保护：私钥应设置严格权限并尽量放置在不可公开读写的位置。
- 最小权限原则：AllowedIPs 不要滥用 0.0.0.0/0，除非确实需要所有流量通过隧道。
- 监控与日志：通过 wg show、journalctl 监控握手失败、接口重启等异常。
- 自动化部署：将重复步骤写入脚本或 wg-quick 配置并结合 systemd，让接口在启动时自动恢复。
快速检查清单（排查时逐项过一遍）
1. 接口存在且 UP（ip link）
2. 私钥/公钥匹配（wg show）
3. 对端有握手记录（latest handshake 字段）
4. 路由指向 wg 接口（ip route）
5. 防火墙允许 UDP 端口并配置了必要的 NAT（iptables/nft）
6. IP 转发已启用（sysctl）
7. MTU 合理并排查分片问题
8. DNS 可解析且指向正确解析器
结语风格收尾（技术人味）
命令行方式管理 WireGuard 给了我们对每一步的可见性和可控性。掌握好密钥、路由、防火墙和 MTU 这四个核心点，绝大多数联通性问题都能迎刃而解。把常用检查命令写成脚本或 systemd 单元，既可提高稳定性，也方便在故障时快速定位。祝在 fq.dog 的读者们构建出既高效又可靠的隧道。
暂无评论内容