AWS 的站点到站点 OpenSWAN *** 隧道问题

Posted 2023-02-22

【中文标题】AWS 的站点到站点 OpenSWAN *** 隧道问题

【英文标题】：Site to site OpenSWAN *** tunnel issues with AWS

【发布时间】：2014-03-12 18:42:21

【问题描述】：

我们在两个 AWS 区域和我们的托管设施之间使用 Openswan 建立了 *** 隧道（使用 AWS 的指南：http://aws.amazon.com/articles/5472675506466066）。常规使用工作正常（ssh 等），但我们在所有区域之间的隧道上遇到了一些 mysql 问题。在 linux 服务器上使用 mysql 命令行客户端并尝试使用 MySQL Connector J 进行连接，它基本上会停止……它似乎打开了连接，但随后卡住了。它没有被拒绝或任何东西，只是挂在那里。

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

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

在 Linux 上的 MySQL 客户端中运行 select 时，我们最多可以得到 2 或 3 行，然后它就会死掉。

话虽如此，我在 AWS 端也有一个单独的 openswan ***，用于客户端（mac 和 ios）*** 连接。一切都通过客户端 *** 运行得非常好，而且总体上看起来更稳定。我注意到的主要区别是静态连接使用“隧道”作为类型，而客户端使用“传输”，但是当将静态隧道连接切换为传输时，它说有 30 个打开的连接并且不起作用.

我是 OpenSWAN 的新手，所以希望有人能帮助我指出正确的方向，让静态隧道和客户端 *** 一样正常工作。

和往常一样，这是我的配置文件：

两个静态隧道服务器的 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 隧道配置

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 隧道配置

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

客户端 *** 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

【问题讨论】：

推测：通往 MySQL 服务器的反向流量的安全组不允许来自 0.0.0.0/0 的 ICMP，可能会破坏路径 MTU 发现。 en.m.wikipedia.org/wiki/Path_MTU_discovery#Problems_with_PMTUD

【参考方案1】：

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

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

加上 1400 的 MTU，我们看起来非常稳定

【讨论】：

据我了解， --clamp-mss-to-pmtu 自动计算最大段大小，我不知道具体是什么。无论如何，事实证明它并不总是有效。我需要使用选项 --set-mss 和我发现尝试的值来静态强制它，直到它起作用。

【参考方案2】：

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

在与 RDS 实例（不是 *** 隧道实例）建立连接的服务器上，运行以下命令以获取 1422 的 MTU 设置（这对我们有用）：

sudo ifconfig eth0 mtu 1422

【讨论】：

这对我来说适用于同样的问题，但我仍然不明白为什么降低客户端的 MTU 大小可以解决问题，一旦问题（如 tcpdump 所示）实际上是响应包大小（在我的例子中是一个弹性缓存节点）。