站点到站点与AWS的OpenSWAN VPN隧道问题

我们在两个AWS地区和我们的科罗拉多州的COLO设施之间有一个Openswan的VPN隧道(使用AWS的指南: http : //aws.amazon.com/articles/5472675506466066 )。 正常使用正常(ssh等),但是我们在所有区域之间的隧道上有一些MySQL问题。 在linux服务器上使用mysql命令行客户端,并试图使用MySQL连接器J连接,它基本上停顿…它似乎打开连接,但后来卡住了。 它不会被拒绝或任何东西,只是挂在那里。

经过最初的研究认为这是一个MTU的问题,但我已经搞砸了很多,没有运气。

与服务器的连接工作正常,我们可以select一个数据库来使用,但是使用Java连接器,看起来Java查询语句后Java客户端没有收到任何networkingstream量。

当在linux上的MySQL客户端上运行一个select时,我们可以在死亡之前得到最多2或3行。

有了这个说法,我还在AWS端有一个单独的openswan VPN用于客户端(mac和iOS)VPN连接。 一切都通过客户端VPN非常有效地运作,而且一般来说似乎更稳定。 我注意到的主要区别是静态连接使用“隧道”作为types和客户端使用“传输”,但是当切换静态隧道连接传输它说,有30个打开的连接,并不起作用。

我对OpenSWAN很陌生,所以希望有人可以帮助我指出正确的方向来获得静态隧道工作以及客户端VPN。

一如既往,这是我的configuration文件:

两个静态隧道服务器的ipsec.conf:

# basic configuration config setup # Debug-logging controls: "none" for (almost) none, "all" for lots. # klipsdebug=none # plutodebug="control parsing" # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey protostack=netkey nat_traversal=yes virtual_private= oe=off # Enable this if you see "failed to find any available worker" # nhelpers=0 #You may put your configuration (.conf) file in the "/etc/ipsec.d/" and uncomment this. include /etc/ipsec.d/*.conf 

VPC1到colo隧道conf

 conn vpc1-to-DT type=tunnel authby=secret left=%defaultroute leftid=54.213.24.xxx leftnexthop=%defaultroute leftsubnet=10.1.4.0/24 right=72.26.103.xxx rightsubnet=10.1.2.0/23 pfs=yes auto=start 

colo-to-VPC1隧道configuration

 conn DT-to-vpc1 type=tunnel authby=secret left=%defaultroute leftid=72.26.103.xxx leftnexthop=%defaultroute leftsubnet=10.1.2.0/23 right=54.213.24.xxx rightsubnet=10.1.4.0/24 pfs=yes auto=start 

客户点VPN ipsec.conf

 # basic configuration config setup interfaces=%defaultroute klipsdebug=none nat_traversal=yes nhelpers=0 oe=off plutodebug=none plutostderrlog=/var/log/pluto.log protostack=netkey virtual_private=%v4:10.1.4.0/24 conn L2TP-PSK authby=secret pfs=no auto=add keyingtries=3 rekey=no type=transport forceencaps=yes right=%any rightsubnet=vhost:%any,%priv rightprotoport=17/0 # Using the magic port of "0" means "any one single port". This is # a work around required for Apple OSX clients that use a randomly # high port, but propose "0" instead of their port. left=%defaultroute leftprotoport=17/1701 # Apple iOS doesn't send delete notify so we need dead peer detection # to detect vanishing clients dpddelay=10 dpdtimeout=90 dpdaction=clear 

找到解决方案。 需要在两端添加以下IP表规则:

iptables -t mangle -I POSTROUTING -p tcp -tcp-flags SYN,RST SYN -j TCPMSS –clamp-mss-to-pmtu

随着1400的MTU,我们看起来非常稳固

我们对从欧盟地区到美国RDS实例的服务器也有同样的问题。 这似乎是RDS实例未响应自动发现MTU设置所需的ICMP的已知问题。 作为一种解决方法,您需要在执行查询的实例上配置较小的MTU。

在连接到RDS实例(而不是VPN通道实例)的服务器上,运行以下命令以获取1422的MTU设置(适用于我们):

 sudo ifconfig eth0 mtu 1422