OpenVPN的Linux内核版,鬼魅的残缺 part III rework with Netfilter

哥们儿拿到了juniper的offer,由衷祝福,酒足饭饱后的我,在Netfilter的路上却根本停不下来。已经是深夜,回忆这些年在Netfilter上的探索,结合目前的一些状况,突然觉得,既然我已经想把OpenVPN弄到内核了,那为何上一个鬼魅的实现没有使用Netfilter呢?当时我就觉得采用UDP的encap_rcv HOOK这种方式太鬼魅,又有些残缺,缺了什么却不知道,谁说没钱就不能任性,我当时可能就觉得:我就是不用Netfilter,我就是要用另一个方法!就好像上高中的时候,数学课上,我总是能提出一个最简便但却多少有些YD的解法,当老师说这种方法没法得分的时候,我就大喊:我还有一种更复杂的方法...然后那些学习不好但是成绩却很高的人们就有些不高兴了,其实哪知道我真的是在有针对地嘲讽他们啊...现在好了,当那些人都穿着西装不再跟我玩这种幼稚的游戏的时候,我依然在跟自己玩,只是我是自己嘲讽自己而已。
       整个城市,向黑暗中退去,你我都放弃忍耐!
       我将OpenVPN顺利移植进了内核,然而却对tun.c做了比较大的手术,在那个实现中,我借用了一个udp_encap_rcv钩子点,然后在tun驱动的xmit函数中增加了一个新的钩子点,两个钩子点对接完成了OpenVPN数据通道处理流程的短路。然而仔细想想,总觉得哪里不妥,所谓的优化无极限并非仅仅针对性能,还针对美感,如果自己都觉得它丑陋无比,那么它就一定可以换种方式重新实现。
       在《OpenVPN的Linux内核版,鬼魅的残缺 part I:The PROTOCOL》中,那种短路方式确实绕开了OpenVPN这个大电阻,但是在udp的encap_rcv增加了一个通过real source address以及real source port为主键查找multi_instance的过程,我们一向都认为这个过程是绕不开,因此它作为一个小电阻存在在那里。我们还知道,Linux的内核协议栈将所有的同一种协议的socket链在了一张hash表中,每一个到达本地的数据包都要根据4元组在这个hash表中检索到唯一的一个socket并和skb本身关联起来,因此这个查找过程是绝对绕不开的,这不是说我认为它绕不开,而是socket层的例行过程。那么,数据包是怎么知道自己要到达本地的呢?很显然,还有一种绝对绕不开的过程,那就是路由查找,当然这个绝对也并不绝对,因为存在很多的路由板卡,专门在链路层cache路由结果,当然这是后话,也并不是每一台设备都拥有这种板卡。到目前为止,我总结一下OpenVPN内核版本的数据通道处理流程的三次查找操作:
1.路由查找:决定了数据包是到达本地的,这是这个数据包是OpenVPN数据通道数据包的前提;
2.UDP的socket查找:这是这个数据包是OpenVPN数据通道数据包的另一个前提;
3.multi_instance查找:这是一个短路操作的查找,原版的OpenVPN的这个查找在multi.c文件的一个multi_process_incoming_link函数中。
好了,在我描述了以上的3个所谓的必不可少的查找之后,接下来就是我的风格展示了,做掉它们!我并不认为会有奇迹,我也同样不相信程序可以智能到自己寻找加密参数,那么查找肯定是必不可少的了,问题是,如何将查找次数降低到最少!我的方式是,我的方式还是Netfilter,一个极端优秀的框架!优秀到多么极端的程度仅仅和你的想象力有关!我没有发明什么新的东西,而是使用了conntrack!然后将所有的信息都保存在conntrack的extend中,这种方式是我一直都在思考的,并且还真的用到了工作中,这是绝对值得欣慰的。
       关于ip conntrack,我已经不想再多说,之前的文章已经说了不少,我对它的掌控虽谈不上出神入化但也稍微有点说到它就排他了...conntrack可谓说是“一次慢速的多层查询以建立快速通道”的绝佳实例,因此唯一耗时的操作过程仅仅在第一次建立conntrack结构体的时候,在这个慢速的过程中,所有的查询结果都可以保存在conntrack中,虽然Linux的ip conntrack中没有所谓的private_data之类的void指针,但是却可以通过extend机制去扩展,此后所有的信息都可以在conntrack结构体的对应extend中直接查到,因此,所有的查询操作都可以归结为单一的conntrack查询操作了。至于conntrack查询的效率,我可以说它非常不高,也非常影响性能,但是正因为如此,我才会说它还有很大优化空间,至于如何优化,我曾经写过一个方法,那就是多张conntrack hash表,典型地可以是按照协议来区分不同的conntrack hash表,从一个skb中取到传输层协议是再简单不过的事了,如果每一种协议建立一张表,岂不是很好的思路?!
       好了,现在假设你已经明白我的大致思路,那么具体的实现该如何呢?那当然最简单不过了,解密流程如下:
