4. 左耳进右耳出的tun设备

introduction

tun/tap提供了一种用于发消息的新玩法. 假设你现在想要发一条tcp消息, 传统的玩法是创建一个socket, 然后通过折腾这个socket来达到发消息的目的. 但是tun/tap的玩法是你先往一个文件里写, 然后t/t进程从这个文件里读出这条消息以后再发到物理链路里去.

但为什么要折腾这一下呢?

这里面可以拿出来玩的点在于t/t进程是怎么发的, 发给谁的, 比如你, 想发消息给youtube.com, 然后请求内容进了t/t进程, t/t会不会直接发给yt? 不见得会, 如果经过合理配置, t/t不会那么老老实实, 而是可以发给另一个人. 这像什么? 是不是很像你的VPN?

听懂了吗? 你以为你是发消息给1.2.3.4, 但如果这个包真的丢到物理链路上去了, 是没有人知道1.2.3.4在哪儿的, 于是t/t把这条消息先发给2.3.4.5, 这个人知道1.2.3.4是谁, 然后他帮你转发过去, 这像什么? 是不是很像容器通信? 你以为你给容器发消息呢, 其实网上没有人知道这个容器IP到底是谁, 于是t/t帮你先发给宿主机, 然后宿主机转发给下辖的容器, 不错, 这正是flannel的玩法

传统的socket是怎么玩的

我觉得有必要先介绍一下传统socket是怎么玩的, 某App现在想要向网络中发送一条消息, 于是他先创建了一个socket, 然后他通过socket调用实现用户态&内核态的数据交互, 接下来这条消息会进网络协议栈, 继而通过eth0网卡发到网上. 这个过程, 就是我们所说的: "普通网卡通过网线收发数据包" (顺着网线来打我)

那么tun是怎么玩的

tun设备你要知道他本身没有任何发信息的能力, 他只有一层拦截&修改消息的能力, 我们回到上面的例子中, 这个App想要发消息给1.2.3.4, 于是他通过Socket API发消息:

• 协议栈收到这条消息以后判定这条消息应该从tun0设备发出, 消息发给了tun0

• /dev/tun0 收到了这条消息以后, 发现某个VPN程序已经将这个文件打开了, 于是将消息发送给VPN, 这个时候消息已经出内核态了

• VPN程序, 将目标IP修改成2.3.4.5后, 将这个消息通过Socket API发到协议栈里, 通过eth0网卡发出

你看到了吗? 他本身并不发任何消息, 他只负责将要发送的包, 转发给某个中间程序, 最后说到底还是要通过Socket发出去的.