Tun 与 Tap 的区别是什么

看这几篇文章：

http://www.openvpn.net/index.php/open-source/faq.html

What is the principle behind OpenVPN tunnels?

Okay, here is a brief summary of the principle behind OpenVPN:

Imagine you had a direct physical wire (i.e. a long cable) connecting two computers (A and B) at different locations. On each computer there would be a /dev/longcable which would be a network device. You could route IP traffic over it, and do everything you could normally do with a network device.

Basically a tun device is like having a /dev/longcable except the OpenVPN daemon is the program that connects the /dev/longcable on computer A with the /dev/longcable on computer B so that you can use the internet rather than a real physical cable. But in this case it is called /dev/tun or whatever your OS prefers to call them.

Now the mechanism by which OpenVPN connects /dev/tun on computer A with /dev/tun on computer B is this: It simply creates an encrypted UDP connection over the internet between A and B and forwards traffic between /dev/tun on A with /dev/tun on B. Because of the clever way in which the tun and tap drivers were designed, it is possible for a program running entirely in user-space to effect this link, allowing OpenVPN to be a portable cross-platform daemon (like SSH), rather than an OS-specific kernel module (like IPSec).

The difference between a tun and tap device is this: a tun device is a virtual IP point-to-point device and a tap device is a virtual ethernet device. So getting back to the "long cable" analogy, using a tun device would be like having a T1 cable connecting the computers and using a tap device would be like having an ethernet network connecting the two computers. People who are running applications that need the special features of ethernet (which won't work on an IP-only network) will often bridge their physical local ethernet with a tap device (using a utility such as brctl on Linux), then VPN the tap device to another similar setup at the other end. This allows OpenVPN to route ethernet broadcasts and non-IP protocols such as Windows NetBios over the VPN. If you don't need the special features of ethernet (such as bridging capability), it's better to use a tun device.

Tun and tap devices can be interconnected to create a complex routing topology. Some people have created multi-node WAN networks over tap devices and actually run DHCP over the VPN so that clients can log into the virtual ethernet and request an IP address. I've even heard of people using Linux advanced routing to run OSPF (a kind of dynamic routing protocol) over the VPN WAN to allow for dynamic, fault-tolerant routing. They sky is the limit as far as the complexity of network you can build, but the basic building block is a VPN daemon such as OpenVPN connecting tun or tap devices on two different machines.

What is the difference between a TUN device and a TAP device?

A TAP device is a virtual ethernet adapter, while a TUN device is a virtual point-to-point IP link.

You cannot mix --dev tun and --dev tap on different ends of the connection. Use one or the other consistently.

What is Bridging?

Bridging is a technique for creating a virtual, wide-area ethernet LAN, running on a single subnet.

For practical information on bridging, see the Ethernet Bridging Mini-HOWTO.
What is the difference between bridging and routing?

Bridging and routing are two methods of linking systems via a VPN.
Bridging advantages

* Broadcasts traverse the VPN -- this allows software that depends on LAN broadcasts such as Windows NetBIOS file sharing and network neighborhood browsing to work.
* No route statements to configure.
* Works with any protocol that can function over ethernet, including IPv4, IPv6, Netware IPX, AppleTalk, etc.
* Relatively easy-to-configure solution for road warriors.

Bridging disadvantages

* Less efficient than routing, and does not scale well.

Routing advantages

* Efficiency and scalability.
* Allows better tuning of MTU for efficiency.

Routing disadvantages

* Clients must use a WINS server (such as samba) to allow cross-VPN network browsing to work.
* Routes must be set up linking each subnet.
* Software that depends on broadcasts will not "see" machines on the other side of the VPN.
* Works only with IPv4 in general, and IPv6 in cases where tun drivers on both ends of the connection support it explicitly.

What are the fundamental differences between bridging and routing in terms of configuration?

When a client connects via bridging to a remote network, it is assigned an IP address that is part of the remote physical ethernet subnet and is then able to interact with other machines on the remote subnet as if it were connected locally. Bridging setups require a special OS-specific tool to bridge a physical ethernet adapter with a virtual TAP style device. On Linux, for example, brtcl is this tool. On Windows XP or higher, select your TAP-Win32 adapter and your ethernet adapter in Control Panel -> Network Connections, then right click and select Bridge Connections.

When a client connects via routing, it uses its own separate subnet, and routes are set up on both the client machine and remote gateway so that data packets will seamlessly traverse the VPN. The "client" is not necessarily a single machine. It could be a subnet of several machines.

Bridging and routing are functionally very similar, with the major difference being that a routed VPN will not pass IP broadcasts while a bridged VPN will.

When you are bridging, you must always use --dev tap on both ends of the connection. If you are routing you can use either --dev tap or --dev tun, but you must use the same on both ends of the connection. --dev tun tends to be slightly more efficient for the routing case.

http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

http://www.openvpn.net/index.php/open-source/documentation/howto.html
Determining whether to use a routed or bridged VPN

See FAQ for an overview of Routing vs. Ethernet Bridging. See also the OpenVPN Ethernet Bridging page for more notes and details on bridging.

Overall, routing is probably a better choice for most people, as it is more efficient and easier to set up (as far as the OpenVPN configuration itself) than bridging. Routing also provides a greater ability to selectively control access rights on a client-specific basis.

I would recommend using routing unless you need a specific feature which requires bridging, such as:

* the VPN needs to be able to handle non-IP protocols such as IPX,
* you are running applications over the VPN which rely on network broadcasts (such as LAN games), or
* you would like to allow browsing of Windows file shares across the VPN without setting up a Samba or WINS server.