紧急断网还是访问局域网？WireGuard 的两种答案

握手完成，浏览正常，打印机、NAS 和本地 SSH 主机却消失了。在 Windows 客户端上，这通常根本不是路由故障：只要对端的允许前缀包含字面默认值，客户端就会启用“阻止未隧道流量”，而该选项是以防火墙规则实现的，会丢弃从任何其他接口发出的数据包。路由表仍然把本地子网列为直连，所以症状看起来像在撒谎。该怎么做由三个条件决定，其中只有一个与路由有关。

两种故障戴着同一副面具

第一种故障是客户端的 fail-closed 模式，其特征是隧道之外的一切都停止，而隧道本身工作得完美无缺。第二种是真正的可达性问题：缺少路由、服务器上缺少客户端后方子网的条目，或者两个网络共用同一地址段。两者都会造出一台能浏览却不能打印的机器，而它们的修法正好相反，所以诊断必须先于配置。

区分二者的观察点是：本地子网是否仍在路由表里，而发往它的流量却被丢弃。

三个条件决定答案

第一，这台机器需要 fail-closed 吗？如果需要，隧道断开时必须停止流量，而不是让它退回物理接口，这个要求高于本地便利。第二，隧道开着时，本地设备必须保持可达吗？打印、网络存储和本地管理控制台是常见理由，它们是正当需求，而不是需要道歉的例外。第三，配置文件是否把默认值写成字面的 0.0.0.0/0？正是这个细节触发了客户端的规则，而它是可编辑的。

在动配置文件之前，把这三个问题写下来回答，因为每个答案指向不同的配置。

选择 fail-closed，放弃局域网

如果泄漏比本地可达更重要，就保留字面默认值，让“阻止未隧道流量”保持启用。这是一个自洽的立场：这台机器被视为一台要么在隧道内、要么离线的设备，本地服务从另一台设备访问，或在服务器为它们做路由时经隧道访问。代价是真实的，应该写进部署说明，而不是等需要打印的人自己发现。

对于处理那些隧道一断就不该出现在咖啡馆网络上的工作的机器，这是正确的选择。对于同时需要扫描仪的家用笔记本，这是个糟糕的默认值。

选择局域网访问，换一种方式表达默认值

如果本地设备必须保持可达，就用同样的覆盖范围，但不写那个字面默认前缀。两个半前缀覆盖所有 IPv4 地址，对应的那一对覆盖 IPv6，而客户端不再插入阻断规则，因为它要找的字符串不在。

[Peer]
AllowedIPs = 0.0.0.0/1
AllowedIPs = 128.0.0.0/1
AllowedIPs = ::/1
AllowedIPs = 8000::/1
Endpoint = vpn.example.net:51820

清掉那个勾选框会让客户端把同样两对写进配置文件，所以把生成的文件与上面的块作比较，是确认机制而不是猜测机制的快捷方式。由此带来两个后果。覆盖面完全相同，隧道的其他方面不变。保护并不相同：规则消失后，隧道一旦断开，机器就会用回物理接口，而这正是 fail-closed 所阻止的。

无论如何都要检查另外两个嫌疑

防火墙的问题定下来之后，确认本地子网确实被路由，远端也知道这台客户端背后的一切。必须到达客户端后方局域网的服务器，需要该前缀出现在集线器上客户端的允许列表里；漏掉它，集线器就无法为这些地址选择对端，任何客户端配置都造不出来。

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction
route print 0.0.0.0

网络类别比人们预想的更重要：新建的隧道适配器若被归类为公用，就会改变适用于它的规则，结果看起来像是远端的防火墙拦截。路由打印能显示究竟有没有默认路由，从而把策略问题与缺失的路由区分开。

然后在同一次会话里测三件事：互联网、一个按地址访问的本地主机，以及一个经隧道访问的主机。握手只能证明密钥一致，真正体现策略的是这三项测试。如果清掉选项后本地主机仍然拒绝，剩下的嫌疑依次是路由、远端的允许列表和重复的子网。