FRITZ!Box 的 VPN 已连接却没人应答：WireGuard 还是 IPSec
已连接却访问不到 LAN 的 FRITZ!Box 隧道是地址规划问题。重新导入前，先核对 IPSec 的四个字段或 WireGuard 的对端。
隧道报告已连接，图标是绿色的，而家庭 LAN 上没有任何东西应答。这是 FRITZ!Box 远程访问最常见的抱怨，而且几乎从来不是隧道本身的问题。错的是地址规划、子网标识或客户端的路由表。你最终要排查其中哪一项，取决于你选的是 WireGuard 还是更老的 IPSec Fernzugang，所以先搞清楚自己实际配置的是哪一个。
隧道起来了，LAN 却毫无反应
建立成功的隧道只能证明密钥和端点是对的，并不能证明 客户端拿到的地址是盒子能路由过去的，也不能证明客户端知道哪些前缀属于这条隧道。这是两件互不相同的成功，只有第二件才让你够得着打印机。
先检查客户端的地址，再看它的路由表。
如果分配到的地址落在 LAN 子网之外，盒子就没有回程路由可走。如果落在 DHCP 范围内，盒子可能把同一个地址发给某台本地设备。两种情况都会得到一条能连上、但 LAN 对你视而不见的隧道。
每个选项到底配置了什么
IPSec 选项为一个用户生成配置文件，里面包含预共享密钥和地址。你把它导入会说同一套配置文件的客户端，而在 Windows 上这通常意味着厂商工具，而不是系统内置客户端。WireGuard 选项为一台设备生成一个对端：一对密钥、隧道内的一个地址和一个端点。
这一差别决定了你的维护方式。每台 WireGuard 设备都是带自己密钥的独立对端，所以吊销一部丢失的手机意味着删掉一个对端，其余照常工作。IPSec 靠更换共享密钥或用户配置来吊销，粒度更粗，会波及每一个使用它的设备。
两种选项都不过时。在对端跑不了 WireGuard 的地方，IPSec 这条路依然是受支持的那一条。
会让隧道变成死路的 IPSec 字段
有四个值必须与你的 LAN 一致，其中三个出错时看起来就像隧道坏了。
| Value | What breaks when it is wrong |
|---|---|
| LAN subnet | The client routes nothing, or routes the wrong prefix |
| Network address | The configuration looks valid and the tunnel never establishes |
| DHCP range | No address is left to assign to tunnel clients |
| DNS server | The tunnel works and name resolution does not |
真正让人栽跟头的是网络地址。子网以它的第一个地址来标识，这个地址通常以零结尾，在那里填一个主机地址，得到的配置看起来完全合理，却永远连不上。DHCP 范围之所以重要是另一个原因：隧道客户端通常从它上方分配，所以一个吃满整个子网的范围就没剩什么可发了。
子网重叠是另一个经典情况。如果你要加入的远端 LAN 和你所在的 LAN 用了同一个前缀，路由就分不清两者，唯一的真办法是把其中一侧重新编号。再多的客户端配置也解决不了。
为什么 WireGuard 失败的方式不一样
WireGuard 没有可以打错的预共享密钥，所以它的故障集中在对话端的定义上。允许 IP 列表漏掉 LAN 前缀，会得到一条什么都不承载的隧道，因为客户端永远不会把发往 LAN 的流量送进去。任何一侧用了过期的公钥，握手就永远完不成。缺少端点或端口填错，得到的是沉默而不是报错。
与其重新导入文件碰运气，不如逐字段对比两侧。
唯一的共同故障是子网冲突。WireGuard 会乐于把隧道建到与你本地网络重叠的网段上，然后由路由表决定两个相同前缀里谁说了算。
从外面证明它，然后给自己留一条回去的路
用移动网络测试，绝不要从 LAN 内部测试，因为从里面测的是一条根本不经过隧道的路径。在启用之前记下每个选项用哪个端口，并把那个端口转发到盒子上。
把生成的文件放在不用隧道也能拿到的地方，顺手记下盒子的外部名称。
从未从外部验证过的配置只是计划，不是能用的远程访问通路。测试 LAN 主机时用地址而不是名称，免得 DNS 故障被误当成路由故障。