☰

openswan 多子网路由问题

tag-icon • tag-icon centos openswan
openswan 多子网路由问题

我正在尝试在 CentOS 6.5（最终版）上设置 OpenSwan（2.6.32）以连接 Amazon 云上的远程 VPC 网关。我已建立隧道。但是，只有来自/到 leftsubnets 中定义的最后一个 IP 范围的流量被路由。第一个隧道工作了一小会儿（可能在第二条隧道建立之前），然后就不再路由了。以下是我的配置。

conn aws-vpc
    leftsubnets={10.43.4.0/24 10.43.6.0/24}
    rightsubnet=10.43.7.0/24
    auto=start
    left=206.191.2.xxx
    right=72.21.209.xxx
    rightid=72.21.209.xxx
    leftid=206.191.2.xxx
    leftsourceip=10.43.6.128
    authby=secret
    ike=aes128-sha1;modp1024
    phase2=esp
    phase2alg=aes128-sha1;modp1024
    aggrmode=no
    ikelifetime=8h
    salifetime=1h
    dpddelay=10
    dpdtimeout=40
    dpdaction=restart
    type=tunnel
    forceencaps=yes

启动IPsec服务后：

# service ipsec status
IPsec running  - pluto pid: 8601
pluto pid 8601
2 tunnels up
some eroutes exist

# ip xfrm policy
src 10.43.6.0/24 dst 10.43.7.0/24 
dir out priority 2344 ptype main 
tmpl src 206.191.2.xxx dst 72.21.209.xxx
    proto esp reqid 16389 mode tunnel
src 10.43.7.0/24 dst 10.43.6.0/24 
dir fwd priority 2344 ptype main 
tmpl src 72.21.209.xxx dst 206.191.2.xxx
    proto esp reqid 16389 mode tunnel
src 10.43.7.0/24 dst 10.43.6.0/24 
dir in priority 2344 ptype main 
tmpl src 72.21.209.xxx dst 206.191.2.xxx
    proto esp reqid 16389 mode tunnel
src 10.43.4.0/24 dst 10.43.7.0/24 
dir out priority 2344 ptype main 
tmpl src 206.191.2.xxx dst 72.21.209.xxx
    proto esp reqid 16385 mode tunnel
src 10.43.7.0/24 dst 10.43.4.0/24 
dir fwd priority 2344 ptype main 
tmpl src 72.21.209.xxx dst 206.191.2.xxx
    proto esp reqid 16385 mode tunnel
src 10.43.7.0/24 dst 10.43.4.0/24 
dir in priority 2344 ptype main 
tmpl src 72.21.209.xxx dst 206.191.2.xxx
    proto esp reqid 16385 mode tunnel

我认为防火墙在这里不起作用，因为我完全关闭了它只是为了测试连接。路由也按预期工作。如果我在左侧定义单个网络，在单独的测试连接上单独定义，我可以访问任一子网。只有当我定义 leftsubet 时s，则最后到达的范围最终会被路由。先到达的范围会先工作一小会儿，然后停止路由。

我在互联网上找不到任何遇到类似问题的人......有人可以告诉我吗？

干杯，

博

答案1

使用时leftsubnets，必须使用rightsubnets，而不是rightsubnet。如http://linux.die.net/man/5/ipsec.conf：

如果同时定义了leftsubnets=和rightsubnets=，则所有子网隧道组合都将被实例化。

答案2

这是由于 AWS 的 IPSec 实现处理 SPI（安全参数索引）的方式存在错误。您可以在此详细了解libreswan 的网站但结果是 libreswan 通过建立两个隧道来处理这两个范围（在您的情况下，可能aws-vpc/1x1是和aws-vpc/1x2）。OpenSWAN 和 StrongSWAN 也是这样做的。

这些隧道中的每一个都有自己的 SA（安全关联），每个 SA 都由一对 SPI 标识，一个用于您发送的流量（您的 SPI），另一个用于 Amazon 发送的流量（他们的 SPI）。尽管 Amazon 已经为最先出现的隧道建立了 SPI #1，取代当第二条隧道启动时，使用 SPI #2 对其进行加密（而不是像应该的那样，将 SPI #1 保留用于隧道 1，将 SPI #2 仅用于隧道 2）。流量使用您的 SPI #1 通过隧道 1 发送到 AWS，但 Amazon 使用其 SPI #2 加密回复，这自然会导致流量在您这端解密失败。

这就是为什么第一条隧道只能工作很短的一段时间，直到第二条隧道恢复运行。如果稍后您强制重新生成第一条隧道的 SPI，它将开始工作，但亚马逊的新 SPI #1 将取代第二条隧道的旧 SPI，而第二条隧道将在第一条隧道恢复服务时停止工作。

几年之间我曾两次遇到过这个问题，最近一次是昨天，所以我认为 AWS 不太可能修复它。它似乎不会影响商业 IPSec 实现（否则 AWS 现在已经修复了它），我猜测因为它们实际上没有子网间隧道的概念，而只是聚合了一堆共享相同 SPI 的主机到主机隧道。不过，这只是一个猜测。

编辑：奇怪的是，由于花了一周时间为一位拥有良好 AWS 支持合同的客户处理此事，我现在已经确认了 libreswan 所说的最新 SPI 错误地替换了任何先前建立的 SPI。亚马逊也证实他们正在这样做，并且vpn-他们认为一个实体只能支持一对 SPI。他们的建议是配置 S/WAN，以便只创建一个隧道，然后通过它将流量路由到特定目的地。

幸运的是，libreswan 现在支持此功能（3.18 版或更高版本），前提是您拥有较新的 Linux 内核。我可以确认 CentOS 7 满足这两个要求。

他们的详细写作是在他们的维基上，但结果是您0.0.0.0/0使用 Linux 虚拟隧道接口 ( )vti设备建立了具有非常广泛的源和目标范围的隧道 ( )，然后告诉 libreswan 不要设置通过它的路由 ( vti-routing=no)。然后，您可以使用简单的路由语句 ( ) 选择通过此隧道到达哪些目的地ip route add 10.0.0.0/8 dev vti01。

我在生产环境中使用它。它甚至支持多个同时隧道，稍后的隧道使用不同的配置mark=选项vti-interface=。亚马逊现在还支持将 VPN 与传输网关 (TGW) 关联，同一 AWS 区域中的许多 VPN 可以依次关联到该网关，因此每个 AWS 区域实际上只需要一个 VPN，这是可扩展的。

答案3

尝试使用：

leftsubnets={10.43.4.0/24,10.43.6.0/24,}

代替：

leftsubnets={10.43.4.0/24 10.43.6.0/24}

注意：在 first 和 last 后面也要加两个逗号。

相关内容