0.conntrack建立:我们要明白,OpenVPN的数据通道和控制通道只是应用层的区分,因此它们共享一个conntrack结构体,在数据通道启用之前,控制通道已经建立(SSL握手完成),控制通道的建立意味着和它关联的conntrack结构已经被confirm了。
1.数据包拦截:PREROUTING上在CONNTRACK优先级之后建立一个OpenVPN HOOK,拦截OpenVPN的数据通道的skb。此时取出skb的conntrack结构体,进一步取出自定义的ovpn extend;
2.数据包解密:所有的信息都在ovpn extend中,包括加密密钥和解密密钥,此时我们需要的是解密密钥。将数据包进行常规检查(IP层校验已经在PREROUTING前做过,因此此处只要校验UDP相关的即可)之后,脱掉UDP/IP西服,然后对其进行解密解封装,OpenVPN校验,包括replay攻击校验等,最终露出一个内层被封装的IP数据报文(目前我没有实现TAP mode);
3.短路到tun网卡:这个步骤比较复杂,分为下面的子步骤:
3.0.提出一个问题:第2步最终的skb此时其实已经可以被tun网卡接收了,即模拟一个netif_rx_ni调用。但是且慢!人无远虑必有近忧!我们要考虑属于此时skb的conntrack的返回包回来的时候如何被加密,即按照我最初的思路,需要一个extend和此时的内层skb的conntrack关联起来,问题是如何拿到该conntrack,如果在tun的netif_rx之后自然到达PREROUTING之后拿到,我们将丢失内层skb和外层skb之间的关联。必须另想它法。注意,此时我们依然在外层skb的PREROUTING的OpenVPN HOOK中;
3.1.获取内层skb的conntrack:在不逃出这个外层skb的OpenVPN HOOK的位置,手动让内层skb到PREROUTING中溜达一圈,一直溜达到它的conntrack被指定为止。其实懂行的都知道,过了ipv4_conntrack_in这个函数,它的conntrack就被指定了。注意,此时我们依然在外层skb的PREROUTING的OpenVPN HOOK中;
3.2.设置内层skb conntrack的extend:如果发现内层skb的conntrack OpenVPN extend已经被设置,就直接通过,否则就设置它,注意,此时我们依然在外层skb的PREROUTING的OpenVPN HOOK中,所以很容易关联内层skb conntrack OpenVPN extend以及外层skb conntrack OpenVPN extend;
3.3.模拟tun网卡接收:这是真正的短路操作。在tun数据包接收了内层skb之后,总是还是会到PREROUTING的ipv4_conntrack_in中的,但是无所谓,不会被执行的,会直接退出,这是因为它的conntrack已经有了,previous seen??
4.正向短路至此完成:怎么庆祝一下呢?最好的方法就是顺利让内层skb经过路由,local deliver或者forward,放走它,并等待和它同属一个conntrack的另一个skb的返回!
紧接着,我们看一下加密流程:
0.反向数据包的返回:我等待的数据包终于返回了,好的,这正是我想要的!
1.数据包拦截:PREROUTING上在CONNTRACK优先级之后已经建立了一个OpenVPN HOOK,取出skb的conntrack之后,发现其拥有OpenVPN的extend,其中的信息正是正向解密流程的第3.2步骤建立的,此时我敢保证,这个skb就是需要加密的,好的;但是且慢,如果没有找到conntrack的OpenVPN extend怎么办?这说明这个conntrack是从OpenVPN服务端方向主动发起的,那么这时就要进入慢速路径了,因为短路操作所需的信息不足。所谓的慢速路径就是依旧和往常一样经由IP路由将其发往tun虚拟网卡,然后是字符设备,最后被OpenVPN用户态进程读取,加密,然后写入socket...
2.数据包加密:用第1步中的OpenVPN extend信息中的加密信息对该skb进行封装,加密以及HMAC处理。具体过程和OpenVPN中的几乎一样;
3.数据包外层封装:从第1步中查到的OpenVPN extend获取连接信息,即外层skb的UDP 4元组信息,将其进行UDP封装,IP封装,然后直接调用ip_local_out将其发出,这是反向加密流程的短路操作;
4.反向短路至此完成:怎么庆祝一下呢?...
至此,内核中的所有的操作均已经介绍完毕,那么内核中的所谓的OpenVPN extend信息是什么时候注入进去的呢?以下是一些个注入点:
1.multi_instance建立的时候:此时OpenVPN已经接收到了RESET,但是SSL握手或者password验证等还没有完成,密钥协商还未完成,但是五元组已经确定,这个point可以注入的信息有:该conntrack确实是路由到本地OpenVPN进程的;tun网卡的信息;
2.密钥协商完成:此时的几个密钥对均已经协商完成,包括加密密钥,解密密钥,HMAC相关的密钥...这个point可以注入的信息有:密钥对信息;密钥操作方向信息等;
所有的注入操作我并没有用ioctl,因为这样需要建立一个字符设备,或者修改tun驱动或者建立一个socket,而我不想污染tun,也不想污染devfs,其实ioctl本身就是一种带有京味的污染源,于是我采用了netlink,如果是在脚本中操作,我则更喜欢选择procfs。
       写到这里,发现文字描述真的太累,任何文字在示意图和代码面前都是苍白的,这就是程序员为何喜欢写代码或者画图的根本原因,别跟程序员扯理论,先把代码跑起来再说吧。其实,看了GEB之后明白了一个真理,为何人对图的敏感度要优于文字,因为图是一个二维或者三维的being,而文字则是一个抽象的一维线索,必须串行处理,也就是说,理解文字意味着你的大脑需要不断进行压栈,弹出操作,而理解图片则真正的可以动用大脑的并行处理优势!我将上面的一大堆文字表示成一个图:




