|
|
楼主 |
发表于 2009-11-24 11:30:34
|
显示全部楼层
最近研究OpenVPN，一直被内嵌的TUN/TAP驱动和它们的流程困惑着，处于一会明白，一会糊涂的交互状态下，因此，就求助于各路神仙大侠，呵呵，承蒙大家的支持，现在把这些交流过程转述出来，我想对于想理解TUN/TAP驱动，想理解OpenVPN的同道中人，也是大有裨益的，同时也请不吝赐教。
首先，我发了一封信给TUN/TAP的作者，Mattias Nissler 先生，请求他帮助解答一些TUN.TAP驱动和OpenVPN关系的问题，原文如下：
help:would you please give me some advise about OpenVPN TUN/TAP driver
Hi:
When I read the source code of OpenVPN, it uses TUN/TAP driver to exchange data between user space and kernel space. But when I read the TUN/TAP driver on FreeBSD and NetBSD system, I don't find any protocol-related work the TUN/TAP driver do.
So, my question is why should we use TUN/TAP driver as the OpenVPN driver? and what the relationship of a VPN Tunnel between the "real" physical ethernet driver and a TUN/TAP driver? and what's the facility we use TUN/TAP but not socket?
And I find many SOCKET are create but only one TUN/TAP driver is opened. How to map a TUN/TAP driver to a VPN tunnel and a VPN-client vs VPN server socket connection?
Thank you very much!
Yours sincerely!
Lingfen
2008-4-16
下面是Mattias Nissler 先生的答复，不得不佩服德国人的逻辑思维的慎密：
Hi,
I don't know whether I've understood all of your questions correctly,
but let's see what I can do.
On Wed, 2008-04-16 at 10:16 +0800, 切·格瓦拉 wrote:
> Hi:
> When I read the source code of OpenVPN, it uses TUN/TAP driver to
> exchange data between user space and kernel space. But when I read the
> TUN/TAP driver on FreeBSD and NetBSD system, I don't find any
> protocol-related work the TUN/TAP driver do.
What do you mean by protocol? Ethernet, IP, some VPN protocol? Apart
from that, the tun/tap code isn't supposed to do handle any protocol
tasks. It just provides a virtual network interface that userspace
applications can use to inject/extract raw packets into/from the kernel.
> So, my question is why should we use TUN/TAP driver as the OpenVPN
> driver? and what the relationship of a VPN Tunnel between the "real"
> physical ethernet driver and a TUN/TAP driver? and what's the facility
> we use TUN/TAP but not socket?
Well, the idea is to give the kernel another interface it can send data
to (or receive data from). All packets that the kernel sends via the tun
or tap interface will then be processed by openvpn. Openvpn then
forwards them via an ordinary TCP or UDP connection to the other side of
the tunnel via a physical interface (e.g. ethernet).
> And I find many SOCKET are create but only one TUN/TAP driver is
> opened. How to map a TUN/TAP driver to a VPN tunnel and a VPN-client
> vs VPN server socket connection?
If you have multiple openvpn tunnels, you can run multiple openvpn
instances and they will each use their own tun or tap interface. If you
set up an openvpn server to which multiple clients can connect you have
some kind of virtual ethernet segment and there is only one tun or tap
device that connects the operating system kernel to this virtual
ethernet segment.
Hope this helps!
Mattias
然后我好像都明白了，但是又不明白，就再发了一封信给他：
Thank you very much!
I get much help from your valuable suggestion and thanks a lot.
And, would you please give me a data flow description of the packet from the mobile user to the office server? I think the IP packets are routed as the following:
Mobile User Office Server
------------ ---------------
Telnet Client Telnet Server
------------ ---------------
|| /\
\/ ||
------------ ---------------
telnet data write to tun() telnet data receive from tun()
------------ -----/\------ User Space
-----||----------------------------------------||-----------------
-----\/----- ------------Kernel Space
write tun() read tun()
TUN/TAP driver TUN/TAP Driver
IP encapsulation IP decapsulation
---------------- -------------------
|| /\
\/ ||
---------------- -----------Kernel Space
------------------------------------------------------------------
---------------- -----------User Space
read tun() write tun()
|| /\
\/ ||
socket send to remote socket receive from remote
---------------- -----------User Space
------------------------------------------------------------------
---------------- -----------Kernel Space
ethernet driver ethernet driver
| | | |
| | | |
| -------------------------------------- |
| SSL VPN Tunnel |
---------------------------------------------
Do I have the right understand of the data flow of the OpenVPN? I will explain it as following:
1. When a mobile user want to telnet to his office telnet server, he use the c-term terminal and connect to the remote telnet server;
2. Then the OpenVPN capture the connect request, and get the data, write to the TUN/TAP virtual driver.
3. The TUN/TAP driver encapsulate the IP packet into a new IP pcaket(suppose we run in TUN mode,if TAP,encapsulate ethernet frame into a IP packet).
4. The OpenVPN deamon receive the TUN driver packet, encript the data, and use the application program socket send() function send it to the physical ethernet card.
----------------------------------------------------------------
5. The server VPN tunnel server socket listen at a virtual address and receive the tunnel packet.
6.OpenVPN server decript the packet payload, the write to the TUN driver.
7.TUN driver decapsulate the IP-in-IP, send the "telnet IP" packet to OpenVPN.
8.OpenVPN do some routing lookup, send it to the office server.
9.The ack packet vise versa.
Am I right?
回复的原文如下：
Hi,
seems you got the general idea, but got some details wrong. Let me
briefly sum up the data path:
1. Some program (e.g. telnet in your example) uses the socket API to
create a socket and send, say a UDP data packet to some server.
2. The operating system encapsulates the packet in UDP, IP and checks
the destination address when routing (i.e. deciding on which interface
to output the packet).
3. Assume the OS has selected the tun or tap interface to output the
packet. If it's a tun interface, the driver will receive an IP packet
from the kernel and make it available to openvpn. If it's a tap device,
the kernel hands over an ethernet packet.
4. Openvpn read()s on /dev/tapX or /dev/tunX and receives the packet.
5. Openvpn does encryption, encapsulation etc. sends the packet to its
peer using the socket API.
6. The packet is back in the kernel and is routed again. This time, a
physical network interface is selected, say an ethernet interface.
7. The ethernet interface driver receives the packet and puts it onto
the wire.
This is the sender part. I guess you will now be able to reconstruct
what happens when receiving packets. Basically, everything happens in
reverse order.
As I've already mentioned in the previous mail, encapsulation is done in
the kernel just like for ordinary network traffic.
Mattias |
|
发表于 2009-11-24 10:53:50
发表于 2009-11-24 11:05:36
