开放湾多子网路由问题

Question

我正试图在OpenSwan 6.5 (final)上安装一个CentOS (2.6.32)，以连接亚马逊云上的远程VPC网关。我把隧道弄起来了。但是，只有从左子网中定义的/到最后一个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

我不认为防火墙在这里扮演任何角色，因为我完全关闭它只是为了测试连接。路线也如预期的那样正常工作。如果我在左侧定义单个网络，单独在一个独立的测试连接上，我可以到达任何一个子网。只有当我定义左撇子，那么，无论哪一个范围最后会被路由在最后。无论哪个先来，在停止路由之前工作一秒钟。

我在网上找不到有类似问题的人。谁能指点我一下吗？

干杯,

bo

Answer 1

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

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

Answer 2

这是由于AWS实现IPSec处理SPIs (安全参数指数)的方式出现了错误。您可以在利布雷斯旺网站上详细了解它，但是结果是libreswan通过建立两个隧道(在您的例子中，可能是aws-vpc/1x1和aws-vpc/1x2)来处理这两个范围。OpenSWAN和StrongSWAN也是如此。

每个隧道都有自己的SA (安全关联)，每个通道都由一对SPIs标识，一个用于您发送的流量(您的SPI)，另一个用于Amazon发送的流量( SPI)。尽管Amazon已经为任何最先出现的隧道建立了SPI #1，但当第二个隧道出现时，将其替换为SPI #2 (而不是将SPI #1用于隧道1号，而只对第二个隧道使用SPI #2 )。流量被发送到使用SPI #1的隧道中的AWS，但是Amazon用它们的SPI #2加密答复，这自然会导致流量在您的末尾无法解密。

因此，第一条隧道只运作一段很短的时间，直至第二条隧道出现。如果在稍后的某个时候，您强制SPIs在第一隧道的更新，它就会开始工作，但是Amazon的新SPI #1将取代原来的SPI以取代第二隧道，而第二隧道将在隧道一号恢复服务时停止工作。

几年前，我在两个不同的场合遇到过这种情况，最近的一次是昨天，所以我认为AWS不太可能修复它。它似乎并没有影响商业IPSec实现(或者AWS现在已经修复了它)，我猜是因为它们实际上没有子网之间隧道的概念，而只是聚集了一堆共享相同SPIs的主机-主机隧道。然而，这只是猜测而已。

编辑:奇怪的是，由于花了一周时间为一个拥有良好AWS支持合同的客户做这方面的工作，我现在已经证实了libreswan对最新SPI错误地替换了任何早期建立的SPI的说法。亚马逊还证实，他们正在这样做，在他们看来，一个vpn-实体只能支持一对SPIs。他们的建议是配置S/WAN，以便只创建一个隧道，然后将流量路由到特定的目的地。

幸运的是，libreswan现在支持这一点，在3.18或更高版本中，只要您有一个合理的最新Linux内核。我可以确认CentOS 7在这两方面都满足。

他们的详细内容是在他们的维基上，但结果是您使用(vti)设备建立了一个具有非常宽的源和目标范围(0.0.0.0/0)的隧道，然后告诉libreswan不要设置跨它的路由(vti-routing=no)。然后，您可以使用简单的路由语句(ip route add 10.0.0.0/8 dev vti01)选择到达该隧道的目的地。

我让这个在生产部工作。它甚至支持多个同步隧道，稍后的隧道使用不同的mark=和vti-interface=配置选项。Amazon现在还支持将VPN与传输网关(TGW)相关联，而同一AWS区域中的许多VPN又可以关联到该网关，因此每个AWS区域实际上只需要一个VPN，这是可伸缩的。

Answer 3

试着使用：

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

而不是：

leftsubnets={10.43.4.0/24 10.43.6.0/24}

注:加两个逗号。第一次也是最后一次。