我们在两个AWS区域和我们的colo工具之间有一个带有Openswan的VPN隧道（使用AWS的指南：http://aws.amazon.com/articles/5472675506466066） . 常规使用工作正常（ssh等），但我们在所有区域之间的隧道上遇到了一些MySQL问题 . 在Linux服务器上使用mysql命令行客户端并尝试使用MySQL Connector J进行连接它基本上会停止...它似乎打开了连接，但随后被卡住了 . 它不会被拒绝或任何东西，只是挂在那里 .
在最初的研究认为这是一个MTU问题，但我已经搞砸了很多，没有运气 .
与服务器的连接工作正常，我们可以选择要使用的数据库等，但是使用Java连接器后，看起来Java客户端在进行查询后没有收到任何网络流量 .
当在linux上的MySQL客户端中运行select时，我们可以在它死之前获得最多2或3行 .
有了这个说法，我还在AWS端有一个单独的openswan VPN，用于客户端（mac和iOS）vpn连接 . 一切都通过客户端VPN很好地工作，一般看起来更稳定 . 我注意到的主要区别是静态连接使用“隧道”作为类型，客户端使用“传输”，但是当将静态隧道连接切换到传输时，它说有30个打开的连接并且不起作用 .
我对OpenSWAN很新，所以希望有人可以帮我指出让静态隧道正常工作以及客户端VPN的正确方向 .
和往常一样，这是我的配置文件：
ipsec.conf for BOTH static tunnel servers:
# 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-to-colo tunnel 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 tunnel conf
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
Client point 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
2 回答
找到了解决方案 . 需要在两端添加以下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隧道实例） Build 连接的服务器上，运行以下命令以获得1422的MTU设置（这对我们有用）：