基于Linux内核新特性的网关设计实践

通过对上述三项新技术的研究，我们发现可以尝试设计一套基于路由的方式，实现多租户层叠网络的外网网关。在方案设计过程中，我们也碰到了诸如 lwtunnel 和流卸载功能不足，以及 VRF 和流卸载不能一起有效的工作等问题。最终我们都设法解决了，并针对这些内核的不足提交补丁给 Linux 内核社区。

1、lwtunnel 发送报文 tunnel_key 丢失

问题描述：我们利用 lwtunnel 路由方式发送报文时，创建了一个 external 类型的 gretap 隧道，我们将命令设置了 id 为 1000，但是发送成功报文中没有 tunnel_key 字段。

# ip l add dev tun type gretap
# ifconfig tun 1.1.1.7/24 up
# ip r r 2.2.2.11 via 1.1.1.11 dev tun encap ip id 1000 dst 172.168.0.1

问题定位：我们研究 iproute2 代码，发现由于 TUNNEL_KEY 的标志并没有开放给用户态，所以 iproute2 工具并没有对 lwtunnel 路由设置 TUNNEL_KEY，导致报文不会创建 tunnel_key 字段。

提交补丁：我们给内核和用户态 iproute2 分别提交补丁来解决这一问题：

• iptunnel: make TUNNEL_FLAGS available in uapi
• iproute: Set ip/ip6 lwtunnel flags

提交补丁后，可以通过以下方式设置路由：

ip r r 2.2.2.11 via 1.1.1.11 dev tun encap ip id 1000 dst 172.168.0.1 key

2、lwtunnel 对指定密钥的 IP 隧道无效

问题发现：为了能有效隔离租户路由，我们给每个租户创建一个基于 tunnel_key 的 gretap 隧道设备。如下图，创建一个 tunnel_key 1000 的 gretap 隧道设备，把隧道设备加入租户所属 VRF，隧道设备能有效地接收报文，但并不能发送报文。

# ip l add dev tun type gretap key 1000
# ifconfig tun 1.1.1.7/24 up
# ip r r 2.2.2.11 via 1.1.1.11 dev tun encap ip id 1000 dst 172.168.0.1 key

问题定位：研究内核发现，IP 隧道在非外部模式下即使指定了轻量级隧道路由，发送报文也没有使用它，导致报文路由错误被丢弃。

提交补丁：

• ip_tunnel: Make none-tunnel-dst tunnel port work with lwtunnel

提交补丁后，在未指定 tunnel_dst 的非外部模式 IP 隧道下，，能使用轻量级隧道路由进行发送报文。

3、外部 IP 隧道 ARP 无法正常运行

问题描述：邻居 IP 隧道进行了 ARP 请求，但是本端的 ARP 回应报文的隧道头中并没带 tunnel_key 字段。

# ip l add dev tun type gretap external
# ifconfig tun 1.1.1.7/24 up
# ip r r 2.2.2.11 via 1.1.1.11 dev tun encap ip id 1000 dst 172.168.0.1 key

问题定位：研究代码发现，隧道收到了对端的 ARP 请求，在发送报文 ARP 回复的时候会复制请求报文的隧道信息，但是遗漏了所有 tun_flags。

提交补丁：

• iptunnel: Set tun_flags in the iptunnel_metadata_reply from src

4、流卸载不能与 DNAT 有效工作

问题描述：防火墙创建规则从 eth0 收到目的地址 2.2.2.11 的报文，DNAT 为 10.0.0.7， 流卸载无法工作。

问题定位：分析发现，客户端 1.1.1.7 -> 2.2.2.7 DNAT 到服务器 10.0.0.7，第一个回复的反向报文（syc+ack）使用了错的目的地址获取反向路由。

daddr = ct->tuplehash[!dir].tuple.dst.u3.ip

此时 dir 为反方向，所以 daddr 获取为原方向的目的地址，这个值是 2.2.2.7，但是由于被 DNAT过，真正的路由不应该通过 2.2.2.7 去获取，而是应该根据 10.0.0.7 这个值去获取。

addr = ct->tuplehash[dir].tuple.src.u3.ip

提交补丁：

• netfilter: nft_flow_offload: Fix reverse route lookup

5、流卸载不能与 VRF 有效工作

问题描述：将网卡 eth0 和 eth1 加入 VFR 后，流卸载不起作用。

# ip addr add dev eth0 1.1.1.1/24
# ip addr add dev eth1 1.1.1.1/24
# ip link add user1 type vrf table 1
# ip l set user1 up
# ip l set dev eth0 master user1
# ip l set dev eth1 master user1

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!