☰

ipsec 右子网范围较广，无法覆盖路由表 | IPSec 在“本地”路由某些数据包，而不是通过隧道； ip xfrm 改变？

tag-icon • tag-icon route ipsec openswan
ipsec 右子网范围较广，无法覆盖路由表 | IPSec 在“本地”路由某些数据包，而不是通过隧道； ip xfrm 改变？

我想覆盖部分 (IPSec) 路由表

（通过 eth0 本地路由到 10.108.0.0/16，而不是通过 IPSec 隧道）

我的 IPSEC 配置

conn vpc
    type=tunnel
    authby=secret
    left=172.16.0.200
    leftid=x.x.x.x
    leftsubnet=172.16.0.0/16
    leftfirewall=yes
    right=y.y.y.y
    rightsubnet=10.0.0.0/8
    #pfs=yes
    auto=start

如您所见，通过隧道路由 10.0.0.0/8

# ip r s t all
10.0.0.0/8 via 172.16.0.1 dev eth0  table 220  proto static  src 172.16.0.200 
default via 172.16.0.1 dev eth0 
10.108.0.0/16 via 172.16.0.1 dev eth0 
172.16.0.0/24 dev eth0  proto kernel  scope link  src 172.16.0.200 
broadcast 127.0.0.0 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
local 127.0.0.0/8 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
local 127.0.0.1 dev lo  table local  proto kernel  scope host  src 127.0.0.1 
broadcast 127.255.255.255 dev lo  table local  proto kernel  scope link  src 127.0.0.1 
broadcast 172.16.0.0 dev eth0  table local  proto kernel  scope link  src 172.16.0.200 
local 172.16.0.200 dev eth0  table local  proto kernel  scope host  src 172.16.0.200 
broadcast 172.16.0.255 dev eth0  table local  proto kernel  scope link  src 172.16.0.200 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
fe80::/64 dev eth0  proto kernel  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101
local ::1 dev lo  table local  proto none  metric 0 
local fe80::52:b2ff:fe65:b0fe dev lo  table local  proto none  metric 0 
ff00::/8 dev eth0  table local  metric 256 
unreachable default dev lo  table unspec  proto kernel  metric 4294967295  error -101

# ipsec statusall
Listening IP addresses:
  172.16.0.200
Connections:
     vpc:  172.16.0.200...x.x.x.x  IKEv1/2
     vpc:   local:  [x.x.x.x ] uses pre-shared key authentication
     vpc:   remote: [y.y.y.y] uses pre-shared key authentication
     vpc:   child:  172.16.0.0/16 === 10.0.0.0/8 TUNNEL
Security Associations (1 up, 0 connecting):
     vpc[3527]: ESTABLISHED 30 minutes ago, 172.16.0.200[x.x.x.x]...y.y.y.y[]
     vpc{1}:   172.16.0.0/16 === 10.0.0.0/8

我特地添加了

    #ip r a 10.108.0.0/16 via 172.16.0.1

10.108.0.0/16 via 172.16.0.1 dev eth0

我希望它能在表 220“之前”捕获，但
流量仍然通过 IPSec 隧道。我一定是缺少了一些层。我知道我可以将 rightsubnet=10.0.0.0/8 更改为 rightsubnet=10.0.0.0/16 但我只想更改一条路线

只是检查

# ip xfrm policy
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir fwd priority 1955 
    tmpl src x.x.x.x dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir in priority 1955 
    tmpl src x.x.x.x dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.0.0.0/8 
    dir out priority 1955 
    tmpl src 172.16.0.200 dst x.x.x.x
            proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0

也许我可以在这里改变一些东西

我想通过本地 eth0 路由 10.108.0.0/16，而不是通过 IPSec 隧道

编辑我已将政策扩展为：

ip xfrm policy update dir in src 172.16.0.0/16 dst 10.108.0.0/16
ip xfrm policy update dir out src 172.16.0.0/16 dst 10.108.0.0/16
ip xfrm policy update dir fwd src 172.16.0.0/16 dst 10.108.0.0/16

