当 IPsec 中断时，备用路由并不是备用策略

一个站点失去了隧道，而路由表仍然显示一条经由互联网通往目的地的完全可用的路径。有人提议切换到那条路径，并称这一改动为路由修复。数据包确实可以走那条路；没有人提出的问题是，它是否被允许在没有保护的情况下抵达。这是来自两张不同表的两个不同答案，把它们混为一谈，正是故障变成事故的方式。

路由表里看起来完全相同的两种结果

可达性说明数据包有地方可去。安全策略说明这个数据包在路上必须经历什么，而两者由不同的机制执行。一条路由可以为一个策略必须丢弃的流而存在，这种组合并不是配置错误。把两个问题分开，才让中断预案真正可被审查。

因此，只有在有人决定适用哪一条允许结果之后，中断路径才算一个设计。在这个决定存在之前，备用路由是诱惑，而不是方案。

IPsec 架构区分必须丢弃的流量、允许绕过保护的流量，以及必须受到保护的流量。这是三条不同的指令，中间那条是有意为之的豁免，而不是故障模式。把它们读成一对，才产生了隧道与开放道路之间的虚假二选一。

缺少关联并不会悄悄把保护规则提升为绕过。策略仍然写着保护，于是数据包等待或消亡，这种行为是控制按字面工作，而不是策略损坏的证据。

把你的流的需求写成三句话之一：停在原地直到出现受保护的路径，切换到另一条受保护的路径，或者使用一条被单独授权可以不走 IPsec 的路径。只有第三句改变了安全契约，而它需要一位能签字的负责人。这句话要写进变更记录，而不是某个人的记忆。评审人批准第二句、拒绝第三句，只要它们可见，两个决定都合理。

替代路径需要可路由的地址、在抵达处的显式接纳，以及一条双向可用的回程路径。站点私有地址不会因为默认路由指向某处就变得可达。

认证与编址同样重要。跳过隧道、抵达一个期待保护的边界的流量，即使落在正确的接口上也会被拒绝，因此接收方策略必须有意识地接受这种形态。远端从未同意的豁免，是多了几步的中断。

为了让故障切换生效而移除选择器或放宽映射，并不是受控的豁免。它扩大了豁免范围，让远端继续执行另一套东西，还可能改变哪条转换规则与这条流匹配。

转换可以呈现另一种地址视图，但正向和反向映射必须与替代路径一致。单向映射会产生一条先建立、随后挂起的连接。半套映射比没有更糟，因为它看起来像进展。

接纳是另一半。接收方必须有针对这类流量的明确规则、自己的日志，以及一种在凌晨三点把获批豁免与错误区分开的方法。

记录故障如何被发现、由哪条策略选择替代，以及故障发生时正在运行的会话会怎样。新连接在切换后可以成功，而较旧的连接仍然保留着绑定在已失效地址上的状态。

当需求是持续保护时，始终优先选择另一条受保护的路径。在确实需要无保护例外的地方，用源、目的、服务和时限把它限定住，并写下它如何被撤销。

验收覆盖隧道失效的情形和恢复后的情形，并对每种情形做一次应用检查。有意思的结果不是数据包一直在动，而是它们只在组织所选的契约之下移动。

还要加上撤销测试。一条没有人能关掉的豁免，已经悄悄变成了永久策略，而这正是原规则所要防范的。给它加上到期日期和具名评审人，否则这条豁免会比所有理解它的人活得更久。