站点间的OpenSWAN VPN隧道问题

Question

我们在两个AWS区域和我们的colo设施之间有一个带有Openswan的VPN隧道(使用AWS的指南：http://aws.amazon.com/articles/5472675506466066)。常规使用可以正常工作(ssh等)，但是我们在所有区域之间的隧道上遇到了一些MySQL问题。使用linux服务器上的mysql命令行客户端并尝试使用MySQL连接器J进行连接，它基本上阻止了…它似乎打开了连接，但后来被卡住了。它没有被否认什么的，只是挂在那里。

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

连接到服务器可以正常工作，我们可以选择要使用的数据库等等，但是使用Java连接器，似乎在查询之后Java客户端没有接收到任何网络流量。

当在linux上的MySQL客户机中运行select时，我们可以在它死前得到最多2或3行。

尽管如此，我还在AWS端为客户端(mac和iOS) VPN连接提供了一个单独的开放虚拟专用网。所有的东西都通过客户端VPN出色地工作，而且总体上看起来更稳定。我注意到的主要区别是静态连接使用“隧道”作为类型，而客户端使用“传输”，但是当将静态隧道连接切换到传输时，表示有大约30个打开的连接，不能工作。

我对OpenSWAN非常陌生，所以希望有人能帮助我找到正确的方向，让静态隧道和客户端VPN一起工作。

与往常一样，下面是我的配置文件：

两个静态隧道服务器的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 1-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 1隧道孔洞

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

Answer 1

找到了解决办法。需要在两端添加以下IP表规则：

iptables -t mangle POSTROUTING -p tcp -tcp-标志SYN RST SYN -j TCPMSS线夹-mss

这个和1400的MTU一起，我们看起来很坚固

Answer 2

在从欧盟地区连接到美国的一个RDS实例时，我们也遇到了同样的问题。这似乎是一个已知的问题，RDS实例没有响应ICMP，这是自动发现MTU设置所必需的。作为解决办法，您需要在执行查询的实例上配置一个更小的MTU。

在连接到RDS实例(而不是VPN隧道实例)的服务器上，运行以下命令以获得MTU设置为1422 (对我们有效)：

sudo ifconfig eth0 mtu 1422