入站 IPsec 对等端匹配不到任何配置？检查四个字段

对端报告隧道已建立，你这一侧却看不到任何安全关联，而配置文件里明明有一个匹配的连接名。这三种说法可以同时成立。入站协商是拿对端的地址、它出示的身份以及它提议的流量，去与运行中的配置比对。磁盘上从未被加载的文件、与期望值不符的身份，或前缀差一位的选择器对，任何一项都会让协商悄无声息。按响应端处理问题的顺序，依次检查这四组字段。

从数据包出发，而不是从文件出发

响应端收到 IKE 请求后，先寻找能接受该对端的定义，然后才继续做认证与流量选择。如果第一步没有任何已加载的定义匹配，协商会在有用的错误抵达用户之前就结束。

所以“配置看起来没问题”并不算证据。该问的是运行中的服务加载了什么、又为这次尝试选中了哪一条。一条状态命令就能回答这个问题，而编辑器缓冲区回答的是另一个问题。再次修改文件之前，先看列表。

第一组字段：真正被加载的定义

用掌管守护进程的工具检查运行状态：一条列出已加载连接的状态命令，而不是编辑器缓冲区。确认期望的条目存在、为你想要的启动行为启用，并且是在你最后一次编辑之后加载的。保存了却没有重新加载，是“我改好了却什么都没变”最常见的原因。

还要确认服务读取的是哪个文件。各发行版不同，写错 include 文件的连接会被静默忽略，而不是被拒绝。如果状态列表里根本没有你的条目，先怀疑包含路径，再怀疑语法。

第二组字段：端点不等于身份

对端连接所用的地址，与它用来认证的身份，是两个不同的字段。主机名、可分辨名称、密钥 ID 和地址，都可能按配置充当 IKE 身份，它们完全不必长得像公网地址。

端点匹配还可能涉及 NAT 视角：网络上看到的地址，与对端自认为拥有的地址可能不同。在 libreswan 的连接模型中，left 与 right 只是两个参与方的标签，而不是固定的本地与远端次序；因此照搬别处可用的配置并调换地址，并不是可靠的转换。

写下双方期望的身份，以及验证该身份所用的凭据。如果这两行对不上，再怎么调整地址也匹配不了。

第三组字段：被保护的流量

选择器描述内层源与目的范围、地址族，以及任何协议或端口限制。针对单个主机地址的提议，与针对整个子网的请求并不相同；按子网配置的响应端可能拒绝它，也可能把它收窄。

两端不一致时，从双方视角比对预期的流，而不是把每个选择器都放宽到能连通为止。分别问两位管理员他们认为自己在保护哪条流，再把两个答案对照。不一致通常是一侧写主机前缀、另一侧写子网。因为如今保护了全部流量而匹配上的隧道，是另一个安全决策，而且是没人批准过的决策。

第四组字段：你读到的只是某一种实现

Libreswan、老版 Openswan 与 strongSwan 的管理工具不同、配置语法不同、匹配顺序也不同。其中一家的可用示例，并不能准确说明另一家的配置选择优先级或报错措辞，所以要按本机守护进程的文档来核对。

把一次尝试端到端串起来：发起方的源地址、出示的身份、提议的选择器，对上响应端的选择消息以及它点名的已加载条目。封装与解封装计数为零，只能说明观察到的关联没有承载这些数据包；它既不能指出拒绝提议的端点，也不能证明当时存在匹配的条目。

经过协同修正后，确认被选中的配置与关联，然后实测真正被放行的服务及其回程路径。匹配到配置只是让协商得以进行，而协商并不是最后一道访问检查。