网络变化时 MOBIKE 如何让 IKEv2 VPN 保持存活

一部手机离开 Wi-Fi 加入蜂窝网络，一台笔记本从 Ethernet 移到热点，而 IKEv2 隧道要么活下来，要么没有。MOBIKE 就是让它活下来的扩展：它告诉远端源地址已经改变，而不是从头开始。它做不到的是让每个应用在切换过程中都保持存活。这是两个不同的说法，而人们通常想说的是第二个。

分阶段地走一遍切换过程，因为每个阶段的失败方式都不同。

更新究竟改变了什么

只要安全关联仍然有效，发起方就会得知自己的新地址，并向响应方发送更新，响应方随后把该地址用于同一个关联。安全参数不会从头重新协商。 这就是全部好处：没有新的认证轮次，没有新的密钥交换，也不需要询问用户。这也意味着存活下来的状态仍然属于旧会话。

MOBIKE 还可以把流量转移到 UDP 封装，这就是可用的隧道有时会在换网后开始使用 4500 端口的原因。这种转移本身并不能证明检测到了 NAT，尽管两者经常一起出现。

你的配置文件是否真的启用了它

两端都必须支持该扩展，部署也必须启用它。在 strongSwan 中，行为可以按连接配置，接口或路由变化可以在需要时触发路径搜索和更新。请检查连接的实际设置，而不是假设每个 IKEv2 配置文件都会启用它。从早于该功能的指南中复制来的配置文件，是这种情况的常见来源。

两端的协商状态才是权威，而不是产品系列的文档。

分阶段地走一遍切换过程

在移动网络之前，记录应用的状态。然后移动，之后记录客户端和服务端的状态。地址缺失、对端不可达，以及必须自行重连会话的应用，是三种不同的结果。只有前两种属于 VPN 层；第三种属于应用所使用的协议。

把网络切换与静止测试作对比，才能知道哪个事件触发了问题。在最终网络上做吞吐量测量无法重现一次切换。它测的是终点，而不是旅程。

把故障分层

长时间存活的 TCP 会话可能因 IKEv2 交换之外的原因失败。新网络的过滤、解析或路由方式可能不同。隧道地址可能完全没有变化，而它下面的路径却变了。这就是为什么应用重连能修好 VPN 从未破坏的东西。

恢复期间也要让阻断策略保持生效。

自动移动性和阻止直接流量的规则是两种不同的控制手段，为了前者而关掉后者是糟糕的取舍。如果移动性更新失败，阻断应当保持，而不是让流量绕过隧道泄漏出去。

重复发生时该记录什么

保留两侧的时间戳和两个地址值。这份记录能说明更新是否在应用失去联系之前完成，而这正是移动性缺陷与应用超时的区别。然后比较切换方向：从 Wi-Fi 走向蜂窝网络，与反向并不对称。一个方向可行，另一个方向却会失败。

这种不对称足够常见，应当成为第一个要测试的东西。

手上有记录之后，事故就不再是又一个断开的图标，而是有已知负责人的序列中的一个事件。而这是一次走查能诚实承诺的全部。