IPsec 配置文件里的五种地址角色，以及哪一种写错了

在一个典型的连接定义里，五个不同的任务都会拿到一个地址，而它们不必彼此一致。管理员常卡住，是因为一个看似合理的直觉——让所有字段都指向同一台主机——对其中至少三个任务是错的。出路是先给症状命名，再看可能造成该症状的那一两个字段。

五个任务，按重要性排序

传输端点决定 IKE 交换被送到哪里。经认证的身份是双方各自证明的名字，它对照的是策略而不是路由表。受保护子网是选择器，决定哪些内部流量属于这条隧道。然后是网关自己发起会话时使用的源地址，最后是到达对端所走的底层下一跳。

left 和 right 这类参与者标签只是连接两端的约定，并不等于本地与远端。先读实际安装的那份实现的文档，再假设某个键的含义与另一款产品相同。

判断一：什么都建立不起来

日志里完全看不到交换时，端点就是第一嫌疑对象：地址写错、路径被过滤，或者守护进程根本没在某个接口上监听。要等到握手可见之后再看身份字段，因为身份是在交换内部判定的，而不是在交换之前。被过滤的路径和写错的地址从客户端看完全一样，所以动手修改之前先检查监听侧。确认守护进程绑定在你预期的接口上，因为只在某一个地址上监听的进程，看起来和一条被封掉的路径一模一样。

经过转换后观察到的公网地址，与对端所证明的身份并不是一回事。为了迎合远端抓包看到的结果去改地址，是一种常见且错误的改法。

判断二：隧道起来了，流量却不通

选择器决定什么能进隧道，这里一旦对不上，就会出现协商成功、应用仍然失败的情况。远端必须把你的受保护网段写成它自己的远端网段，而写反的取值正是在这里混进来的。

修改之前先把两份配置并排读一遍。一台主机上的本地网段就是另一台主机上的远端网段，只要有一对写反，就能解释一条什么都传不过去的隧道。先缩小这对网段，再动键值：隧道内放一个子网、隧道外放一个，就能判断问题出在选择器还是路由上。

判断三：只有网关自身的流量失败

替客户端转发的流量可能一切正常，而网关自己发起的请求却失败，因为那条流没有可以继承的客户端源地址。首选源地址这项设置正是为这种情况准备的，它并不是源地址转换：它是挑一个源地址，而不是改写一个源地址。

如果某个应用显式绑定了另一个地址，它可以盖过这项首选设置，所以在断定设置被忽略之前，先确认数据包真实的源地址。要在网关自己的接口上抓包，而不是相信配置的意图。

下一跳是本地指令

底层下一跳只告诉这台主机如何到达对端，远端并不需要同一个值。把它当成共享设置，或者把默认网关写死，一旦路由变化或出现第二条路径就会立刻失效。

有些实现在这里提供特殊取值。手册针对已安装版本列出的写法是唯一安全的答案，而本地路由表就是它确实生效的证据。当对端能按名字到达、却不能按地址到达时，这个不一致本身就是结论，而不是需要绕开的细节。

从两端读这份配置

在纸上把角色对调，是最快的复核方式：交换受保护网段，保留各自一侧的下一跳，保留各自一侧的身份。任何经不起这次对调的项，多半被分配给了错误的任务。

然后按角色各测一条流：对端之间的可达性、一条内部客户端流，以及一个由网关发起的请求。三个测试就能告诉你哪个任务分配错了，而不必再次打开配置。把结果写进工单、放在你改过的字段旁边，因为下一位工程师会遇到同一份配置。