2017/05/06
【关于题外话在最后】
写作本文主要基于两点,首先是因为我前段时间写了几篇关于XXN的新解,收到了很多的邮件反馈,我也思考了很多,另一个方面是因为很多人问我怎么用QQ,P2P搭建一个IP层的Tunnel,我的回答是“我也不知道”。我确实不知道,根本就没有试过,只是有个这样那样的想法…我主要是没有动力和能力去Hack这些非Linux上的东西…所以说,我写这篇文章,用UNIX的方法 “将多个小工具结合起来” 实现我的那些没有实现的想法,抛砖引玉一下。
声明:
本文没有技术含量,甚至不会有什么代码,本文只是一些Linux bash和netcat的使用技巧之堆砌,但我觉得只有这种是理解Everything over App的最好方式,虽然我没有能力将TAP对接到QQ上,但我有能力将其对接到netcat以及ssh上,而netcat,ssh和QQ并没有什么本质的区别,结论是,只要你能找一个通信软件,Tunnel便可以嫁接于其上。
Tunnel的种类
一般而言,传统的Tunnel都是用新的IP报文来运输原始IP报文的,这种新的IP报文往往封装一个新的四层头。但是也有用TCP,UDP来运输原始IP报文的,典型的例子就是OpenXXN,BadXXN等。
事实上,你可以用任何的报文来运输原始IP报文,在上一篇文章《从一个简单的聊天程序SimpleChat看XXX技术》中,我提到你可以用QQ,P2P协议来运输IP报文,并且给出了一个应景的设想。本文将通过简单的实例来实现一下这种设想。
发展阶段
像类似PPPoE,L2TP什么的,提出了一个很好的框架和概念,说明IP over XXX的可行性,然后OpenXXN掀开了一次Revolution,说明IP可以over UDP,并且和SSL/TLS进行了深度结合,小众的BadXXN应该是另一次Revolution的,但是作者好像没有把握住机会,和OpenXXN不同的是,BadXXN旨在提供灵活且独立的点对点组网能力。
在研究了BadXXN之后,我自己写了一个简单的Demo,即SimpleXXN
https://github.com/marywangran/overlay
其实,BadXXN的思路很简单,这个和我们平时的聊天软件的思路完全一致,不同的是聊天软件运输的是我们键盘输入的消息,而BadXXN运输的则是从TAP网卡中读取的IP报文。借着这个思路,我觉得任何的可以进行网络通信的软件都可以运输IP报文,只需要将程序的输入和输出重定向到TAP网卡的输入和输出即可,这非常简单。
准备工作
如果说TAP网卡在文件系统中以一个文件的形式存在,那么事情会非常简单,比如tap0网卡在文件系统中有一个字符设备文件/dev/tap0,那么以scp为例,我便可以通过以下的命令来运输通过tap0传输的IP报文或者以太帧:
scp /dev/tap0 root@192.168.44.129:/dev/tap0
然而自打Linux 2.6.x(8<x<32)起,内核便不再提供这种机制了。至少在2.6.8的内核中,有一个ethertap的模块,它提供了我上述所说的“理想方法”,你只需要以下的命令便可以构建一个tap0文件:
modprobe ethertap
ifconfig tap0 10.10.10.10/24 up
mknod /dev/tap0 c 36 16
...
可是到了2.6.32内核,ethertap模块没有了,只剩下了tun模块,使用tun模块,无法直接建立tap0的设备文件,必须通过ioctl来显式设置它:
modprobe tun
tunctl -u root -t tap0
# 注意,tun模块让你无法通过命令构建一个可以直接读写的tap0设备文件,你必须写一个程序显式执行open/ioctl对,然后操作其文件描述符进行读写。
...
这意味着我不得不写一个程序了,而这令不会编程的我感到悲哀!我把该文件命名为tunio.c,如下所示:
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <net/if.h>
#include <linux/if_tun.h>
#include <sys/select.h>
#include <sys/ioctl.h>
#include <fcntl.h>
struct frame {
unsigned int len;
char data[2000];
};
// 为了便于重定向操作,我在本程序中只使用了3个文件描述符:TAP网卡字符设备,标准输入,标准输出
int main(int argc, char **argv)
{
int fd = -1;
struct ifreq ifr;
size_t len;
char buf[2004];
struct frame frm;
int i;
fd_set rd_set;
if( (fd = open("/dev/net/tun", O_RDWR)) < 0) {
exit(-1);
}
memset(&ifr, 0, sizeof(ifr));
ifr.ifr_flags |= IFF_NO_PI;
ifr.ifr_flags |= IFF_TAP;
snprintf(ifr.ifr_name, IFNAMSIZ, "%s", "tap0");
ioctl(fd, TUNSETIFF, (void *)&ifr);
while(1) {
int nfds;
int j;
FD_ZERO(&rd_set);
FD_SET(0, &rd_set);
FD_SET(fd, &rd_set);
char *tmp;
nfds = select(1024, &rd_set, NULL, NULL, NULL);
for (j = 0;j < nfds; j++) {
// 如果标准输入有动静的话
if(FD_ISSET(0, &rd_set)) {
unsigned int dlen;
// 从标准输入中读取数据长度
len = read(0, &dlen, sizeof(unsigned int));
// 按照指示的长度读取原始IP报文或者数据帧
len = read(0, frm.data, dlen);
// 将IP报文或者数据帧写入TAP设备
len = write(fd, frm.data, len);
}
// 如果虚拟网卡字符设备有动静
if(FD_ISSET(fd, &rd_set)) {
// 从网卡读取IP报文或者以太帧
len = read(fd, buf, sizeof(buf));
// 为了对端可以区分数据边界,加入了长度头
frm.len = len;
memcpy(frm.data, buf, len);
tmp = (char *)&frm;
// 将加入长度头的原始数据输出到标准输出
for (i = 0; i < len+sizeof(unsigned int); i++) {
printf("%c", tmp[i]);
}
}
// 刷新输出
fflush(NULL);
}
}
return 0;
}
将以上的代码编译成tunio即可:
gcc tunio.c -o tunio
然后就可以用这个tunio和其它的既有程序进行基于UNIX哲学的组合从而构建出一个看起来像那么回事的Tunnel了。
在继续之前,我不得不说一下不能继续使用ethertap的原因。
一个好好的ethertap为什么就下课了呢?其实很大的原因在于ethertap所依赖的Netlink机制被重构了。在2.4版本以及2.6的早期版本的内核中,Netlink消息是通过字符设备进行读写的,然而后来Netlink便不再采用字符设备了,而是采用socket API进行读写了,而socket并没有导出文件到文件系统这也是众所周知,socket仅仅导出文件到进程。然而这跟ethertap下课有关吗?有的!
ethertap之所以可以导出文件到文件系统,就是使用的Netlink字符设备,你看看上述的mknod命令,其major设备号36就是Netlink的major设备号:
#define NETLINK_MAJOR 36
在init_netlink中:
if (register_chrdev(NETLINK_MAJOR,"netlink", &netlink_fops)) {
...
在ethertap模块代码中,你看不到任何关于字符设备的逻辑,事实上ethertap的字符设备文件的读写逻辑已经被Netlink接管,这个从hard_xmit以及netif_rx这两个协议栈的读写接口中便可获知,它们都是直接与Netlink接口。
好了,现在Netlink不再采用字符设备的方式了,改由API调用的方式控制了,那么ethertap便面临两个选择,一个是也跟着采用API的方式进行控制,而这个与tun模块功能重复,另一个选择是为ethertap单独注册一个字符设备类型,或者将其注册到misc设备,但这样会使字符设备集合越来越臃肿…再者说了,不还有tun的吗?编个程序封装一下读写控制逻辑有那么难吗?所以说,只能下课了…
其实,虽然ethertap好用,但其实现方式是有问题的,试想如果大家都为每一个功能注册一个Netlink号码,或者注册一种字符设备,那么几乎可以肯定,这种横向的平坦拓展方式总有一天会让Netlink或者字符设备管理机制不堪重负…之前的ioctl问题就是一个例子。
下面开始真正有意思的东西。
使用netcat实现一个简单的Demo
小用一下这个被誉为“瑞士军刀”的小巧nc,我来展示一下IP报文是如何通过nc构建的连接运输到另一个任意节点的。
我把tunio的标准输出重定向到netcat的标准输入,然后把netcat的标准输出重定向到tunio的标准输入,事情就成了,这让整个事情变成了一个环:
是不是很简单呢?
那么怎么实现呢?虽然逻辑上上图已经足够简单,但是实现上还是需要一个pipe作为过渡的,因此我们先在两台机器上分别创建一个pipe:
mkfifo /tmp/tmp_fifo
接下来的玩法完全取决于你对netcat的熟悉程度,本文不讲netcat,只说Tunnel,所以直接给出命令:
# 机器1:
cat /tmp/tmp_fifo | ./tunio 2>&1 | nc -l 1567 >/tmp/tmp_fifo
ifconfig tap0 10.10.10.10/24 up
# 机器2:
cat /tmp/tmp_fifo | ./tunio 2>&1 | nc 192.168.44.100 1567 >/tmp/tmp_fifo
ifconfig tap0 10.10.10.20/24 up
然后你来试试在机器2上去ping机器1的tap0的地址,绝对通了。这下,我们在物理网络的TCP连接上成功构建了一个承载以太帧的Ethernet over TCP的Overlay,显然这还远远不够,我们来抓包看看。在机器2上执行:
curl 10.10.10.10
同时在机器1上抓包:
tcpdump -i any tcp port 1567 -n -w overlay1.pcap
打开这个overlay1.pcap,我们可见:
好吧,虽然很完美的完成了隧道封装,然而没有实现加密…某种意义上,这并不是XXN,具体为啥我在这里多说无益。技术归技术,我们现在的目标是实现加密传输。这简直太简单了。
在继续展示加密隧道之前,我必须来点题外话为netcat做点推广。在前几篇文章中,我提到了QQ,P2P,甚至差点连飞鸽传书都扯上,但这些对Linux用户来讲,都是被鄙视的。在Linux上难道不是netcat这把瑞士军刀最靠谱吗?如果两人都使用Linux,最轻便的聊天工具就是netcat,根本不用装别的什么乱七八糟的东西。
实现一个加密隧道:使用ncat
当然,按照UNIX的传统方法,使用netcat和一个加密解密的命令加上输入输出重定向,就能在上节例子的基础上实现加密隧道,比如可以nc…|mcrypt…,然而我没有成功!所以我不得不使用别的方案。
幸亏有一个好用的ncat可以使用,我直接就用了。其实还有一个cryptcat可用,但我没有用成功,如果用成功的,希望可以告诉我。我本人对bash重定向的掌握一直都是半吊子水平,所以用起来当然没有玩Netfilter,XXN这般得心应手。决定使用ncat,命令如下:
# 机器1:
cat /tmp/tmp_fifo | ./tunio 2>&1 | ncat -vnl 333 --ssl >/tmp/tmp_fifo
#【以下特意给出屏幕输出,以显示正在初始化加密套件】
ifconfig tap0 10.10.10.10/24 up
# 机器2:
cat /tmp/tmp_fifo | ./tunio 2>&1 |ncat -nv 192.168.44.100 333 --ssl >/tmp/tmp_fifo
#【以下特意给出屏幕输出,以显示正在初始化加密套件】
ifconfig tap0 10.10.10.20/24 up
同上面的netcat明文实例一样,依然在机器2上执行curl,在机器1上抓包,得到如下结果:
我不可能去解释这些密文是什么个含义,总之,这就是一条加密的隧道,构建成功了。至于说加密强度如何,不属于本文的范畴。
实现一个加密隧道:使用ssh
其实一开始我是希望使用scp来做tap0字符设备文件的传输的,中间我采用了一个fifo pipe来过渡,但是没有成功,貌似scp的源文件必须是Regular file才可以,不能是pipe。后来我决定放弃,进而寻找别的方案。毕竟,搞清楚scp并不是我的目的,其实我完全可以修改scp的源码使之适应pipe传输的,但是这样做毫无意义。
放弃了scp后,我转向了直接使用ssh来执行远程命令,ssh执行远程命令要比scp更加通用,而不仅仅只是一个“文件传输”机制。废了大力之后,也算是小成功了,仍然是上述的机制,我的命令如下:
# 机器1:
mkfifo /tmp/tmp_fifo
./tunio </tmp/tmp_fifo |ssh root@192.168.44.129 "cat >/tmp/tmp_fifo"
ifconfig tap0 10.10.10.10/24
# 机器2:
mkfifo /tmp/tmp_fifo
./tunio </tmp/tmp_fifo |ssh root@192.168.44.100 "cat >/tmp/tmp_fifo"
ifconfig tap0 10.10.10.20/24
这个更加对称,比使用netcat/ncat的方式更加对称,更加优雅,但是效率去不咋地。抓包我就不给出了,大家自己品鉴吧。
本质
总的来讲,扯以上这些,我就是想说明一个观点,构建一个加密的隧道其实非常简单,方法更是多种多样,如果有人问你什么是XXN,你给他展示一下用Linux2.4内核ethertap模块+netcat+mcrypt或者快速手写一个tunio,然后配合ncat或者配合ssh构建一条加密隧道,那么你就算彻底理解了XXN的本质,如果你能快速让QQ和tunio这类程序对接,那你就是百折不扣的高手!当然,我达不到这样的水平,我只是指路人,我只是鼓手。当然,如果你真的拿netcat,ncat,ssh和tunio,ethertap这类对接了,很多学院派,科班生会觉得你这根本不是XXN,因为在他们眼里,XXN就是L2TP,PPTP,…,MPLS之流,你这自己搭建的,根本就什么都不是…其实我觉得这种学院派才是什么都不懂。
XXN在概念上满足两点即可,第一就是V(虚拟),第二是P(专用),这两点分别用Overlay和加解密技术完全可以完美表达。至于是L2TP,…等,它们只是成熟的标准之作罢了,但完全没有做到大道至简。
感谢老一辈程序员使我可以写就本文
这部分本想放在文章最前面的,但是怕喧宾夺主,所以移到了最后。
说实话,本文根本没有任何技术含量,但是绝对可以引发人们的思考。在我2006年刚刚参加工作的时候,我什么都不懂。但我跟一帮上世纪90年代以及21世纪前5年的程序员一起学到了很多的东西,比如用鼠标线上网,用串口联网,…他们说以前的时候,以太网卡和网线是稀缺的,反而PS/2,RS232是常见的,人们普遍都是使用物理单机,然后依靠软盘,刻录光盘,后来的U盘作为介质来传输数据,这就好比我之前说的用卡车运数据时一样的。
如果说我在一块没有接线网卡(假设它没有接线依然可以运行)上抓到了一个数据帧,然后把这个帧放到了一个U盘里,将U盘通过卡车,轮船运送到了外国,在外国有人将这个数据帧注入到了一个没有接线的网卡里,那么在协议栈看来,这个主机就跟从网线上收到了这个数据帧是一样的…所以说,网线只是个介质。
在2010年的时候,我第一次知道了TAP网卡这种东西,发现IP数据报文还可以通过一个字符设备读到用户态应用程序,进而被加密后通过socket传输出去,我觉得这太妙了!这难道不是跟用串口联网一样的道理吗?用串口和用socket唯一的区别就是,前者将原始IP数据写进了串口,而后者将原始IP数据写入socket,在应用程序看来,这没什么不同,都是写入了一个文件而已。之所以可以这么理解,得益于UNIX的两个传统,一个是IO的文件本质,一切皆文件,读写文件即可,第二个是分层的协议栈模型,这使得Overlay成为了可能!
好吧,我来总结一下,其实没什么好总结的,几乎都一样:
- 串口联网:IP字符设备fd<—>APP<—>串口字符设备
- OpenXXN:IP字符设备fd(tun/tap)<—>OpenXXN<—>socket
- 本文范例:IP字符设备fd(tun/tap)<—>netcat/ncat/ssh<—>socket
大家都一样,最终大家都回归到了最开始的状态!中间的IPSec之流实乃昙花一现也。
鉴于此,我将我本文的简单返璞归真的方法自诩为另一种革命,承接于IPXXc,OpenXXN,BadXXN。如果你能玩的得心应手,就可以出神入化,随心所欲了,你的XXN数据将不再建立在协议的基础上,它甚至没有自己的协议,完全传输裸数据,因此也就没有任何的可以识别的Pattern。
不管是用USB联网,还是用串口联网,或者用任意APP上网,我们都要记住,这完全得益于一切皆文件以及分层协议栈的馈赠啊。你和想建立XXN连接的主机之间,无非有两种连接方式,第一种就是物理直连,即通过网线,串口线,USB线,无线等连接起来的,另一种就是逻辑连接,即虽然不是物理介质之间连接的,但却是可以通过TCP/IP协议栈连接在一起的,比如用一对socket就能互相通信。不管以上哪一类,XXN连接在乎的是只要能和对端保证TCP/IP可达即可。
推荐一本书,《全球城市史》,今天周六刚刚看完,虽然篇幅比较短小,但确实很好看,从这本书里思考,你可以看到我本文一样的观点。古代大家自给自足,都待在家里做工,后来大家集中式地先后走向工厂,走向写字楼,走向园区,如今随着交通和通讯技术越来越发达,大家再次回到了家里工作,同样都是在家工作,但层次却完全不同,可能在未来几十年,我们会再次回到男耕女织的生活,但是和古代的男耕女织却完全不同,古代的男耕女织是无组织的个体行为,而未来的男耕女织却是一个整体组织中的一环…以前,没有网线,网卡匮乏,大家用串口,USB,鼠标线等做Overlay,如今网络资源过剩,大家用TCP/IP做Overlay…网络技术在更高的层次上实现了回归。
想象一下大型机工作站时代,大家通过哑终端接入这些超级计算机,自己的终端可能离计算机很远,终端仅仅提供输入输出功能,根本没有计算功能,慢慢的计算资源逐渐移到了终端,这便开启了个人计算机时代,接下来,随着计算需求的增加,计算资源有一次集中了,这次不叫大型机了,这次叫云端,同样的,云计算也是在更高的层次实现了回归。