当然了,我在图上写下了太多的文字,以至于显得很乱,但是如果不加那些文字,可能会更乱,因为Netfilter的效果就是你可以“在任何地方将skb带到任何地方”,两个任何现实了“乱”的精髓,但是也同样表达了,真正的出神入化就是“乱得可以”。好了,如果连图都觉得很乱,那么就跑代码吧,在给出代码之前,先给出用法:
1.启动一个OpenVPN服务端:cipher设置为none,auth设置为none,你知道,如果协议跑通了,这些都不是事儿,毕竟那些算法只是独立的另一个库实现,相当独立。加载nf_ovpn_helper.ko,即可
2.启动OpenVPN客户端:cipher设置为none,auth设置为none
3.在虚拟IP上跑一些数据:比如用iperf试试看...panic?oh no!
4.开启真正的debug之旅...

代码和图一样,依然给出了大量的文字说明,其分量和代码差不多...代码如下:

/*
 * 整个城市向黑暗中退去,你我都放弃忍耐
 */
#include <linux/module.h>
#include <linux/netfilter.h>
#include <linux/ip.h>
#include <linux/inet.h>
#include <net/net_namespace.h>

#include <net/netfilter/nf_conntrack.h>

#include "ovpn_func.h"

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Wangran <[email protected]>");
MODULE_DESCRIPTION("OpenVPN connection helper");
MODULE_ALIAS("ip_conntrack_ovpn");
MODULE_ALIAS_NFCT_HELPER("ovpn");

/* 
 * 此端口难道就这么写死成1194吗?难道不是需要注册的吗 :(
 **/
#define OVPN_PORT	1194

