WireGuard 分离隧道：不设默认路由的配置方法

分离隧道由你留在外面的内容定义，而 WireGuard 只用一个字段就做出这个决定。客户端对端的 AllowedIPs 同时决定哪些目的地走隧道，并过滤接受哪些内部源地址，wg-quick 又把同一份列表变成主机路由。列表一旦写错，隧道要么吞掉一切，要么什么都带不动。

先确定前缀列表

在碰配置文件之前，先把必须走隧道的目的地写下来。办公网段、数据库网段、管理网络：每一项都是有理由的前缀。不在列表里的全部留在物理路径上，这正是设计的全部意义。

如果列表包含 0.0.0.0/0 或 ::/0，你建的就是完整隧道，应当明说，因为故障模式和 DNS 预期不同。

把列表控制得足够短，便于复核者事后对照路由表。

客户端配置：对端、AllowedIPs、DNS

客户端的接口块放自己的隧道地址和私钥。对端块放服务器公钥、端点，以及第一步里的前缀：

[Interface]
Address = 10.9.0.2/32
PrivateKey = <client-private-key>
DNS = 10.20.0.53

[Peer]
PublicKey = <server-public-key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16, 10.30.0.0/24
PersistentKeepalive = 25

客户端上的 AllowedIPs 是远端目的地的集合，不是客户端自己的地址。DNS 行只有经由 wg-quick 的解析器集成才生效，因此不支持 resolvconf 或 systemd-resolved 的主机会忽略它。PersistentKeepalive 用来维持 NAT 映射，在直连路径上并不需要。

给每个前缀加上它服务对象的注释，否则下一次修改就只能靠猜。

服务端配置：相反视角

在服务端，对端条目代表客户端，所以它的 AllowedIPs 是客户端的隧道地址，通常是 /32。它不是办公网段。把客户端的列表抄到服务端条目，是分离隧道最常见的错误，结果要么放宽了访问，要么在握手时破坏了内部源地址校验。

服务端自身的接口地址，以及它通往办公网所需的路由，与任何对端条目都是分开的。

两个文件，两种视角，一套前缀分在两边。

启动并读取路由

用受支持的管理器启动接口，然后看它实际装了什么，而不是你打算装什么。wg-quick 从 AllowedIPs 推导路由；如果配置里写了 Table = off，就什么都不装，路由要你自己写。逐个前缀读取路由，确认指向 WireGuard 接口。路由列表为空，通常说明生效的配置并不是你改的那份。

也要看握手计数器，没有握手的对端是密钥、端点或可达性问题，而不是路由问题。

把用过的确切命令写下来，因为下一个人会在压力下执行它。

两端都验证，然后记录回滚

测试一个私有地址、它的内部名称，以及一个必须保持直连的目的地。如果私有地址通了、直连目的地却改走隧道，说明前缀列表太宽。如果地址通而名称失败，说明 DNS 行没有生效。回滚只有一条命令，它应当写在同一份记录里。

重新连接后确认路由还在，因为重新应用配置的管理器可能覆盖手工路由。

只保留一个配置负责人，因为两个管理器同时生成同一个接口，迟早会冲突。wg-quick 手册记录了它提供的路由与 DNS 行为。