strongSwan安装,双方都在NAT后面

我正在尝试在家中安装一个strongSwan服务器,并从另一个networking连接到它。 假设sun是VPN服务器, venus是客户端。 sunvenus都在NATnetworking之后。 sun不是我的家庭networking的门户。 但是,端口4500,500和50(UDP)被转发到sun

ipsec.conf(sun)

 # 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(venus)

 # 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=xxxx # 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这是我尝试连接时发生的情况:

太阳(yyyy是维纳斯的公共知识产权):

 13[NET] received packet: from yyyy[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] yyyy 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 yyyy[500] 14[IKE] sending keep alive 14[NET] sending packet: from 10.135.1.200[500] to yyyy[500] 15[JOB] deleting half open IKE_SA after timeout 

金星(xxxx是Sun的公共知识产权)

 13[IKE] initiating IKE_SA krustykrab[1] to xxxx 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 xxxx[500] 14[NET] received packet: from xxxx[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 xxxx[4500] 09[IKE] retransmit 1 of request with message ID 1 09[NET] sending packet: from 192.168.10.200[4500] to xxxx[4500] 10[IKE] retransmit 2 of request with message ID 1 10[NET] sending packet: from 192.168.10.200[4500] to xxxx[4500] 11[IKE] retransmit 3 of request with message ID 1 11[NET] sending packet: from 192.168.10.200[4500] to xxxx[4500] 14[IKE] sending keep alive 14[NET] sending packet: from 192.168.10.200[4500] to xxxx[4500] 15[IKE] retransmit 4 of request with message ID 1 15[NET] sending packet: from 192.168.10.200[4500] to xxxx[4500] 10[IKE] sending keep alive 10[NET] sending packet: from 192.168.10.200[4500] to xxxx[4500] 12[IKE] sending keep alive 12[NET] sending packet: from 192.168.10.200[4500] to xxxx[4500] 11[IKE] retransmit 5 of request with message ID 1 11[NET] sending packet: from 192.168.10.200[4500] to xxxx[4500] 

金星tcpdump:

 16:57:42.389799 IP 192.168.10.200.500 > xxxx500: isakmp: parent_sa ikev2_init[I] 16:57:42.465073 IP xxxx500 > 192.168.10.200.500: isakmp: parent_sa ikev2_init[R] 16:57:42.712016 IP 192.168.10.200.4500 > xxxx4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:57:42.712057 IP 192.168.10.200 > xxxx: ip-proto-17 16:57:46.712854 IP 192.168.10.200.4500 > xxxx4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:57:46.712911 IP 192.168.10.200 > xxxx: ip-proto-17 16:57:53.913742 IP 192.168.10.200.4500 > xxxx4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:57:53.913799 IP 192.168.10.200 > xxxx: ip-proto-17 16:58:02.458669 IP xxxx500 > 192.168.10.200.500: [|isakmp] 16:58:06.874834 IP 192.168.10.200.4500 > xxxx4500: NONESP-encap: isakmp: child_sa ikev2_auth[I] 16:58:06.874884 IP 192.168.10.200 > xxxx: ip-proto-17 

Sun的tcpdump:

 16:59:06.521762 IP yyyy500 > 10.135.1.200.500: isakmp: parent_sa ikev2_init[I] 16:59:06.556423 IP 10.135.1.200.500 > yyyy500: isakmp: parent_sa ikev2_init[R] 16:59:26.556324 IP 10.135.1.200.500 > yyyy500: [|isakmp] 

sun似乎并没有在4500端口获取数据包,这很奇怪,因为我在venus打开了一个Python解释器,input:

 In [1]: from socket import * In [2]: x = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) In [3]: x.sendto('', ('xxxx', 4500)) Out[3]: 0 

包被收到了:

 17:02:45.246769 IP yyyy44335 > 10.135.1.200.4500: [|isakmp] 

我也试过设置

 port_nat_t = 6000 

在双方charon部分,但他们仍然尝试使用港口4500

由于证书和证书请求, IKE_AUTH消息可能会变得非常大,以至于它们必须在IP层上分片(可以在venustcpdump捕获中看到这些片段)。 也许在sun的NAT盒子有问题重新组装碎片包或只是丢弃它们。

作为一种解决方法,您可以尝试在两侧安装两个对等方的证书,然后相应地configurationrightcert ,使其指向包含另一个对等方证书的文件。

完成后,您可以在两端configurationrightsendcert=never ,以避免发送证书请求。 因为leftsendcert默认为ifasked对等体最终不会发送他们的证书和消息的大小应该足够小,以避免IP分片。

顺便说一下,你不必打开UDP端口50.没有NAT遍历,你需要允许IP 协议 50(ESP),但是如果涉及到一个NAT,ESP数据包得到UDP封装,所以打开UDP端口500和4500是足够。