我在 Ubuntu 18.04 服务器上设置了一个 StrongSwan VPN 服务器，它运行良好。我能够从 Windows 10 和 macOS 连接到此 VPN，一切运行良好。问题是我无法让 Linux 使用 StrongSwan 客户端连接到同一 VPN 服务器。
Linux 客户端只是一个公路战士场景，我使用 charon-cmd 来建立按需 VPN 连接，如下所示：
root@ubuntu:~# charon-cmd --cert DigiCertCA.crt --host vpn.example.com --identity <myuser>
00[LIB] created TUN device: ipsec0
00[LIB] dropped capabilities, running as uid 0, gid 0
00[DMN] Starting charon-cmd IKE client (strongSwan 5.3.5, Linux 4.4.0-142-generic, x86_64)
00[LIB] loaded plugins: charon-cmd aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 sshkey pem openssl fips-prf gmp agent xcbc hmac ccm gcm kernel-libipsec kernel-netlink resolve socket-default eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic
00[JOB] spawning 16 worker threads
15[IKE] initiating IKE_SA cmd[1] to XX.YYY.199.103
15[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
15[NET] sending packet: from 192.168.1.29[60971] to XX.YYY.199.103[4500] (1256 bytes)
16[NET] received packet: from XX.YYY.199.103[4500] to 192.168.1.29[60971] (38 bytes)
16[ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
16[IKE] peer didn't accept DH group MODP_2048, it requested MODP_3072
16[IKE] initiating IKE_SA cmd[1] to XX.YYY.199.103
16[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
16[NET] sending packet: from 192.168.1.29[60971] to XX.YYY.199.103[4500] (1384 bytes)
05[NET] received packet: from XX.YYY.199.103[4500] to 192.168.1.29[60971] (584 bytes)
05[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) N(MULT_AUTH) ]
05[IKE] local host is behind NAT, sending keep alives
05[IKE] remote host is behind NAT
05[IKE] establishing CHILD_SA cmd
05[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) ]
05[NET] sending packet: from 192.168.1.29[50969] to XX.YYY.199.103[4500] (304 bytes)
04[NET] received packet: from XX.YYY.199.103[4500] to 192.168.1.29[50969] (3408 bytes)
04[ENC] parsed IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID N(AUTH_FOLLOWS) ]
04[IKE] received end entity cert "C=US, ST=Massachusetts, L=Needham Heights, O=Example Corporation, CN=*.example.com"
04[IKE] received issuer cert "C=US, O=DigiCert Inc, CN=DigiCert TLS RSA SHA256 2020 CA1"
04[IKE] no trusted RSA public key found for '10.1.1.4'
04[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
04[NET] sending packet: from 192.168.1.29[50969] to XX.YYY.199.103[4500] (80 bytes)
请注意，上述日志末尾附近的错误是“未找到 10.1.1.4 的可信 RSA 公钥”。该 IP 地址是 StrongSwan 服务器计算机的 NAT 化“内部”IP 地址。同一台计算机的面向公众的 IP 地址是 XX.YY.199.103。
在 charon-cmd 命令行上，我指定 --cert DigiCertCA.crt，因为这是来自为该服务器颁发主要证书的 CA 的中间证书。
我已经在 Google 上搜索了错误“未找到 (IP-addr) 的受信任 RSA 公钥”，并找到了一些讨论，但到目前为止，这些建议都对我没用。有人能帮我解决这个问题吗？我已经重新颁发了证书，其 SAN 名称与客户端用于连接的名称完全匹配，因为我知道 StrongSwan 通常不喜欢通配符证书。但添加 SAN 名称并没有帮助。
这是 StrongSwan 的服务器端配置。请记住，从 Windows 10 和 macOS 连接时，所有这些服务器配置都可以正常工作。
服务器端文件：/etc/ipsec.conf
config setup
charondebug="ike 1, knl 1, cfg 0"
uniqueids=no
conn ikev2-vpn
auto=add
ike=aes256-aes128-sha256-sha1-modp3072-modp2048-modp1024
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
dpdaction=clear
dpddelay=300s
rekey=no
left=%any
leftid=@*.example.com
leftcert=example_com.crt
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
rightauth=eap-mschapv2
rightsourceip=10.10.1.0/16
rightdns=8.8.8.8,8.8.4.4
rightsendcert=never
eap_identity=%identity
服务器证书（真实域名在本讨论中更改为 example.com，但其他一切都完全相同）。请注意，这是一个通配符证书，其中“CN”名称带有星号。但是，还请注意，有一个 SAN（主题备用名称），其名称与我从客户端到达服务器时使用的完全相同，在本例中为 vpn.example.com。
root@base:/etc/ipsec.d/certs# openssl x509 -in example_com.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
09:11:4c:4d:84:9b:3a:c4:16:31:d8:4b:12:52:1b:0f
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1
Validity
Not Before: Apr 22 00:00:00 2021 GMT
Not After : May 23 23:59:59 2022 GMT
Subject: C = US, ST = Massachusetts, L = Needham Heights, O = Example Corporation, CN = *.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:af:76:1f:f6:9a:e4:a5:2f:12:f1:e3:80:de:46:
4e:61:39:17:87:9d:d0:d5:13:9a:2e:8d:aa:cb:2a:
1c:28:8e:27:27:54:df:bb:c9:2a:fb:74:a1:b0:96:
1c:21:3d:26:8f:63:03:1b:45:36:6b:a3:46:07:dd:
44:6e:a6:db:e5:db:e5:4d:5f:e2:5a:21:5e:d4:a2:
d6:02:11:71:4b:89:8e:93:dd:d2:ef:13:b2:55:74:
d4:eb:e1:ad:ec:70:76:b3:8b:a8:f0:ae:60:39:f2:
1e:5b:f6:a7:a6:e3:ad:b5:8c:6b:a5:25:fa:fc:ac:
05:03:16:ab:77:37:d4:14:8c:28:46:9e:37:f7:d9:
3c:63:4e:a5:ea:e7:14:0c:46:e9:43:4b:45:f9:f6:
8f:6c:db:6d:da:9b:1d:98:d5:e3:dd:be:a2:8f:2a:
d2:66:e6:92:38:49:aa:e4:4b:52:8b:c2:28:79:f6:
32:94:99:56:78:5a:b3:c3:98:cd:f8:fd:2b:37:e8:
25:ae:5b:31:43:82:42:d2:35:95:c3:53:d0:31:09:
da:61:23:4c:08:42:68:08:50:d2:ef:26:60:5d:01:
9f:6f:ed:25:40:02:98:29:e9:19:bf:7f:98:b5:45:
4c:c8:5d:1d:8f:31:da:bc:de:42:45:ed:51:2e:da:
7f:5d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:B7:6B:A2:EA:A8:AA:84:8C:79:EA:B4:DA:0F:98:B2:C5:95:76:B9:F4
X509v3 Subject Key Identifier:
E2:30:0F:0F:D7:96:0B:BE:4A:19:55:54:2B:D4:1A:2F:E9:11:40:A3
X509v3 Subject Alternative Name:
DNS:*.example.com, DNS:example.com, DNS:vpn.example.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/DigiCertTLSRSASHA2562020CA1.crl
Full Name:
URI:http://crl4.digicert.com/DigiCertTLSRSASHA2562020CA1.crl
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.2
CPS: http://www.digicert.com/CPS
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertTLSRSASHA2562020CA1.crt
X509v3 Basic Constraints: critical
CA:FALSE
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 46:A5:55:EB:75:FA:91:20:30:B5:A2:89:69:F4:F3:7D: 11:2C:41:74:BE:FD:49:B8:85:AB:F2:FC:70:FE:6D:47
Timestamp : Apr 22 20:58:13.047 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:44:02:20:55:BC:68:21:95:C6:A7:AF:82:B9:BC:C3:
2B:82:49:E5:F9:88:EA:90:96:8B:27:17:4A:5D:E1:B3:
F2:D3:03:92:02:20:0D:24:0B:20:5D:17:F6:5A:F9:67:
5B:A4:67:A2:64:8F:F4:9C:F7:95:A2:30:BE:AC:69:57:
EB:3F:2D:EC:70:7E
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 22:45:45:07:59:55:24:56:96:3F:A1:2F:F1:F7:6D:86: E0:23:26:63:AD:C0:4B:7F:5D:C6:83:5C:6E:E2:0F:02
Timestamp : Apr 22 20:58:12.955 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:21:00:AC:04:98:CB:33:16:0A:5E:A6:83:AA:
20:BB:B2:15:00:73:6B:BA:B6:DD:AB:8C:BF:4E:09:42:
43:AF:BF:CA:7F:02:20:23:29:7D:F7:3E:6F:C5:70:CE:
8F:E1:40:B7:F9:84:39:29:D0:06:12:7B:58:4A:11:D9:
8A:14:60:D1:CF:51:3A
Signed Certificate Timestamp:
Version : v1 (0x0)
Log ID : 41:C8:CA:B1:DF:22:46:4A:10:C6:A1:3A:09:42:87:5E: 4E:31:8B:1B:03:EB:EB:4B:C7:68:F0:90:62:96:06:F6
Timestamp : Apr 22 20:58:12.964 2021 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:15:E7:1D:C7:A4:61:33:A8:41:91:42:FD:
53:31:98:AB:ED:20:07:12:2A:FA:D7:AA:86:67:44:88:
29:41:7A:6B:02:21:00:EE:1A:9C:7E:80:30:1E:26:D3:
6E:2A:BF:32:C9:46:AB:C3:F1:9D:85:F8:71:B9:75:D9:
1F:DE:86:58:84:C1:32
Signature Algorithm: sha256WithRSAEncryption
46:80:80:28:cf:e2:95:e4:1e:ef:40:12:fb:c8:d9:5b:57:1e:
cd:b1:8c:94:11:87:ec:09:b7:43:57:27:79:f6:61:38:86:ba:
3b:f7:b9:16:79:b4:c9:86:d5:cf:d8:49:9e:ec:a1:a1:d5:1d:
e0:6c:9d:38:71:6c:f6:f2:90:3a:88:18:cc:6d:d1:c0:90:2d:
bb:e4:96:be:e6:b3:cb:04:af:09:6c:e5:b9:17:e7:6d:45:1e:
42:c5:eb:ef:e2:3f:91:55:76:39:1b:2c:75:12:d9:a1:bd:2e:
bc:18:f8:e8:ed:f4:be:75:5b:c6:0d:6a:ec:6a:3d:15:d9:7c:
35:5d:98:46:bf:10:d7:56:7b:a2:55:23:29:21:3c:2e:3e:6f:
39:0f:0d:a0:a6:3e:3d:9c:70:b9:0c:ce:92:2b:7b:ca:bb:67:
97:1e:1a:a8:08:c7:54:b4:96:79:00:32:9b:50:b5:1f:09:d9:
ab:be:aa:42:1d:68:a1:87:a1:26:36:a4:f4:c7:56:27:20:72:
c6:f5:f6:47:ee:ac:9e:b3:03:9e:95:0e:f0:61:cb:a6:75:71:
11:c6:ee:fb:44:08:e1:25:3c:77:9a:99:97:2a:62:56:54:99:
8e:3d:a7:4b:cc:20:38:23:d5:c5:b5:9f:67:0f:c8:6c:5f:f2:
f2:6d:e4:32
来自 DigiCert 的 CA 证书。我在客户端有此证书的副本，并在“charon-cmd”的 --cert 参数中指定此文件。
root@base:/etc/ipsec.d/cacerts# openssl x509 -in DigiCertCA.crt -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0a:35:08:d5:5c:29:2b:01:7d:f8:ad:65:c0:0f:f7:e4
Signature Algorithm: sha256WithRSAEncryption
Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
Validity
Not Before: Sep 24 00:00:00 2020 GMT
Not After : Sep 23 23:59:59 2030 GMT
Subject: C = US, O = DigiCert Inc, CN = DigiCert TLS RSA SHA256 2020 CA1 Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:c1:4b:b3:65:47:70:bc:dd:4f:58:db:ec:9c:ed:
c3:66:e5:1f:31:13:54:ad:4a:66:46:1f:2c:0a:ec:
64:07:e5:2e:dc:dc:b9:0a:20:ed:df:e3:c4:d0:9e:
9a:a9:7a:1d:82:88:e5:11:56:db:1e:9f:58:c2:51:
e7:2c:34:0d:2e:d2:92:e1:56:cb:f1:79:5f:b3:bb:
87:ca:25:03:7b:9a:52:41:66:10:60:4f:57:13:49:
f0:e8:37:67:83:df:e7:d3:4b:67:4c:22:51:a6:df:
0e:99:10:ed:57:51:74:26:e2:7d:c7:ca:62:2e:13:
1b:7f:23:88:25:53:6f:c1:34:58:00:8b:84:ff:f8:
be:a7:58:49:22:7b:96:ad:a2:88:9b:15:bc:a0:7c:
df:e9:51:a8:d5:b0:ed:37:e2:36:b4:82:4b:62:b5:
49:9a:ec:c7:67:d6:e3:3e:f5:e3:d6:12:5e:44:f1:
bf:71:42:7d:58:84:03:80:b1:81:01:fa:f9:ca:32:
bb:b4:8e:27:87:27:c5:2b:74:d4:a8:d6:97:de:c3:
64:f9:ca:ce:53:a2:56:bc:78:17:8e:49:03:29:ae:
fb:49:4f:a4:15:b9:ce:f2:5c:19:57:6d:6b:79:a7:
2b:a2:27:20:13:b5:d0:3d:40:d3:21:30:07:93:ea:
99:f5
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
B7:6B:A2:EA:A8:AA:84:8C:79:EA:B4:DA:0F:98:B2:C5:95:76:B9:F4
X509v3 Authority Key Identifier:
keyid:03:DE:50:35:56:D1:4C:BB:66:F0:A3:E2:1B:1B:C3:97:B2:3D:D1:55
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertGlobalRootCA.crt
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/DigiCertGlobalRootCA.crl
Full Name:
URI:http://crl4.digicert.com/DigiCertGlobalRootCA.crl
X509v3 Certificate Policies:
Policy: 2.23.140.1.1
Policy: 2.23.140.1.2.1
Policy: 2.23.140.1.2.2
Policy: 2.23.140.1.2.3
Signature Algorithm: sha256WithRSAEncryption
77:ab:b7:7a:27:3d:ae:bb:f6:7f:e0:5a:56:c9:84:aa:ca:5b:
71:17:dd:22:47:fc:4e:9f:ee:d0:c1:a4:04:e1:a3:eb:c5:49:
c1:fd:d1:c9:df:8c:af:94:45:2c:46:2a:a3:63:39:20:f9:9e:
4a:24:94:41:c8:a9:d9:e2:9c:54:05:06:cb:5c:1c:be:00:1b:
0f:a8:5a:ff:19:bb:65:c7:16:af:21:56:dd:61:05:c9:e9:8f:
98:76:df:6b:1b:d0:72:0c:50:b9:30:29:7a:bf:60:59:10:66:
13:3a:2d:ac:15:11:6c:2d:23:0c:02:3e:05:3b:fe:e5:a1:9c:
e2:8a:db:87:d7:4a:e8:5e:e7:48:06:eb:ab:12:9a:f2:af:84:
c3:5b:83:4a:99:81:83:ab:00:a1:ca:0a:3c:4c:a2:25:89:2a:
22:a7:a4:f3:33:4c:5b:8c:2e:1a:02:97:0f:9d:8f:6d:2d:95:
08:fb:4f:da:f1:91:38:25:e1:9c:6e:61:18:87:6a:ce:b1:bb:
00:30:6a:9b:b7:af:da:f1:c5:97:fe:8a:78:24:aa:ea:93:80:
ba:33:65:7a:bc:a1:77:e9:7f:69:14:0b:00:3f:77:92:b1:4d:
5b:73:87:0a:13:d0:9c:c8:f2:4b:39:4f:52:84:49:a6:4c:90:
4e:1f:f7:b4
答案1
那么对于将来遇到此问题的人来说，解决方案是修改 /etc/ipsec.conf 文件如下：
config setup
charondebug="ike 1, knl 1, cfg 0"
uniqueids=no
conn ikev2-vpn
auto=add
ike=aes256-aes128-sha256-sha1-modp3072-modp2048-modp1024
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
dpdaction=clear
dpddelay=300s
rekey=no
left=%any
leftid=vpn.example.com
leftcert=example_com.crt
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
rightauth=eap-mschapv2
rightsourceip=10.10.1.0/16
rightdns=8.8.8.8,8.8.4.4
rightsendcert=never
eap_identity=%identity
我猜 StrongSwan 对“leftid”参数非常挑剔——它必须与证书的 SAN 名称中的内容完全匹配，并且必须与 charon-cmd 的 --host 参数中的内容完全匹配。
如果 StrongSwan 有一条日志消息告诉你就好了为什么“未找到 10.1.1.4 的可信 RSA 公钥”。相反，它需要数小时的反复试验和在黑暗中摸索，随机尝试这做那。