L2TP/IPsec 在一张网络里能连上，在另一张里却超时

同一台笔记本、同一份配置文件、同一个密码，在一栋楼里能用，换一栋楼就失败。这个对比是工单里最有用的证据，却往往最先被丢掉。在两个接入网络之间，交换要经过不同的地址转换、不同的过滤规则和不同的路由器助手。把客户端固定住、只换网络，才能弄清其中哪一项真正有影响。

先固定客户端，再比较网络

在记录下正常可用的那一次之前，设备上什么都别改：客户端版本、配置文件内容、服务器名称，以及连接成功的时间。然后在同一时段内，在第二张网络上复现故障，让客户端状态尽量保持一致。两次尝试之间改过配置文件，整个对比就作废了。目标只有一个变量，而这个变量就是网络。

先确认故障网络上的普通上网是否正常，有访客门户的话也要算进去。一个从未通过的门户产生的超时，看起来和隧道被过滤一模一样，而这项检查只需要一分钟。

四个阶段，四种不同的报错

一条 L2TP/IPsec 连接 要经过四个阶段，而 RFC 3193 描述了把前两个阶段绑在一起的安排。IKE 协商是过滤路径产生静默超时的地方。IPsec 认证是证书或预共享密钥不一致时反而给出明确拒绝的地方。L2TP 隧道建立是安全关联已经建立却仍可能走不通的地方，PPP 登录则是错误凭据最终给出可见失败的地方。要看停在哪一阶段的日志，而不是它打印的最后一行。

journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10

strongSwan 的日志能看出 IKE 交换有没有走到提案、对端到底有没有回应，从而把可达性和策略分开。xl2tpd 的日志接着 IPsec 结束的地方往下走，所以安全关联已建立、日志里却什么都没有，就指向 L2TP 阶段。路由查询确认客户端确实发往你以为的服务器地址，从而抓出从上一张网络继承下来的过期 DNS 应答。三份输出合起来，说的是阶段，而不是症状。

比较 NAT 深度与助手行为

NAT 穿越会把受保护流量改走 UDP 封装一旦检测到地址转换，承载正常会话的端口号就可能与静态图上的不同。只放行一个建立包，证明不了交换的其余部分；外部端口扫描也无法告诉你对端如何处理通过认证的合法流量。第二层转换会再次改变局面，因为映射存在两份，并按两套不同的时间表过期。移动网络上的运营商级转换，正是办公室能用的配置在手机热点上失败时的常见原因。

路由器助手和网络一样五花八门。有的固件会拦截并改写交换，有的只是不再丢弃，还有的只在旧模式下才应用这项设置。要读固件自己对那个复选框的说明；如果有兼容模式，就把它当成一次有意的改动来试，而不是一次改三样。

出站客户端、入站服务器：两个不同的问题

出站客户端和入站服务器需要不同的上行可达性，帮助前者的穿透功能对后者毫无作用。家用路由器能让笔记本连到远端网关，并不因此就接受打向其背后服务器的入站连接。把两者混为一谈，就会让你去找根本不是问题所在的端口转发。比较之前先说明故障设备扮演的是哪种角色。

做完成支持范围内的改动后，重复同一次连接，并记录它走到哪一阶段。把可用的配置文件和故障网络的记录放在一起；不要重置凭据，也不要重装客户端，因为那会丢掉整个对比赖以成立的证据。