# ip xfrm policy
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir fwd priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
        proto esp reqid 1 mode tunnel
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir in priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
        proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.0.0.0/8 
    dir out priority 1955 
    tmpl src 172.16.0.200 dst 54.77.116.107
        proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.108.0.0/16 
    dir fwd priority 0 
src 172.16.0.0/16 dst 10.108.0.0/16 
    dir out priority 0 
src 172.16.0.0/16 dst 10.108.0.0/16 
    dir in priority 0

另一种尝试：

ip xfrm policy add dir out src 172.16.0.0/16 dst 172.16.0.1
ip xfrm policy add dir in src 172.16.0.0/16 dst 172.16.0.1 
ip xfrm policy add dir fwd src 172.16.0.0/16 dst 172.16.0.1

# ip xfrm policy 
src 172.16.0.0/16 dst 172.16.0.1/32 
    dir fwd priority 0 
src 172.16.0.0/16 dst 172.16.0.1/32 
    dir in priority 0 
src 172.16.0.0/16 dst 172.16.0.1/32 
    dir out priority 0 
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir fwd priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 10.0.0.0/8 dst 172.16.0.0/16 
    dir in priority 1955 
    tmpl src 54.77.116.107 dst 172.16.0.200
            proto esp reqid 1 mode tunnel
src 172.16.0.0/16 dst 10.0.0.0/8 
    dir out priority 1955 
    tmpl src 172.16.0.200 dst 54.77.116.107
            proto esp reqid 1 mode tunnel

但它看起来仍然不是一个好的“重定向”

答案1

我知道这可能不是您想听到的，但处理 IPsec 和路由的最佳方法是将两者完全隔离。策略模式下的默认 IPsec（Linux 执行此操作的方式，看起来像您正在使用的方式）倾向于“合并”各层，从而使路由变得非常模糊。更好的方法是将 IPsec 更像是典型的逻辑网络链路：让 IPsec 处理点对点通信，并在 GRE 之上使用动态路由协议（如 OSPF 和 BGP）（如果是，则可以跳过动态路由）你想要，但建议）。

在您的情况下，您不是直接172.16.0.0/16与接口，而是让 IPsec 堆栈在，甚至是10.0.0.8/8上创建点对点链接。例如，您可以使用左侧 IP 和右侧 IP。建立后，为本地端和远程端创建具有内部 IP 的 GRE 隧道（并为相应的外部端使用上述IP）。额外好处：如果您能够在传输模式下运行 IPsec，您可以完全放弃该部分并使用端点的实际 IP 作为 GRE 隧道的外部部分。/30/3110.254.254.1/3010.254.254.2/3010.100.100.1/3010.100.100.2/3010.254.254.0/3010.254.254.0/30

现在您有了一个标准以太网接口（GRE 隧道），并且可以非常轻松地执行静态路由：只需指向10.0.0.8/8via10.100.100.2和172.16.0.0/16at 10.100.100.1。更好的是：完全删除这些静态路由，并让 OSPF 或 BGP 自动为您处理路由（请参阅 quagga）。

优点：您可以随时轻松添加路由，而无需重新配置底层 IPsec 堆栈，因为它与路由完全隔离。您可以运行任何需要标准以太网接口的服务，而不会感到奇怪（iptables 就是一个完美的例子）。您可以利用 BGP 和多个 IPsec 隧道轻松完成多个发散和冗余的路径，并完全避免有些复杂的 IPsec 高可用性方案。但最大的好处是，您现在已将 IPsec 放置在一个非常隔离的位置（保护链路上的流量），无需任何额外的配置即可轻松扩展到上层网络层。

IPsec 是一个非常灵活的协议，正因为如此，很多东西最终都被卷入了它的漩涡。在某种程度上，让 IPsec 坚持它最擅长的事情并利用更高级别的网络堆栈概念，而不是把厨房水槽扔给它，确实更好。

相关内容