☰

NO_PROPOSAL_CHOSEN strongswan ipsec 隧道

tag-icon • tag-icon vpn ipsec strongswan
NO_PROPOSAL_CHOSEN strongswan ipsec 隧道

您好，我正在尝试在 AWS VM 上设置站点到站点 VPN 隧道。以下是ipsec.conf两个 VM 的文件。

VM-1 (assume IP address : 1.2.3.4)

 conn %default
    lifetime=60m
    mobike=no
    keyexchange=ikev2
    authby=secret
    type=transport
    auto=start

conn gateway-1
    left=1.2.3.4
    leftid=1.2.3.4
    leftfirewall=yes
    right=1.2.4.5
    rightid=1.2.4.5
    ike=aes256-sha1-modp1024!
    esp=aes256-sha1!
    leftauth=secret
    rightauth=secret
    type=transport
    auto=start


VM-2 (assume IP address : 1.2.3.5)
 conn %default
    lifetime=60m
    mobike=no
    keyexchange=ikev2
    authby=secret
    type=transport
    auto=start

conn gateway-2
    left=1.2.3.5
    leftid=1.2.3.5
    leftfirewall=yes
    right=1.2.4.4
    rightid=1.2.4.4
    ike=aes256-sha1-modp1024!
    esp=aes256-sha1!
    leftauth=secret
    rightauth=secret
    type=transport
    auto=start

在两台机器上我都通过命令启动了 strongswan strongswan start。

当我尝试strongswan up gateway-1从 VM-1 运行时，我得到了 -

initiating IKE_SA aaa[3] to 1.2.3.5
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP)    N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 1.2.3.4[500] to 1.2.3.5[500] (336 bytes)
received packet: from 1.2.3.5[500] to 1.2.3.4[500] (36 bytes)
parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN notify error
establishing connection 'gateway-1' failed

我不确定我在这里遗漏了什么。

答案1

IKE 提议首先通过发起方和响应方 ID（IDi/IDr）进行匹配，其工作原理与 TLS SNI 或 HTTP 主机标头非常相似 - 发起方说“我是 <leftid>，我想与 <rightid> 对话”，响应方尝试找到配置匹配这些 ID（作为 leftid/rightid 或 rightid/leftid）。

但目前您定义的连接的 ID 彼此完全不匹配 - 例如 VM2 声称是，但 VM1由于某种原因被配置为请求：1.2.3.51.2.4.5

虚拟机 1 虚拟机 2
------------------- -------------------
连接网关-1 连接网关-2
    leftid=1.2.3.4 /--     leftid=1.2.3.5
    rightid=1.2.4.5   --/ rightid=1.2.4.4

（请注意，ID 仅用于匹配，因此它们实际上不需要采用 IP 地址格式 - 如果使用域格式的 ID，可能会更容易理解这一点，例如leftid=gateway1.example.com。）

请注意，strongSwan 不再推荐 ipsec.conf 样式；您应该借此机会为 swanctl 重写它。

相关内容