主页 / server / 问题 / 1129745
Accepted
simonw
Asked: 2023-04-26 23:40:47 +0800 CST

自定义路由表中的 VPN 网关失败

  • 772

我的目标是配置一个容器作为路由器，在多个 VPN 连接上进行负载平衡。

为此，我用以下概率标记启动数据包：

iptables -I PREROUTING -t mangle -j CONNMARK --restore-mark
iptables -A PREROUTING -t mangle -m statistic --mode random --probability .50 -j MARK --set-mark 200 -m mark --mark 0
iptables -A PREROUTING -t mangle -j MARK --set-mark 201 -m mark --mark 0
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark

选择两个路由表之一：

echo "200     tun0" >> /etc/iproute2/rt_tables
echo "201     tun1" >> /etc/iproute2/rt_tables 
ip rule add fwmark 200 table tun0
ip rule add fwmark 201 table tun1

我相信路由表选择正确，因为当我配置任一表 tun0/1 以使用 VPN 网关流量时似乎无法返回。Atcpdump显示流量退出但任何命令失败。

ip route add default 10.7.7.1 dev tun0 table tun0
ip route add default 10.7.7.1 dev tun1 table tun1

如果表 tun0/1 使用非 VPN 网关，10.10.10.1流量将按预期运行。我还可以通过在主表上设置默认路由来在 VPN 网关之间进行选择：

ip route add default 10.7.7.1 dev tun0/1

因此，问题似乎出在通过自定义表之一而不是主表选择 VPN 网关时。欢迎任何线索/诊断/建议！

注意我已经配置了必要的选项：

echo 0 > /proc/sys/net/ipv4/conf/**/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
sysctl -w net.ipv4.fwmark_reflect=1
sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE

回答：

@AB 的回答提供了解决方案。我需要在 tun0/1 表中为返回本地网络的流量添加路由：

ip r a 10.10.10.0/24 via 10.10.10.1 table tun0
ip r a 10.10.10.0/24 via 10.10.10.1 table tun1

正如@AB 所说，没有这些标记的数据包将被发送回接收它们的 tun。

iptables

1 个回答

  1. Best Answer

    让我们看看会发生什么。

    • 数据包（新流的第一个）从非隧道接口到达
    • conntrack为此数据包创建一个新条目，开始一个新流
    • 数据包在路由决定之前接收（随机，这次：）标记 200
    • 使用表 200 路由数据包
    • 表 200 有一种可能性：数据包将通过tun0发送
    • 数据包的标记在其conntrack条目中为整个流保存（即：connmark）。

    到目前为止一切正常，数据包（及其流）已通过tun0进行负载平衡。

    现在，当此流中的回复数据包返回时会发生什么？

    • 回复数据包从tun0到达

    • 回复数据包被conntrack识别为现有流的一部分

    • 在路由决策之前，数据包从其关联到现有流的connmark继承标记 200

    • 使用表 200 路由数据包

    • 表 200 有一种可能性：数据包将通过tun0发送

      糟糕：回复数据包从它来的地方路由回来：隧道接口，而不是从流的初始数据包来自的地方。

    • 根据下一跳路由器（隧道远程端点）是否也禁用了严格反向路径转发 ( rp_filter=0)，数据包要么被丢弃，要么再次路由回创建循环，直到其递减的 TTL 达到 0。

    因此，问题似乎出在通过自定义表之一而不是主表选择 VPN 网关时。

    实际上，主路由表不止有一条默认路由。它通常包括一个或多个 LAN 路由。因此，当不涉及任何标记时，将在评估所有主要路由表条目后正确路由回复，而不仅仅是遵循其默认路由。

    这些额外的 LAN 路由：使用eth0和eth1 的路由，或者至少是涉及客户端请求的路由，如果不是两者，也必须复制到额外的路由表 200 和 201。

    附加说明（不适用于 OP 的情况）：在相反方向工作的设置中：来自使用完全相同（私有）IP 源地址的不同节点的原始流流向同一服务，可能有两个不同的流看起来相同的（相同的 5-uple 协议、saddr、sport、daddr、dport）除了它们的隧道接口。默认情况下，conntrack会看到单个流。为了防止这种情况，可以使用conntrack zones，（选择一个值来表示接口）让conntrack单独处理它们。

    • 1

相关问题