eBPF对TCP listen socket lookup的逻辑进行重定义

eBPF让Linux内核(其它OS内核对eBPF的支持,我不清楚,仅谈Linux)本身变得可编程,前面我已经展示了eBPF很多的trick用法,本文我来展示如何让eBPF干涉socket的查找。

我们知道,数据包到达四层后,会进行socket查找,以TCP为例,这个过程在tcp_v4_rcv函数中执行,所谓的查找过程就是一个简单的hash查找,然而hash查找算法的执行过程会随着输入数据的不同而产生畸变,由于代码是写死的,我们对这种畸变束手无策,只能寄希望于实现更好的hash算法。

eBPF改变了这一切,它可以让socket的查找过程变得可编程,你可以自定义自己的查找算法,绕开内核提供的标准hash查找过程。

先从一个概念,Anycast,开始。

Anycast即多个节点对外通告相同的地址,通过就近路由来寻址最合适的节点。采用Anycast有两个明显的益处:

  1. 实现广域范围的负载均衡。
  2. 所有节点配置相同,可以透明无缝迁移。

由于任何运营商都不会通告/32的前缀,甚至/24的很少通告,因此可以将IP地址的最后几位用于负载均衡,因此,一个服务器节点一般通告一个Anycast网段而不是一个/32地址,比如 192.168.40.0/24

这有几个益处:

  • 广域范围,DNS调度系统可以为用户吐192.168.40.0/24段的任意地址,实现地址隐藏。
  • 局域网范围,前端LB(比如LVS)可以target 192.168.40.0/24内的任意主机,实现负载均衡。
  • 实现更好的用户分组和策略路由。

类似的用法,参见iptables的 CLUSTERIP ,我之前写过一篇分析文章:
https://blog.csdn.net/dog250/article/details/77993563

现在言归正传,虽然可以通告一个网段,但是一个TCP服务却无法侦听一个网段,一个TCP服务要么侦听特定的/32地址,要么侦听0.0.0.0,别无它选。

假设一个服务器上驻留了两个服务,服务A通告192.168.40.0/24网段的80端口,服务B通告172.16.40.0/24网段的80端口,如何?

显然,侦听0.0.0.0:80是不可以的,这样会混杂两个服务,所以,你必须显示侦听所有这2段/24的地址,一共512个,一个socket只能侦听1个IP/Port元组,这意味着你必须显示创建512个socket,然而你的本意可能只需要2个就够了,一个侦听192.168.40.0/24:80,另一个侦听172.16.40.0/24:80,问题又回到了原点,怎么办?

一个见招拆招的方案就是 允许一个socket侦听一个非/32段。 这意味着要修改内核。我们可以找到这个patch:
https://www.spinics.net/lists/netdev/msg370789.html
我很赞同这种风格,事实上我出过很多如此捣鼓的方案。

然而,eBPF是更好的选择:
Programming socket lookup with BPF: https://lwn.net/Articles/797596/

这个topic事实上新增了一种eBPF类型(这种新增类型的事情一直在持续发生),我们只需要看一下代码就知道发生了什么。

遗憾的是,在Linux 5.5的合并窗口,这个patch目前依然没有进入主线,我们只能从支线来拉取代码。不管怎样,我觉得它是有意义的,甚至可以和eBPF的REUSEPORT作用点进行合并。

首先,我们把patch该功能的代码拉下来:

git clone https://github.com/jsitnicki/linux.git

然后翻阅 net/ipv4/inet_hashtables.c 文件的 __inet_lookup_listener函数:

struct sock *__inet_lookup_listener(struct net *net,
                                    struct inet_hashinfo *hashinfo,
                                    struct sk_buff *skb, int doff,
                                    const __be32 saddr, __be16 sport,
                                    const __be32 daddr, const unsigned short hnum,
                                    const int dif, const int sdif)
{
        struct inet_listen_hashbucket *ilb2;
        struct sock *result = NULL;
        unsigned int hash2;

		// 新增逻辑!增加了对eBPF程序的调用支持
        result = inet_lookup_run_bpf(net, hashinfo->protocol,
                                     saddr, sport, daddr, hnum);
        if (result)
                goto done;

		// 即便这里采用了2元组的hash2替代了仅仅端口hash的listen_hash,
		// 在海量listener情况下依然存在冲突链表过长的问题,毕竟hash桶是宏定义写死的。
        hash2 = ipv4_portaddr_hash(net, daddr, hnum);
        ilb2 = inet_lhash2_bucket(hashinfo, hash2);

        result = inet_lhash2_lookup(net, ilb2, skb, doff,
                                    saddr, sport, daddr, hnum,
                                    dif, sdif);
        if (result)
                goto done;

        /* Lookup lhash2 with INADDR_ANY */
        hash2 = ipv4_portaddr_hash(net, htonl(INADDR_ANY), hnum);
        ilb2 = inet_lhash2_bucket(hashinfo, hash2);

        result = inet_lhash2_lookup(net, ilb2, skb, doff,
                                    saddr, sport, htonl(INADDR_ANY), hnum,
                                    dif, sdif);
done:
        if (IS_ERR(result))
                return NULL;
        return result;
}

