☰

Ipsec VPN 到 AWS：无法 ping 隧道内的 AWS 端

tag-icon • tag-icon ubuntu amazon-web-services vpn ipsec strongswan
Ipsec VPN 到 AWS：无法 ping 隧道内的 AWS 端

摘要：我认为我的 Ubuntu 服务器上缺少一些使用 Strongswan Ipsec 连接到 AWS VPN 的路由。您知道我的服务器上需要哪些路由吗？

我正在尝试设置从服务器到 AWS 的 BGP 路由 VPN。我曾使用静态路由 VPN 进行此操作，因此我知道我的 AWS 端和 ipsec 是正确的。但是，BGP 很棘手。

我在 Ubuntu 上使用 Strongswan 作为“客户”端。我的 ipsec 隧道已启动（经ipsec statusAWS 控制台确认）。问题似乎是我的 BGP 客户端 (frr) 无法连接到 AWS 中的 BGP 进程（反之亦然）。

走其中一条隧道，ip a看起来是这样的：

5: tunnel1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 1.2.3.4 peer 2.3.4.5
    inet 169.254.10.146 peer 169.254.10.145/30 scope global tunnel1
       valid_lft forever preferred_lft forever

该界面是用Strongswan调用的脚本创建的，如下所示：

ip tunnel add ${VTI_INTERFACE} local ${PLUTO_ME} remote ${PLUTO_PEER} mode vti key ${PLUTO_MARK_IN_ARR[0]}
sysctl -w net.ipv4.conf.${VTI_INTERFACE}.disable_policy=1
sysctl -w net.ipv4.conf.${VTI_INTERFACE}.rp_filter=2 || sysctl -w net.ipv4.conf.${VTI_INTERFACE}.rp_filter=0
ip addr add ${VTI_LOCALADDR} remote ${VTI_REMOTEADDR} dev ${VTI_INTERFACE}
ip link set ${VTI_INTERFACE} up mtu ${MTU}
iptables -t mangle -I FORWARD -o ${VTI_INTERFACE} -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
iptables -t mangle -I INPUT -p esp -s ${PLUTO_PEER} -d ${PLUTO_ME} -j MARK --set-xmark ${PLUTO_MARK_IN}

我有一条这样的路线：

169.254.10.144/30 dev tunnel1 proto kernel scope link src 169.254.10.146

我可以 ping 我本地（客户端）端（169.254.10.146），但 ping 远程端时显示：

PING 169.254.10.145 (169.254.10.145) 56(84) bytes of data.
From 169.254.10.146 icmp_seq=1 Destination Host Unreachable

尽管说无法访问，但我在隧道接口上看到一个数据包，尽管它似乎并没有真正通过隧道发送到 AWS（至少，AWS Cloudwatch 统计数据没有显示其他活动）。

BGP 调试步骤之一是尝试通过端口 179 远程登录到邻居 (169.254.10.145) - 但此操作失败，并显示“无路由到主机”。但奇怪的是，我可以在隧道接口的 tcpdump 中看到 AWS 尝试连接到我的 BGP 客户端：

12:49:45.860899 IP 169.254.10.145.43731 > 169.254.10.146.179: Flags [S], seq 857645259, win 26880, options [mss 1375,sackOK,TS val 3261400514 ecr 0,nop,wscale 7], length 0
12:49:45.860931 IP 169.254.10.146.179 > 169.254.10.145.43731: Flags [S.], seq 2284055933, ack 857645260, win 64249, options [mss 1379,sackOK,TS val 936428713 ecr 3261400514,nop,wscale 7], length 0

看起来我的服务器正在返回 ACK 数据包，但连接从未建立。如果我停止 BGP 服务，我们将开始发送 RST 响应：

12:52:02.055473 IP 169.254.10.145.43679 > 169.254.10.146.179: Flags [S], seq 2280717367, win 26880, options [mss 1375,sackOK,TS val 3261536708 ecr 0,nop,wscale 7], length 0
12:52:02.055498 IP 169.254.10.146.179 > 169.254.10.145.43679: Flags [R.], seq 0, ack 1, win 0, length 0

由此我猜测内核的 ACK 数据包和我的 ping 数据包正在进入隧道接口，但实际上并没有进入 ipsec 或进入 AWS。

看来我需要添加一些额外的路由，但我不知道可能需要什么。感觉我已经把所有东西都准备好了。我查看了无数的例子和说明，但很少有人展示我没有的东西，甚至更少的人确认我需要我认为我需要的路由，或者 BGP 工作需要哪些路由。任何帮助都非常感谢。

答案1

事实证明，解决方案是附加的 xfrm 策略。其背后的想法是，虽然数据包正在进入接口，但流量并没有被 ipsec “收集”。为了解决这个问题，我们似乎需要标记数据包（以与我们在 ipsec 配置和 iptables 中所做的方式相同），并且还要通过策略专门“激活”xfrm。就我而言，它是这样的：

ip xfrm policy add dst 169.254.10.144/30 src 169.254.10.144/30 dir out tmpl src 1.2.3.4 dst 2.3.4.5 proto esp spi 0xc0f93fba reqid 1 mode tunnel mark 0x64

这使得政策如下：

src 169.254.10.144/30 dst 169.254.10.144/30
    dir out priority 0
    mark 0x64/0xffffffff
    tmpl src 1.2.3.4 dst 2.3.4.5
        proto esp spi 0xc0f93fba reqid 1 mode tunnel

这包含了一些魔力，似乎我们必须从现有策略中获取。首先是“spi 编号”。它由 Strongswan 设置，我认为它不可预测，在传递给 的环境中也不可用ipsec-vti.sh。相反，您需要执行一些 grep 和 awk 来将其从ip xfrm policy输出中拉出。同样，reqid这个设置 1 表示第一个接口，2 表示创建的第二个接口 - 遗憾的是，tunnel1 并不总是第一个，因此您也需要将该数字拉出。

相关内容