struct ovpn_instance {
	__be32 saddr;
	__be32 daddr;
	__be16 sport;
	__be16 dport;
	__be32 packet_id;
    /* 请恕我这么写,反正没有实际实现 */
	unsigned char *info[0];
};

/* fake struct nf_conn_counter*/
struct instance_info {
	u_int64_t i;
	u_int64_t j;
	__be32 saddr;
	__be32 daddr;
	__be16 sport;
	__be16 dport;
	__be32 packet_id;
};

/* 真实的packet_id应该从慢速路径或者控制路径的Netlink消息传递到conn的extend中 */
__be32 static_fake_packet_id = 0;

static int ovpn_nf_pre_routing(struct sk_buff *skb)
{
	/* nothing to do */
	return NF_ACCEPT;
}

/* 第二个参数真的需要吗,因为加密所需要的cipher_info以及封装需要的udp头,ip头信息全部
 * 而不是部分地保存在了conntrack info信息中了啊啊啊
 *
 * 注意:这里的参数并不符合规范,因为我盗取了heler的结构体,但是思想是一致的!
 **/
static int encap_xmit(struct sk_buff *skb, struct ovpn_instance *ovpn)
{
	/*
	 * 正如我一贯的风格,我总是无情推翻昨天的自大,将欢乐瞬间变成悲哀
	 * 我没有调用ovpn_data_channel_encap_xmit这个tun网卡的HOOK函数,因为
	 * 我觉得太垃圾了,其实我正在逐步还原tun.c,就像这次一样,我力图使用
	 * Netfilter进行短路操作,而不再触摸tun.c以及UDP socket。就像你看到
	 * 的那样,你依然可以加载系统自带的原生态tun.ko
	 **/
	int ret = NF_DROP;	
	int copy = 0;
	unsigned int max_headroom;
	struct sk_buff *skb_to_encap;
	__be32 saddr = ovpn->saddr;
	__be32 daddr = ovpn->daddr;
	__be16 sport = ovpn->sport;
	__be16 dport = ovpn->dport;
	__be32 packet_id = ovpn->packet_id;
	struct iphdr *old = ip_hdr(skb);
	/* but 怎么判断OpenVPN是UDP的 
     * 很简单,一切都在nf_conn的extend中,
     * 只是,我这里没有写而已!
     **/

#define I_THINK_THIS_LENGTH_ENOUGH_BECAUSE_OF_XXX  78    
	max_headroom = (I_THINK_THIS_LENGTH_ENOUGH_BECAUSE_OF_XXX +  
				    sizeof(struct iphdr)                +
				    sizeof(struct udphdr)               +
				    sizeof(struct ovpnhdr));

    if (skb_headroom(skb) < max_headroom || !skb_clone_writable(skb, 0)) {
        struct sk_buff *new_skb = skb_realloc_headroom(skb, max_headroom);
        if (!new_skb) {
            goto out;
        }
        skb_dst_set(new_skb, skb_dst(skb));

        skb_to_encap = new_skb;
        copy = 1;
    } else {
        skb_to_encap = skb;
	}
	/* ##################### encap OpenVPN #################### */
	{
        struct ovpnhdr *ohdr;
		skb_push(skb_to_encap, sizeof(struct ovpnhdr));
	    ohdr = ovpn_hdr(skb_to_encap);
		/* 慢速路径的packet_id必须反映到快速路径中来!! */
	    ohdr->id = htonl(packet_id);
	    ohdr->ocode = (P_DATA_V1 << P_OPCODE_SHIFT) | 0x0;
	}
	/* ##################### encap UDP #################### */
	{
		struct udphdr *uh;
	
		skb_push(skb_to_encap, sizeof(struct udphdr));
		skb_reset_transport_header(skb_to_encap);

		uh = udp_hdr(skb_to_encap);
		uh->source = sport;
		uh->dest = dport;
		uh->len = htons(skb_to_encap->len);
		uh->check = 0;
		uh->check = csum_tcpudp_magic(saddr, daddr, skb_to_encap->len,
								IPPROTO_UDP, csum_partial(uh,
						                                   skb_to_encap->len, 
							                                0));
	}
	/* ##################### encap IP #################### */
	{
		struct iphdr *iph;
		struct dst_entry *dst;

		skb_push(skb_to_encap, sizeof(struct iphdr));
		skb_reset_network_header(skb_to_encap);
		iph = ip_hdr(skb_to_encap);
		iph->version		=	4;
		iph->ihl		=	sizeof(struct iphdr)>>2;
		iph->frag_off		=	0;//old->frag_off;
		iph->protocol		=	IPPROTO_UDP;
		iph->tos		=	old->tos;
		iph->daddr		=	daddr;
		iph->saddr		=	saddr;
		iph->ttl		=	old->ttl;
		/* 这个reroute频繁用于OUTPUT Netfilter HOOK,但问Rusty本人,
		 * Netfilter的OUTPUT设计为何如何之好 */
		if (ip_route_me_harder(skb_to_encap, RTN_LOCAL)!= 0) {
			/* 无论如何都要STOLEN的 */
            if (copy) {
			    kfree_skb(skb_to_encap);	
            }
			goto out;
		}
		dst = skb_dst(skb_to_encap);	

		ip_select_ident(iph, dst, NULL);
	}
	ip_local_out(skb_to_encap);
    /* 偷走数据包,不再在曾经的路上继续 */
    ret = NF_STOLEN;
out:
	return ret;

}