我们可以在eBPF程序中大有所为:

static inline struct sock *__inet_lookup_run_bpf(const struct net *net,
                                                 struct bpf_inet_lookup_kern *ctx)
{
        struct bpf_prog *prog;
        int ret = BPF_OK;

        rcu_read_lock();
        prog = rcu_dereference(net->inet_lookup_prog);
        if (prog) // 这里定义我们自己的lookup逻辑就是了。
                ret = BPF_PROG_RUN(prog, ctx);
        rcu_read_unlock();

        return ret == BPF_REDIRECT ? ctx->redir_sk : NULL;
}

现在有解了,还是上面的需求,我们可以让两个服务均侦听0.0.0.0:80,然后用eBPF程序进行分流:

#define NET1 (IP4(192,  168,   40, 0) >> 8)
#define NET2 (IP4(172, 16, 40, 0) >> 8)
struct {
	__uint(type, BPF_MAP_TYPE_REUSEPORT_SOCKARRAY);
	__uint(max_entries, MAX_SERVERS);
	__type(key, __u32);
	__type(value, __u64);
} redir_map SEC(".maps");

SEC("inet_lookup/demo_two_servers")
int demo_two_http_servers(struct bpf_inet_lookup *ctx)
{
	__u32 index = 0;
	__u64 flags = 0;

	if (ctx->family != AF_INET)
		return BPF_OK;
	if (ctx->protocol != IPPROTO_TCP)
		return BPF_OK;
	if (ctx->local_port != 80)
		return BPF_OK;

	switch (bpf_ntohl(ctx->local_ip4) >> 8) {
		case NET1:
		index = 0;
		break;
		case NET2:
		index = 1;
		break;
		default:
		return BPF_OK;
	}

	return bpf_redirect_lookup(ctx, &redir_map, &index, flags);
}

我们在两个用户态的服务里所要做的,仅仅是:

  1. 将上述eBPF程序载入内核。
  2. 找到redir_map这个map。
  3. 将通告192.168.40.0/24的服务socket以index=0插入map。
  4. 将通告172.16.40.0/24的服务socket以index=1插入map。

是不是非常有意义!


事实上,socket查找这件事是非常灵活的,TPROXY就是其简单的case之一。我们考虑以下场景:

  • 服务器侦听192.168.56.110:80

此时如果从另一台机器发起一个到 192.168.56.110:1234 的TCP连接,很明显是不通的,理由就是用192.168.56.110:1234作为key查找socket表的时候,没有发现有任何socket侦听1234端口。

然而这只是常规的hash元组匹配算法的结果,如果你手工指定 就是让这个访问到达192.168.56.110:80这个socket ,那么事实上也是可以建连成功的,TPROXY就是干这个的,这只需要在192.168.56.110上配置下面的iptables规则:

iptables -t mangle -A PREROUTING -p tcp --dport 1234 -j TPROXY --on-port 80

这个时候,你再试试?

实际上,TPROXY还是有所限制的,比如其侦听socket必须携带TRANSPARENT选项,毕竟从TPROXY顾名思义,它截获的包一般目的地并不是它自己,它只是一个代理。

用eBPF实现上面的从1234端口到80端口的重定向就简单多了:

SEC("inet_lookup/demo_two_servers")
int redirect_to_port_80(struct bpf_inet_lookup *ctx)
{
	__u32 index = 0;

	if (ctx->family != AF_INET)
		return BPF_OK;
	if (ctx->protocol != IPPROTO_TCP)
		return BPF_OK;
	if (ctx->local_port != 1234)
		return BPF_OK;
	// 80服务socket在服务进程中以index=0插入到map中即可!
	return bpf_redirect_lookup(ctx, &sk_map, &index, 0);
}

有点意思。虽然经理可能并不认同。


浙江温州皮鞋湿,下雨进水不会胖。

发布了1547 篇原创文章 · 获赞 4784 · 访问量 1064万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览