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);