static unsigned int ipv4_ovpn_in_local( unsigned int hook,
					struct sk_buff *skb,
					const struct net_device *in,
					const struct net_device *out,
					int (*okfn)(struct sk_buff *))
{
	int ret = NF_ACCEPT;
	struct nf_conn *ct;
	enum ip_conntrack_info ctinfo;
	struct net_device *dev = NULL;
	struct tun_struct *tun = NULL;

	ct = nf_ct_get(skb, &ctinfo);
	if (!ct) {
		goto out;
	}
	if (ct == &nf_conntrack_untracked) {
		goto out;
	}
	/* 注意,这个dev不该这么写死,应该从extend中获取,但是debug之旅如此奇幻,
	 * 你难道不想试试看吗?
	 */
	dev = dev_get_by_name(&init_net, "tun0");
	if (!dev) {
		goto out_not_put;
	}

	tun = netdev_priv(dev);;
	if (!tun) {
		goto out;
	}

	if (out && dev == out) {	
		/* 
		 * 这里要取出保存在conn中的所有信息,包括加密密钥
		 */
        /*
		 * cipher_info = (struct instance_info *)nf_conn_acct_find(ct);
		 * if (cipher_info != NULL) {  
		 * 	if (cipher_info->saddr != 0 &&
		 *			cipher_info->daddr != 0) {
         */
				struct ovpn_instance ovpn;
				ovpn.saddr = 0x32c7a8c0;/*cipher_info->daddr;*/
				ovpn.daddr = 0xe9c7a8c0;/*cipher_info->saddr;*/
				ovpn.sport = 0xaa04;/*cipher_info->dport;*/
				ovpn.dport = 0xaa04;/*cipher_info->sport;*/
				++ static_fake_packet_id;/*cipher_info->packet_id;*/
				ovpn.packet_id = static_fake_packet_id;/*cipher_info->packet_id;*/
				ret = encap_xmit(skb, &ovpn);
				goto out;	

	} 
out:
    dev_put(dev);
out_not_put:
    return ret;
}
static unsigned int ipv4_ovpn_in( unsigned int hook,
				struct sk_buff *skb,
				const struct net_device *in,
				const struct net_device *out,
				int (*okfn)(struct sk_buff *))
{
	int ret = NF_ACCEPT;
	struct nf_conn *ct;
	enum ip_conntrack_info ctinfo;
	struct iphdr *hdr = ip_hdr(skb);
	struct udphdr *uh;
	struct net_device *dev = NULL;	
	struct tun_struct *tun = NULL;
	__be32 saddr, daddr;
	__be16 sport, dport;
	int dir;

	ct = nf_ct_get(skb, &ctinfo);
	if (!ct) {
		goto out;
	}
	if (ct == &nf_conntrack_untracked) {
		goto out;
	}
	/* 注意,这个dev不该这么写死,应该从extend中获取,但是debug之旅如此奇幻,
	 * 你难道不想试试看吗?
	 */
	dev = dev_get_by_name(&init_net, "tun0");
	if (!dev) {
		goto out_not_put;
	}

	if ((in && in == dev) || (in && in == init_net.loopback_dev)) {
		goto out;
	}

	tun = netdev_priv(dev);;
	if (!tun) {
		goto out;
	}

	switch (tun->flags & TUN_TYPE_MASK) {
	case TUN_TAP_DEV:
		goto out;
	}

	saddr = hdr->saddr;
	daddr = hdr->daddr;

	/* 到达此处的数据包有以下几类:
	 *	1.正方向的UDP到将欲到达OpenVPN的数据包
	 *		1.1.控制通道数据包
	 *			这类数据包将最终穿过INPUT,完成conntrack的confirm,至此conntrack建立
	 *		1.2.数据通道的数据包
	 *			这类数据包就是我要截获,解密,进而STOLEN的。This is it!!!
	 *	2.从OpenVPN进程socket发出的数据包
	 *		2.1.控制通道数据包
	 *			这类数据包来自OpenVPN进程,用于SSL握手以及PING(keepablive)
	 *		2.2.数据通道数据包
	 *			这类数据包本来来自OpenVPN进程,由其加密,但是由于它们将在tun的xmit中被截获自行进行OpenVPN/UDP/IP封装,
	 *			因此并不会到达此处,也可以在OUTPUT/PREROUTING中被识别并自行进行OpenVPN/UDP/IP封装并被STOLEN到dev_queue_xmit
	 *			......
	 *
	 **/
	dir = CTINFO2DIR(ctinfo);
	if (dir != IP_CT_DIR_ORIGINAL) {
		goto check_encap_xmit;
	}
	/* 此处没加锁啊没加锁!!! */
	if (hdr->protocol != IPPROTO_UDP) {
	/*
	 * 这里彻底呈现了UDP的优势
	 * 你可能不信!但是如果是TCP,你将不能在中间任何地方截获(STOLEN)数据!
	 * 因为TCP是端到端流协议,你要是截获了数据,怎么发送回执??
	 * 你没法ACK数据,TCP将不再继续!除非...
	 * 除非你连ACK也伪造!连带的,你难道要自己实现TCP的语义?? 
	 **/
		goto check_encap_xmit;
	}

	skb_pull(skb, ip_hdrlen(skb));
	skb_reset_transport_header(skb);
	/* 此处省略了UDP接收的例行校验检查 */
	uh = udp_hdr(skb);
			
	if (uh->dest != htons(OVPN_PORT)) {
		skb_push(skb, ip_hdrlen(skb));
		skb_reset_network_header(skb);
		goto check_encap_xmit;
	}
	sport = uh->source;
	dport = uh->dest;
	{
		/*
		 *  这里要取出保存在conn中的所有信息,包括解密密钥
		 *	ct_inner = nf_ct_get(skb, &ctinfo_inner);
		 *	cipher_info = nf_conn_acct_find((const struct nf_conn *)ct_inner);
		 *	if (cipher_info == NULL) {  
		 *		...
		 *		...
		 *
		 */
	}	
    /* decrypt 
     * 很显然,这是关键!数据解密!
     * 但是谁能告诉我内核中怎么高效使用加解密,如果不能高效,
     * 那么起码保证灵活,就像OpenSSL那样!进入了内核态,我突然
     * 突然想到了OpenSSL的好,人,不能忘本啊  :<
     */
	/*
	 *  以上是我在udp_encap_rcv版本中的注释!!但是,但是
	 *  天啊!饶恕我的贪婪吧!
	 *  在nf_conntrack_helper版本中,我连封装的力气都没有了,为了尽快验证,
	 *  我将代码写死!
	 *  解密算法:AES-128-ECB
	 *  解密密钥:128位的0!
	 */
	/* ################################################################### */
	/* 验证伊始,推进一个udp头 */
	skb_pull(skb, sizeof(struct udphdr));
	{
		/* PRE Decrypt--对齐数据,验证操作码 */
	    u8 *data = skb->data;
	    u8 ocode = data[0];
	    int op = ocode >> P_OPCODE_SHIFT;
	    if (op != P_DATA_V1) {
			skb_push(skb, sizeof(struct udphdr));
			skb_push(skb, ip_hdrlen(skb));
			skb_reset_network_header(skb);
			skb_reset_transport_header(skb);
		    goto out;		
	    }
	}
	/* ################################################################### */
	{
		/* Decrypt--调用内核接口解密数据 */
        /*int i;
		struct crypto_cipher *tfm;
		unsigned char key1[16] = {0};
        unsigned char *data;

		tfm = crypto_alloc_cipher("aes", 0, CRYPTO_ALG_ASYNC); 
		if (!tfm) {
			return NF_DROP;
		}
		crypto_cipher_setkey(tfm, (const u8 *)&key1[0], 16);
        data = skb->data + 1;
        for (i = 0; i < skb->len - 1; i += crypto_cipher_blocksize(tfm)) {
            crypto_cipher_decrypt_one(tfm, data + i, data + i);
        }       
		crypto_free_cipher(tfm);
		*/
		/* 解密完成,推进一个OpenVPN头的长度 */
		skb_pull(skb, sizeof(struct ovpnhdr));
	}
	/* ################################################################### */

	switch (tun->flags & TUN_TYPE_MASK) {
	case TUN_TUN_DEV:
        switch (skb->data[0] & 0xf0) {
                /* 当前只支持IPv4 */
        case 0x40:
            break;
        default:
			/* 解密发现不是IPv4,不再恢复skb指针 */
			ret = NF_DROP;
            goto out;
                    
        }
        skb_reset_mac_header(skb);
		skb_reset_network_header(skb);
		skb_reset_transport_header(skb);
            /* 是时候丢掉西装外衣了,口袋里的通行证会将你引入深渊,
             * 不信的话,注释此言,在OpenVPN客户端机器上ping一下
             * 服务端的虚拟IP试一试 
             **/
        skb_dst_drop(skb);
        skb->protocol = htons(ETH_P_IP);;
        skb->dev = dev;
        ret = NF_STOLEN;
        break;
	}

    /* 模拟TUN虚拟网卡接收,此时截获处理正式完成,
     * 告诉UDP,嗨,你的数据我已经帮你处理了 
     **/
	/*	遍历PREROUTING旨在创建被OpenVPN封装流量的conntrack,
	 *	因为只有在这里才能从OpenVPN数据通道的conntrack中的info信息得到加密密钥:
	 *	1.该类流量在netif_rx_ni->netif_receive_skb->ip_rcv...路径中径直通过PREROUTING;
	 *	2.该类流量的reply流量直接使用其conntrack info中的加密密钥进行加密
	 **/
	nf_reset(skb);
    /* 溜达溜达,一直溜达到skb的conntrack被设置,所以我使用了带有condition的版本 */
	NF_HOOK_COND(PF_INET, NF_INET_PRE_ROUTING, skb, skb->dev, NULL,
						ovpn_nf_pre_routing, skb->nfct != NULL);
	{
		/*struct nf_conn *ct_inner;*/
		/*enum ip_conntrack_info ctinfo_inner;*/
		/*struct instance_info *cipher_info; */
		/* OK! 此时的ct应该就是OpenVPN裸skb的ct了! */
		/*
		 *  注意,这里可能比较绕!对于ct_inner,很显然它是OpenVPN数据协议封装的内部skb的ct,那么
		 *  它的方向有两个,一个是正一个反,
		 *  1.对于正方向,很显然它是我们在上面的ovpn_nf_pre_routing
		 *	  这个fake HOOK中建立的,理所当然它的cipher_info就是在这里创建的
		 *	2.对于反方向,它走的是慢速路径,即它走的是OpenVPN进程(这是为什么呢?为什么呢?
		 *			因为:
		 *				skb来自某个物理网口,显然最终它要从tun0中xmit出去,这一路上它是不可能获得
		 *				任何关于multi_instance的信息的,所以只好走入慢速路径中,由OpenVPN进程从字符
		 *				设备读取该数据包,然后由OpenVPN进程加密,封装,传输之)
		 *	  只要有反向发起的数据包的正向(即从OpenVPNclient到OpenVPNserver方向)返回包经由此处,它将
		 *	  建立cipher_info。
		 *	因此,此处并不区分对待ct的方向!
		 **/

        /*
		ct_inner = nf_ct_get(skb, &ctinfo_inner);
		cipher_info = (struct instance_info *)nf_conn_acct_find((const struct nf_conn *)ct_inner);
		if (cipher_info == NULL) {  
			cipher_info = (struct instance_info *)nf_ct_acct_ext_add(ct_inner, GFP_ATOMIC);  
			if (cipher_info == NULL) {
				ret = NF_DROP;
				goto out;
			}  
			goto alloc_info;
		} else {
			// 注意:最终的成型info extend中,需要在destroy里面释放 JUST test!!
			if (cipher_info->saddr == 0 && cipher_info->daddr == 0) {
alloc_info:
				cipher_info->saddr = saddr;
				cipher_info->daddr = daddr;
				cipher_info->sport = sport;
				cipher_info->dport = dport;
				// info 就是cipher 
			}
		}
        */    
	}
    /* 真是谢天谢地!谢什么?答曰:
     * 在调用netif_rx的时候竟然还能保留nf信息,比如保留nf_conn...
     * 其实这也没什么大不了的,难道bridge模块没有这么玩吗?难道bonding,vlan没有这么玩吗?
     * 如果你不懂,没关系,试试看: 
     * sysctl -w net.bridge.bridge-nf-call-iptables=1
     * 然后跟一下代码...
     **/
	netif_rx_ni(skb);
    goto out;

check_encap_xmit:
    /* 此处find conntrack的info信息,如果数据包从物理网卡接收,最终需要通过tun网卡发出进行加密,那么:
     * 1.该数据包所属的流在从OpenVPN客户端过来的时候在PREROUTING中被解密,然后在PREROUTING中溜达到conn创建,
     *   此时,该流可以查到,直接取出info信息,调用encap_xmit进行加密;
     * 2.该数据包所属的流是主动从OpenVPN服务端发往OpenVPN客户端方向的,那么它在这个HOOK就应该直接返回,进入
     *   OpenVPN这个慢速路径进行加密,如果有从OpenVPN客户端回来的包,那么在这个HOOK中就会被在conntrack的info
     *   中设置info信息。
     * :)也已经深了,我以上如此清晰的思路想必可以代替代码吧,此处我就直接通过了。
     **/
    {
        int check = 0; /* 真正的check! */
        if (check) {
			struct ovpn_instance ovpn;
            ret = encap_xmit(skb, &ovpn);
        }
    }

out:
	dev_put(dev);
out_not_put:
    return ret;
}

