Check Point VSX VPN：链路选择，还是对端不匹配？

当 Check Point 的站点到站点隧道不再建立时，两种不同的变更会产生同一种症状：对端看到的外部地址变了，或者它拒绝了此刻收到的 IKE 身份。在同侧抓到的报文里，两者看起来完全一样。要判断你遇到的是哪一种，需要三项检查，而其中没有一项是链路选择面板。

顺序搞反，你就会去调整源地址选择来修一个身份不匹配的问题。同一个隧道于是被修了两次，并且在下次路由变更之后再次失效。

区分两种情形的三个条件

条件之一：对端配置的端点，是否与真正到达的地址一致？如果报文从对端并未关联到你那台对端对象的地址抵达远端网关，那么在任何身份交换发生之前，协商就已经失败。条件之二：提议中的 IKE 身份，是否与对端期望的值一致？那属于认证，而不是传输。条件之三：你要改的那个选项，在这个版本上是否受这台虚拟系统支持？界面上看得见的设置，一个也回答不了这三个问题。

如果第一个条件不成立，你有的是路由或地址转换的问题。如果第二个不成立，你有的是与对端的约定问题。如果第三个未知，请先停止配置。

先把外部对端的记录建起来

在动任何东西之前，先写下虚拟系统、软件版本和已安装的更新级别。然后记录外部接口、通往远端对端的路由、NAT 前后的预期源地址，以及远端对端所配置的端点。

把内部受保护的网段放在这份记录的另一部分。修改外部源地址和修改受保护的 LAN 地址是两件不同的事，只是恰好住在同一条策略里。

给你保留的每一份抓包都标上方向。本地发起的协商与对远端对端的应答，可能做出不同的选择，所以没有标注的抓包是弱证据。用虚拟系统和发起方给文件命名。

读懂链路选择究竟分开了什么

Check Point 关于 R81.20 链路选择 的指南分开了人们常常混为一谈的三件事：远端对端如何解析网关地址、哪条路由承载出向流量、以及使用哪个源 IP。每一件回答的都是不同的问题。它们都不改变对端所认证的身份。

正是这种区分解释了：为什么路由变更可以在不碰 IKE 身份的情况下改变可见的外部地址，以及为什么身份变更可以让一个路由完全正确的隧道断掉。

RFC 7296 为 IKE 本身划下了同一条界线：标识载荷并不是传输地址。厂商是实现这种分离，而不是重新定义它。

用证据来决定，而不是用设置面板

如果对端报告身份未知或不匹配，就修对端对象或身份配置，而不是源地址选择。如果对端什么也没报，而你的抓包显示报文从一个意料之外的地址发出，就先修路由或地址转换。如果两边看起来都对而隧道仍然失败，就到远端抓包，比对它收到了什么。只有当地址与身份一致、而路径依然不对时，链路选择的某个选项才成为候选。

在 VSX 上配置那个选项之前，先拿到对应版本的受支持功能指引，或者厂商针对虚拟系统场景的明确声明。早先那份“某功能不可用”的报告属于历史，不是当下的禁令；而设置面板也不是支持性声明。

把两端对齐，并把记录留住

一旦有了受支持的设计，就把外部可达性、对端端点配置和身份约定放在一起，当作一份契约来复核。然后为三种情形规划验收：初始连接、由远端发起的连接，以及你预期在路径断开时出现的失败。

把观测到的外部地址保存在当前虚拟系统上下文旁边。这样下一次路由变更时，比对的就是一份有据可查的契约，而不是某个人记忆里的默认值。