哥们儿拿到了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设置为none3.在虚拟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 marywangran@126.com MODULE_DESCRIPTION("OpenVPNconnectionhelper");MODULE_ALIAS("ip_conntrack_ovpn");MODULE_ALIAS_NFCT_HELPER("ovpn");/**此端口难道就这么写死成1194吗？难道不是需要注册的吗:(**/#defineOVPN_PORT 1194structovpn_instance{ __be32saddr; __be32daddr; __be16sport; __be16dport; __be32packet_id;/*请恕我这么写，反正没有实际实现*/ unsignedchar*info[0];/*fakestructnf_conn_counter*/structinstance_info{ u_int64_ti; u_int64_tj; __be32saddr; __be32daddr; __be16sport; __be16dport; __be32packet_id;/*真实的packet_id应该从慢速路径或者控制路径的Netlink消息传递到conn的extend中*/__be32static_fake_packet_id=0;staticintovpn_nf_pre_routing(structsk_buff*skb) /*nothingtodo*/ returnNF_ACCEPT;/*第二个参数真的需要吗，因为加密所需要的cipher_info以及封装需要的udp头，ip头信息全部*而不是部分地保存在了conntrackinfo信息中了啊啊啊**注意：这里的参数并不符合规范，因为我盗取了heler的结构体，但是思想是一致的！**/staticintencap_xmit(structsk_buff*skb,structovpn_instance*ovpn) *正如我一贯的风格，我总是无情推翻昨天的自大，将欢乐瞬间变成悲哀 *我没有调用ovpn_data_channel_encap_xmit这个tun网卡的HOOK函数，因为 *我觉得太垃圾了，其实我正在逐步还原tun.c，就像这次一样，我力图使用 *Netfilter进行短路操作，而不再触摸tun.c以及UDPsocket。就像你看到 *的那样，你依然可以加载系统自带的原生态tun.ko **/ intret=NF_DROP; intcopy=0; unsignedintmax_headroom; structsk_buff*skb_to_encap; __be32saddr=ovpn- saddr; __be32daddr=ovpn- daddr; __be16sport=ovpn- sport; __be16dport=ovpn- dport; __be32packet_id=ovpn- packet_id; structiphdr*old=ip_hdr(skb); /*but怎么判断OpenVPN是UDP的*很简单，一切都在nf_conn的extend中，*只是，我这里没有写而已！**/#defineI_THINK_THIS_LENGTH_ENOUGH_BECAUSE_OF_XXX78 max_headroom=(I_THINK_THIS_LENGTH_ENOUGH_BECAUSE_OF_XXX+ sizeof(structiphdr)+ sizeof(structudphdr)+ sizeof(structovpnhdr));if(skb_headroom(skb) max_headroom||!skb_clone_writable(skb,0)){structsk_buff*new_skb=skb_realloc_headroom(skb,max_headroom);if(!new_skb){gotoout;}skb_dst_set(new_skb,skb_dst(skb));skb_to_encap=new_skb;copy=1;}else{skb_to_encap=skb; /*#####################encapOpenVPN####################*/structovpnhdr*ohdr; skb_push(skb_to_encap,sizeof(structovpnhdr)); ohdr=ovpn_hdr(skb_to_encap); /*慢速路径的packet_id必须反映到快速路径中来！！*/ ohdr- id=htonl(packet_id); ohdr- ocode=(P_DATA_V1 P_OPCODE_SHIFT)|0x0; /*#####################encapUDP####################*/ structudphdr*uh; skb_push(skb_to_encap,sizeof(structudphdr)); 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)); /*#####################encapIP####################*/ structiphdr*iph; structdst_entry*dst; skb_push(skb_to_encap,sizeof(structiphdr)); skb_reset_network_header(skb_to_encap); iph=ip_hdr(skb_to_encap); iph- version = 4; iph- ihl = sizeof(structiphdr) 2; iph- frag_off = 0;//old- frag_off; iph- protocol = IPPROTO_UDP; iph- tos = old- iph- daddr = daddr; iph- saddr = saddr; iph- ttl = old- /*这个reroute频繁用于OUTPUTNetfilterHOOK，但问Rusty本人， *Netfilter的OUTPUT设计为何如何之好*/ if(ip_route_me_harder(skb_to_encap,RTN_LOCAL)!=0){ /*无论如何都要STOLEN的*/if(copy){ kfree_skb(skb_to_encap); } gotoout; dst=skb_dst(skb_to_encap); ip_select_ident(iph,dst,NULL); ip_local_out(skb_to_encap);/*偷走数据包，不再在曾经的路上继续*/ret=NF_STOLEN; returnret;staticunsignedintipv4_ovpn_in_local(unsignedinthook, structsk_buff*skb, conststructnet_device*in, conststructnet_device*out, int(*okfn)(structsk_buff*)) intret=NF_ACCEPT; structnf_conn*ct; enumip_conntrack_infoctinfo; structnet_device*dev=NULL; structtun_struct*tun=NULL; ct=nf_ct_get(skb, ctinfo); if(!ct){ gotoout; if(ct== nf_conntrack_untracked){ gotoout; /*注意，这个dev不该这么写死，应该从extend中获取，但是debug之旅如此奇幻， *你难道不想试试看吗？ */ dev=dev_get_by_name( init_net,"tun0"); if(!dev){ gotoout_not_put; tun=netdev_priv(dev);; if(!tun){ gotoout; if(out dev==out){ /* *这里要取出保存在conn中的所有信息，包括加密密钥 *//* *cipher_info=(structinstance_info*)nf_conn_acct_find(ct); *if(cipher_info!=NULL){ * if(cipher_info- saddr!=0 * cipher_info- daddr!=0){*/ structovpn_instanceovpn; 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); gotoout; }dev_put(dev);out_not_put:returnret;staticunsignedintipv4_ovpn_in(unsignedinthook, structsk_buff*skb, conststructnet_device*in, conststructnet_device*out, int(*okfn)(structsk_buff*)) intret=NF_ACCEPT; structnf_conn*ct; enumip_conntrack_infoctinfo; structiphdr*hdr=ip_hdr(skb); structudphdr*uh; structnet_device*dev=NULL; structtun_struct*tun=NULL; __be32saddr,daddr; __be16sport,dport; intdir; ct=nf_ct_get(skb, ctinfo); if(!ct){ gotoout; if(ct== nf_conntrack_untracked){ gotoout; /*注意，这个dev不该这么写死，应该从extend中获取，但是debug之旅如此奇幻， *你难道不想试试看吗？ */ dev=dev_get_by_name( init_net,"tun0"); if(!dev){ gotoout_not_put; if((in in==dev)||(in in==init_net.loopback_dev)){ gotoout; tun=netdev_priv(dev);; if(!tun){ gotoout; switch(tun- flags TUN_TYPE_MASK){ caseTUN_TAP_DEV: gotoout; saddr=hdr- saddr; daddr=hdr- daddr; /*到达此处的数据包有以下几类： * 1.正方向的UDP到将欲到达OpenVPN的数据包 * 1.1.控制通道数据包 * 这类数据包将最终穿过INPUT，完成conntrack的confirm，至此conntrack建立 * 1.2.数据通道的数据包 * 这类数据包就是我要截获，解密，进而STOLEN的。Thisisit！！！ * 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){ gotocheck_encap_xmit; /*此处没加锁啊没加锁！！！*/ if(hdr- protocol!=IPPROTO_UDP){ *这里彻底呈现了UDP的优势 *你可能不信！但是如果是TCP，你将不能在中间任何地方截获(STOLEN)数据！ *因为TCP是端到端流协议，你要是截获了数据，怎么发送回执？？ *你没法ACK数据，TCP将不再继续！除非... *除非你连ACK也伪造！连带的，你难道要自己实现TCP的语义？？ **/ gotocheck_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); gotocheck_encap_xmit; sport=uh- source; dport=uh- dest; *这里要取出保存在conn中的所有信息，包括解密密钥 * ct_inner=nf_ct_get(skb, ctinfo_inner); * cipher_info=nf_conn_acct_find((conststructnf_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(structudphdr)); /*PREDecrypt--对齐数据，验证操作码*/ u8*data=skb- data; u8ocode=data[0]; intop=ocode P_OPCODE_SHIFT; if(op!=P_DATA_V1){ skb_push(skb,sizeof(structudphdr)); skb_push(skb,ip_hdrlen(skb)); skb_reset_network_header(skb); skb_reset_transport_header(skb); gotoout; } /*###################################################################*/ /*Decrypt--调用内核接口解密数据*//*inti; structcrypto_cipher*tfm; unsignedcharkey1[16]={0};unsignedchar*data; tfm=crypto_alloc_cipher("aes",0,CRYPTO_ALG_ASYNC); if(!tfm){ returnNF_DROP; crypto_cipher_setkey(tfm,(constu8*) 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(structovpnhdr)); /*###################################################################*/ switch(tun- flags TUN_TYPE_MASK){ caseTUN_TUN_DEV:switch(skb- data[0] 0xf0){/*当前只支持IPv4*/case0x40:break;default: /*解密发现不是IPv4，不再恢复skb指针*/ ret=NF_DROP;gotoout;}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流量直接使用其conntrackinfo中的加密密钥进行加密 **/ 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); /*structnf_conn*ct_inner;*/ /*enumip_conntrack_infoctinfo_inner;*/ /*structinstance_info*cipher_info;*/ /*OK!此时的ct应该就是OpenVPN裸skb的ct了！*/ *注意，这里可能比较绕！对于ct_inner，很显然它是OpenVPN数据协议封装的内部skb的ct，那么 *它的方向有两个，一个是正一个反， *1.对于正方向，很显然它是我们在上面的ovpn_nf_pre_routing * 这个fakeHOOK中建立的，理所当然它的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=(structinstance_info*)nf_conn_acct_find((conststructnf_conn*)ct_inner); if(cipher_info==NULL){ cipher_info=(structinstance_info*)nf_ct_acct_ext_add(ct_inner,GFP_ATOMIC); if(cipher_info==NULL){ ret=NF_DROP; gotoout; } gotoalloc_info; }else{ //注意：最终的成型infoextend中，需要在destroy里面释放JUSTtest!! 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-wnet.bridge.bridge-nf-call-iptables=1*然后跟一下代码...**/ netif_rx_ni(skb);gotoout;check_encap_xmit:/*此处findconntrack的info信息，如果数据包从物理网卡接收，最终需要通过tun网卡发出进行加密，那么：*1.该数据包所属的流在从OpenVPN客户端过来的时候在PREROUTING中被解密，然后在PREROUTING中溜达到conn创建，*此时，该流可以查到，直接取出info信息，调用encap_xmit进行加密；*2.该数据包所属的流是主动从OpenVPN服务端发往OpenVPN客户端方向的，那么它在这个HOOK就应该直接返回，进入*OpenVPN这个慢速路径进行加密，如果有从OpenVPN客户端回来的包，那么在这个HOOK中就会被在conntrack的info*中设置info信息。*:)也已经深了，我以上如此清晰的思路想必可以代替代码吧，此处我就直接通过了。**/{intcheck=0;/*真正的check！*/if(check){ structovpn_instanceovpn;ret=encap_xmit(skb, ovpn);}} dev_put(dev);out_not_put:returnret;staticstructnf_hook_opsipv4_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,多看书，看好书。