static struct nf_hook_ops ipv4_ovpn_ops[] __read_mostly = {
	{	.hook		= ipv4_ovpn_in,
		.owner		= THIS_MODULE,
		.pf		=	NFPROTO_IPV4,
		.hooknum	= NF_INET_PRE_ROUTING,
		.priority	= NF_IP_PRI_CONNTRACK + 1,
	},
	{	.hook		= ipv4_ovpn_in_local,
		.owner		= THIS_MODULE,
		.pf		=	NFPROTO_IPV4,
		.hooknum	= NF_INET_LOCAL_OUT,
		.priority	= NF_IP_PRI_CONNTRACK + 1,
	},
};


static void nf_conntrack_openvpn_fini(void)
{
	nf_unregister_hooks(ipv4_ovpn_ops, ARRAY_SIZE(ipv4_ovpn_ops));
}

static int __init nf_conntrack_openvpn_init(void)
{
	int ret = 0;

	ret = nf_register_hooks(ipv4_ovpn_ops, ARRAY_SIZE(ipv4_ovpn_ops)); 
	if (ret) {
		printk("nf_ct_ovpn: failed to register\n");
		return ret;
	}
		printk("nf_ct_ovpn: OKOK\n");
	return 0;
}

module_init(nf_conntrack_openvpn_init);
module_exit(nf_conntrack_openvpn_fini);


郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。