我正在尝试在家中设置 strongSwan 服务器并从另一个网络连接到它。假设sun是 VPN 服务器，venus是客户端。sun和venus都位于 NAT 网络后面。sun不是我家网络的网关。但是，端口 4500、500 和 50 (UDP) 被转发到sun。
ipsec.conf（太阳）
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
charonstart=yes
plutostart=no
conn venus
left=%any
leftcert=sunCert.pem
right=%any
leftsubnet=10.135.1.0/24
rightid="C=IL, O=KrustyKrab, CN=venus"
keyexchange=ikev2
auto=add
type=tunnel
mobike=no
include /var/lib/strongswan/ipsec.conf.inc
ipsec.conf（金星）
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
charonstart=yes
plutostart=no
conn krustykrab
left=%defaultroute
leftsourceip=%config
leftid="C=IL, O=KrustyKrab, CN=venus"
leftcert=venusCert.pem
right=x.x.x.x # My home public IP
rightsubnet=10.135.1.0/24
rightid="C=IL, O=KrustyKrab, CN=sun"
keyexchange=ikev2
auto=start
type=tunnel
mobike=no
# include /var/lib/strongswan/ipsec.conf.inc
Sun 的私有 IP 是 10.135.1.200，Venus 的私有 IP 是 192.168.10.200 当我尝试连接时发生的情况如下：
Sun（yyyy 是 Venus 的公网 IP）：
13[NET] received packet: from y.y.y.y[500] to 10.135.1.200[500]
13[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
13[IKE] y.y.y.y is initiating an IKE_SA
13[IKE] local host is behind NAT, sending keep alives
13[IKE] remote host is behind NAT
13[IKE] sending cert request for "C=IL, O=KrustyKrab, CN=KrustyKrab CA"
13[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
13[NET] sending packet: from 10.135.1.200[500] to y.y.y.y[500]
14[IKE] sending keep alive
14[NET] sending packet: from 10.135.1.200[500] to y.y.y.y[500]
15[JOB] deleting half open IKE_SA after timeout
Venus（xxxx 是 Sun 的公共 IP）
13[IKE] initiating IKE_SA krustykrab[1] to x.x.x.x
13[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
13[NET] sending packet: from 192.168.10.200[500] to x.x.x.x[500]
14[NET] received packet: from x.x.x.x[500] to 192.168.10.200[500]
14[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(MULT_AUTH) ]
14[IKE] local host is behind NAT, sending keep alives
14[IKE] remote host is behind NAT
14[IKE] received cert request for "C=IL, O=KrustyKrab, CN=KrustyKrab CA"
14[IKE] sending cert request for "C=IL, O=KrustyKrab, CN=KrustyKrab CA"
14[IKE] authentication of 'C=IL, O=KrustyKrab, CN=venus' (myself) with RSA signature successful
14[IKE] sending end entity cert "C=IL, O=KrustyKrab, CN=venus"
14[IKE] establishing CHILD_SA krustykrab
14[ENC] generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CP(ADDR DNS) SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) ]
14[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
09[IKE] retransmit 1 of request with message ID 1
09[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
10[IKE] retransmit 2 of request with message ID 1
10[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
11[IKE] retransmit 3 of request with message ID 1
11[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
14[IKE] sending keep alive
14[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
15[IKE] retransmit 4 of request with message ID 1
15[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
10[IKE] sending keep alive
10[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
12[IKE] sending keep alive
12[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
11[IKE] retransmit 5 of request with message ID 1
11[NET] sending packet: from 192.168.10.200[4500] to x.x.x.x[4500]
Venus 中的 tcpdump：
16:57:42.389799 IP 192.168.10.200.500 > x.x.x.x.500: isakmp: parent_sa ikev2_init[I]
16:57:42.465073 IP x.x.x.x.500 > 192.168.10.200.500: isakmp: parent_sa ikev2_init[R]
16:57:42.712016 IP 192.168.10.200.4500 > x.x.x.x.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
16:57:42.712057 IP 192.168.10.200 > x.x.x.x: ip-proto-17
16:57:46.712854 IP 192.168.10.200.4500 > x.x.x.x.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
16:57:46.712911 IP 192.168.10.200 > x.x.x.x: ip-proto-17
16:57:53.913742 IP 192.168.10.200.4500 > x.x.x.x.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
16:57:53.913799 IP 192.168.10.200 > x.x.x.x: ip-proto-17
16:58:02.458669 IP x.x.x.x.500 > 192.168.10.200.500: [|isakmp]
16:58:06.874834 IP 192.168.10.200.4500 > x.x.x.x.4500: NONESP-encap: isakmp: child_sa ikev2_auth[I]
16:58:06.874884 IP 192.168.10.200 > x.x.x.x: ip-proto-17
Sun 中的 tcpdump：
16:59:06.521762 IP y.y.y.y.500 > 10.135.1.200.500: isakmp: parent_sa ikev2_init[I]
16:59:06.556423 IP 10.135.1.200.500 > y.y.y.y.500: isakmp: parent_sa ikev2_init[R]
16:59:26.556324 IP 10.135.1.200.500 > y.y.y.y.500: [|isakmp]
似乎sun没有在端口 4500 中获取数据包，这很奇怪，因为我打开了 Python 解释器venus并输入：
In [1]: from socket import *
In [2]: x = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)
In [3]: x.sendto('', ('x.x.x.x', 4500))
Out[3]: 0
并且收到了数据包：
17:02:45.246769 IP y.y.y.y.44335 > 10.135.1.200.4500: [|isakmp]
我也尝试设置
port_nat_t = 6000
在charon两边的部分，但他们仍然尝试使用端口 4500
答案1
由于证书和证书请求IKE_AUTH消息可能变得非常大，以至于必须在 IP 层对其进行分段（您可以在 处的tcpdump捕获中看到这些分段venus）。 处的 NAT 盒可能在sun重组分段数据包时遇到问题，或者只是丢弃了它们。
作为一种解决方法，您可以尝试在两侧安装两个对等方的证书，然后进行rightcert相应配置，使其指向包含另一方证书的文件。
完成此操作后，您可以rightsendcert=never在两端进行配置，以避免发送证书请求。因为leftsendcert默认情况下，对ifasked等方最终不会发送其证书，并且消息大小应该足够小以避免 IP 碎片。
顺便说一句，你不必打开 UDP 端口 50。如果没有 NAT 穿越，你需要允许 IP协议50（ESP），但如果涉及 NAT，ESP 数据包将被 UDP 封装，因此打开 UDP 端口 500 和 4500 就足够了。