IKE 标识还是端点地址：别把两者混为一谈
FQDN 类型的 IKE 标识是字面量认证值，而不是反向 DNS 查询。请把端点地址、本地标识和预期对端分开记录。
把标着 FQDN 标识的字段当作字面字符串来读，而不是当作对你公网地址反向 DNS 名称的请求。在 strongSwan 的解析器里它就是字符串，读取时永远不会把它解析成端点。仅这一点就能消除选择对端标识符时最常见的干扰。下面的检查确保涉及到的三个值不会合并成一个。
标签不是查询
厂商界面用 FQDN 和 hostname 这类词相当随意，机箱上的标签并不说明背后的编码方式。一个把字段叫作 Client FQDN 的设备，可能发送 FQDN、邮件形式的字符串，也可能发送裸地址。请把文本和类型当作两个独立决定，并分别记录。
字面标识本身并不需要 DNS。它是对端要核对的声明，不是网络必须解析的名称。
三个值分开写
一个配置界面背后其实有三件事，把它们合并才是代价高昂的错误。一是决定数据包去向的端点地址。二是本端出示的本地标识，三是在认证之前你对远端所预期的标识。请在变更单里写成三行，因为少于这些就只是在描述一条 VPN，而不是一段关系。
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
示例标识必须作为部署的一部分被选定并授权。它们是认证要核对的声明，而不是让任何对端都可信的凭据，所以看起来合理的字符串并不能授权任何事。
类型是值的一部分
strongSwan 标识参考区分 FQDN、邮件形式的值、IP 地址以及其他编码，因此编码与字符同样重要。两台设备可以在不同类型下接受相同的文本，却仍然互相拒绝。只记录值而不记录类型的笔记，只算半份配置。
向厂商确认设备实际发送的是哪种类型，并用解码结果而不是界面标签来验证。猜出来的类型就是等着下一次变更来暴露的不一致。
两侧必须互相满足
每一侧的本地标识都必须通过对端的认证策略。这和把同一个字符串粘进两台设备的每个标识框并不一样，那种捷径只会做出没人能调试的配置。
证书认证还有自己的要求，因为证书的标识和信任条件与你填写的 IKE 标识并列存在。仅有 IKE 标识匹配并不能授权证书对端。
DNS 在哪儿重要，以及你的版本强制了什么
用于发现的网关主机名确实需要可用的 DNS，而这个要求属于寻找端点，与已填写标识的任何反向查询无关。请在变更单里把两者分开，因为发现失败和标识不一致在客户端日志里读起来很像，修复的位置却不同。
在照抄强制类型的写法之前，先读你实际运行的产品和版本的解析器，因为较旧的 strongSwan 版本行为不同，其他厂商也会加上自己的限制。比较两端时，把四样东西放在一起看：预期标识、出示标识、类型和认证错误。这一组能把不一致变成证据，而不是观点。