ipsec.conf 还是 swanctl.conf？选定一个 strongSwan 前端

一份来自旧指南、能够正常工作的 IKEv1 配置落到 Ubuntu 24.04 上，第一次尝试却失败了，因为守护进程从未读过那个文件。通常的反应是再改一遍配置。真正的问题是：装的是哪个 strongSwan 前端，正在运行的服务用的是哪一个。在这一点弄清楚之前，每一次修改都指向一个可能并不存在的加载器。

两个文件，两个加载器，一个守护进程

旧的 starter 方案读取 ipsec.conf，并通过它旧的集成管理方式把连接交给 charon。它的操作入口是 ipsec 命令。

swanctl 方案通过 VICI 加载定义、读取 swanctl.conf，并由 swanctl 命令驱动。systemd 原生的 charon 守护进程与这种方式集成。

两者可以装在同一台机器上，混乱正是从这里开始的。/etc 下的文件只能证明有人写过它，不能证明正在运行的进程读入了它。为了看哪个能用而把所有方案都装上，会得到一台有两条管理路径、却说不清归属的主机。选定一种方案，把另一种删掉或停用。

读取已安装的软件包和 unit

先只做只读操作。Ubuntu 24.04 上的软件包名是分开的：strongswan-starter、strongswan-swanctl 和 charon-systemd。缺少某个软件包是有用的信息，而不是让你去安装它的指令。

一次把软件包和 unit 都清点出来：

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

然后检查活动的 unit 及其启动命令。unit 名称说明配置归哪个守护进程所有，命令行则确认它被要求读取哪些文件。已启用但未运行的 unit，讲的是与正在运行的那个不同的故事。

如果活动 unit 是 strongswan-starter，真正起作用的是 ipsec.conf。如果装着 swanctl 的 charon-systemd，那 ipsec.conf 只是摆设。

使用对应的控制路径

每个前端对连接和关联都有自己的视图。swanctl --list-conns 显示已加载的定义，swanctl --list-sas 显示活动的关联。旧路径用的是 ipsec statusall。

把两者混用会产生误导性的错误。缺少 VICI 套接字或控制请求被拒绝，是管理路径的问题，而不是对方拒绝认证的证据。

读取属于正在运行守护进程的那个视图，然后再解读结果。如果该视图中没有这条连接，问题就在加载，而不在协商。

格式不是 IKE 版本

旧配置用 keyexchange=ikev1 选择 IKEv1。swanctl 连接使用版本设置，其中 1 选择 IKEv1。这是同一件事的两套词汇，而不是一次转换。

对端地址、本地与远端的身份、凭据来源、提议以及 child 选择器，都必须刻意地逐一映射。把 left/right 块粘进 swanctl 语法，这些一样都做不到。

只改协议版本，是最常见的半截迁移。这样得到的文件能加载，随后却会因为与版本无关的原因认证失败。IKEv1 本身已被 RFC 9395 弃用，所以仍在要求它的既有对端值得一份写明的兼容性约束和迁移路径，而不是新的默认值。

动配置之前先确认加载器

先跑加载器检查，再加载目标连接，然后评估协商，最后才看受保护流量的路径。每个阶段的失败特征都不一样。

两条控制路径直接回答加载这个问题：

swanctl --list-conns
ipsec statusall

这些命令里只有一条属于你这台主机。两条都跑一遍再比较输出，是找出哪一条在骗你的办法，而不是诊断方法。

把软件包归属、配置加载和协议兼容性当成三个独立的问题。对某个前端有效的文件，否则会在另一个守护进程运行时被一遍又一遍地改。