对lightweight VPN的理解
来源：互联网 发布：ipadpro绘画软件推荐 编辑：程序博客网 时间：2024/04/29 22:19
==============================================================================================================
--- index:
---------------------------------------------------------------------------------------------------------------
=> what is "lightweight" VPN ?
-----------------------------------------------------
=> [*][*][*] Forward summary: The common architecture design and implementation of user-level "lightweight" VPN # how it could be implemented in user-level
--- with the usage of TUN/TAP $(virtual_dev) or other similar $(virtual_dev)
=> [*][*][*] more advanced use of TUN/TAP $(virtual_dev)
=> key components in "lightweight" VPN architecture: $(virtual_dev), user-level VPN software
=> advantages and disadvantages for "lightweight" VPN # compared to heavyweight VPN (mainly ipsec)
-----------------------------------------------------
=> SSH "sshvpn"
=> VTun
=> CIPE
=> Tinc
=> OpenVPN
---------------------------------------------------------------------------------------------------------------
==============================================================================================================
@@ what is "lightweight" VPN ?
In the book:
<<VPNs.Illustrated.Tunnels.VPNs.and.IPsec>>
it introduce some lightweight VPN implemented by user-level software.
--- "VPN" is a rather general definition. There are many types of VPNs, and their definition / design / implementation
are different.
--- But it may be difficult to understand if without deep kernel-level networking knowledge.
--- As for "lightweight", it means these VPN softwares are purely ( or mostly ) implemented in user-level, compared to
those heavyweight VPNs implemented in kernel-level, like IPsec.
#
# see: <<VPNs.Illustrated.Tunnels.VPNs.and.IPsec>> / 8.1. Introduction
#
===============================================================================================================
@@-@ [*][*][*] Forward summary: The common architecture design and implementation of user-level "lightweight" VPN # how it could be implemented in user-level
The common architecture of user-level "lightweight" VPN is below:
#
# also see figures: <<Figure 7.58. Architecture for the SSH VPN>>
# <<Figure 8.1. IP and Ethernet Tunnels with VTun>>
#
----------------------------------------------------------------------------| |----------------------------------------------------------------------------
| |
VPN peer #a | | VPN peer #b
| |
| |
-------------------- | | --------------------
| VPN software | | negogiate | | VPN software |
application | | | to build L5 security channel | | |
| (encap, decap) | <------------ | ------------------------------------- | ----> | (encap, decap) |
| | | | | | application
| -------- | | | | -------- |
/\ | | | | | | | | | | /\
| ----|------ |-------- | | ----|------ |-------- |
| regular | | | | | | |
| traffic |-------- | L5 security channel, | | | ------------ |
| | | like SSL, TLS, | | | | |
user-level | | | DTS, SSH | | | | |
| | | | | | | |
----------------------------------------------------------------------- | | -------------------------------------------------------------------------
| | | | | | | |
kernel-level | | | | | | | |
\/ | \/ | | \/ | \/
-------------- | -------------- | | -------------- | --------------
| | | | | | | | | | | |
| TCP / IP | | | TCP / IP | | | | TCP / IP | | | TCP / IP |
| stack | | | stack | | | | stack | | | stack |
| | | | | | | | | | | |
--------------- | --------------- | | --------------- | --------------
| | | |
/\ | /\ | | /\ | /\
| | | | | | | |
| | | | | | | |
| | | | | | | |
\/ | \/ | | \/ | \/
| | | |
-------------- | --------------- | | --------------- | --------------
| | | | | | On the wire | | | | | |
| virtual_dev | <---- | physical_dev | <---------------------- Internet ------------------> | physical_dev | ------> | virtual_dev |
| | | | | | | | | |
--------------- --------------- | | ---------------- ---------------
| |
----------------------------------------------------------------------------| |----------------------------------------------------------------------------
The packet path description in word.
Egress packet path
#1. user-level regular application send a clean-text packet, through TCP/IP stack, to $(virtual_dev)
#2. $(virtual_dev) trap this clean-text packet, to user-level VPN software.
#3. VPN software encapsulate this clean-text packet, using its customized format ( probably with crypto work),
and send the secured packet, through L5 security channels ( like SSL, TLS, DLS, SSH ),
again, through TCP/IP stack, this time to $(physial_dev), thus send it on the wire.
Ingress packet path
#1. $(physical_dev) get a a secured packet, upload to TCP/IP stack, further to user-level VPN software.
#2. VPN software decapsulate this secured packet ( probably with crypto work ), and get the clean-text packet.
#3. VPN software push this clean-text packet, to $(virtual_dev). In turn, $(virtual_dev) forward the clean-text
packet, through TCP/IP stack, further to user-level regular application.
#
# --- <quote>: $(kdoc)/networking/tuntap.txt # <<kdoc---networking---tuntap.txt>>
#
# -----------------------------------------------------
#
# 2. What is TUN/TAP driver used for?
# As mentioned above, main purpose of TUN/TAP driver is tunneling.
# It is used by VTun (http://vtun.sourceforge.net).
#
# Another interesting application using TUN/TAP is pipsecd
# (http://perso.enst.fr/~beyssac/pipsec/), a userspace IPSec
# implementation that can use complete kernel routing (unlike FreeS/WAN).
#
#
# -----------------------------------------------------
#
# 3. How does Virtual network device actually work ?
# Virtual network device can be viewed as a simple Point-to-Point or
# Ethernet device, which instead of receiving packets from a physical
# media, receives them from user space program and instead of sending
# packets via physical media sends them to the user space program.
#
# Let's say that you configured IPX on the tap0, then whenever
# the kernel sends an IPX packet to tap0, it is passed to the application
# (VTun for example). The application encrypts, compresses and sends it to
# the other side over TCP or UDP. The application on the other side decompresses
# and decrypts the data received and writes the packet to the TAP device,
# the kernel handles the packet like it came from real physical device.
#
===============================================================================================================
@@-@-@-@ [*][*][*] more advanced use of TUN/TAP $(virtual_dev)
See: <<lx-kdoc---networking---tuntap.txt>> # $(kdoc)/networking/tuntap.txt
Depending on the type of device chosen the userspace program has to read/write
IP packets (with tun) or ethernet frames (with tap). Which one is being used
depends on the flags given with the ioctl().
......
4. What is the difference between TUN driver and TAP driver?
TUN works with IP frames. TAP works with Ethernet frames.
......
6. Does TAP driver support kernel Ethernet bridging?
Yes. Linux and FreeBSD drivers support Ethernet bridging.
---------------------------------------------------------------------------------------------------------------
In previous diagram, lightweight VPN usage is fro local user-level regular application.
However, we could see advanced usage of lightweight VPN.
--- actually, those advanced usage, is _NOT_ about lightweight VPN itself, but about how we use TUN/TAP $(virtual_dev).
---------------------------------------------------------------------------------------------------------------
--- As for TAP $(virtual_dev), since it is about L2 Ethernet frames, we could have:
--------> user-level <-----------------> remote VPN peer
| VPN software
native $(br) subsystem |
|
$(br_dev) |
|
| |
------------------------------------ |
| | | |
| | | \/
$(phy_dev) $(phy_dev) $(tap_dev)
To build a virtual switch which cross physical machine boundary, and L2 traffic is secured when crossing Internet cloud.
--- This is just like $(openvswitch), however, $(openvswitch) is not secured in their $(vport_gre) or $(vport_vxlan).
--- We could also configure a TUN $(virtual_dev) as a $(openvswitch) $(vport), this make $(openvswitch) secured.
---- [*][*] Well, this might be "L2 VPN" we hear about. That is, L2 traffic crossing Internet cloud is secured.
---------------------------------------------------------------------------------------------------------------
--- As for TUN $(virtual_dev), since it is about L3 IP frames, we could let it participate in L3 router logic:
configure a TUN $(virtual_dev) as a gateway.
Then L3 forwarding traffic through TUN $(virtual_dev), would be secured.
--- [*][*] Well, this might be "L3 VPN" we hear about. That is, L3 traffic crossing Internet cloud is secured.
===============================================================================================================
@@-@-@ key components in "lightweight" VPN architecture: $(virtual_dev), user-level VPN software
As we can see, these 2 components play critical roles:
$(virtual_dev)
user-level VPN software
---------------------------------------------------------------------------------------------------------------
--- We don't get user-level "lightweight" VPN software too much, because different software would have different
design and implementation.
---------------------------------------------------------------------------------------------------------------
--- We place more focus on $(virtual_dev) in this archtecture. # simply because I want to investigate kernel source code.
$(virtual_dev) is a virtual "net_device" provided by kernel. # well, in linux terms, but other OS also have this thing
Therefore, when we say "user-level lightweight VPN", we do _NOT_ say it is 100% purely implemented by user-level
code, but it still need some kind of kernel-level support, more or less.
For example: # as we see later in each VPN introduction
TUN/TAP device # $(virtual_dev) used by: SSH "sshvpn", VTun, Tinc, and OpenVPN
customized ones # used by: CIPE
#
# Unlike VTun, CIPE is implemented as a combination of a kernel module and
# a user-space daemon.
#
# ......
#
# Encrypting, UDP encapsulating, and sending and receiving IP datagrams are done
# in the kernel module, which provides a network device to which IP datagrams
# are routed.
#
The main function of $(virtual_dev) is:
pass egress traffic / ingress traffic, between user-level VPN software, and regular applications.
--- security work is mostly performed by user-level VPN software.
[tip] A exception is CPIE, which have its own set of kernel-level module, and
offload security work to kernel-level.
===============================================================================================================
@@-@-@ advantages and disadvantages for "lightweight" VPN # compared to heavyweight VPN (mainly ipsec)
#
# Books and websrc talks enough about advantages and disadvantages, here just for emphasize.
#
--- advantages:
#1. Portability is good.
If different OS kernels provide kernel-level support of $(virtual_dev), then lightweight VPN could be port
to different OS.
--- This is true, since linux / unix / bsd all provide TUN/TAP device.
#2. Great support from 3rd party library
We know VPN have crypto function ( algorithm or protocol ), ussually, these crypto function are far too complicated.
Fortunately, there are a lot of 3 party libraries for support, no only limited to crypto function, but many other
aspects.
Such as OpenSSL.
#3. If it causes problem, no harm to the whole system.
Suppose lightweight VPN dies, it would not crash the whole system. Just a user-level process die.
Compared to heavyweight VPN inimplemented in OS kernel networking stack, if it dies, very likely to crash
the kernel and the whole system.
#4. Since encapsulated packet of lightweight VPN, is a normal TCP / UDP packet ( but its L5 content is secured ),
therefore, no problem with NAT device.
--- ipsec has some problems with NAT, which need to be resolved by NAT-T.
---------------------------------------------------------------------------------------------------------------
--- disadvantages:
#1. performance is not good.
#1. packet path ( ingress / egress ) are longer.
#1.b. too many packet memory copy in ingress / egress packet path.
#1.c. usually, crypto function is implemented in user-level, may not be able to utilitize kernel-level
$(crypto) driver.
--- Currently, kernel-level $(crypto) export its function to user-level.
And there is some patch to OpenSSL to use native $(crypto) framework.
However, even with this, memory copy can not be saved.
#2. No standard.
Unlike heavyweight VPN ( mainly, ipsec ), which is standardalized by RFC. lightweight VPN is mainly
to define / design / implement things theirself.
So different lightweight VPN types can not interoperate.
===============================================================================================================
@@-@ SSH "sshvpn"
#
# --- quote: <<VPNs.Illustrated.Tunnels.VPNs.and.IPsec>> / 7.4. Building VPNs with SSH
#
---------------------------------------------------------------------------------------------------------------
In Chapter 6, we built our VPN by running PPP through an SSL connection. We could do that here as well in an essentially identical way.
Instead of using PPP, we illustrate another method by making use of a gtunnel-based application that we call sshvpn.
---------------------------------------------------------------------------------------------------------------
We set up our tunnel between bsd and laptop, using the architecture shown in Figure 7.58.
(^^Figure 7.58. Architecture for the SSH VPN)
Notice that the figure is similar to Figure 7.22: sshvpn starts an SSH client, with which it communicates via pipes. The SSH client, in turn, connects to the SSH server on laptop, and the SSH server starts another instance of sshvpn, which it communicates with via pipes. As in Figure 7.22, we have shown the two spawned processes as dashed boxes. All communication between the two instances of sshvpn TRavels through the SSH tunnel and so is encrypted and authenticated.
The rest of Figure 7.58 shows that the two instances of sshvpn are connected to their hosts' TCP/IP stacks via the tun0 interface. Thus, data written into the tun0 interface on bsd will be read by the sshvpn on bsd, sent through the SSH tunnel to the sshvpn on laptop, and, finally, written into the tun0 interface on laptop by the sshvpn running there.
--- The figure is a little misleading because the traffic that flows through the SSH tunnel must first travel through the TCP/IP stack again. For clarity, we have omitted showing that path.
A convenient way of visualizing this process is to think of the sshvpn/ssh combination on bsd and the sshvpn/sshd combination on laptop as network interfaces that happen to communicate with each other using the SSH protocol. To the applications that use the VPN, the tun0 interface appears to be exactly this. On the one hand, it appears like any other network interfacean Ethernet interface, sayand on the other hand, it communicates with its peer interface over an SSH tunnel.
---------------------------------------------------------------------------------------------------------------
......
(^^Figure 7.62. SSH VPN Datagram Format)
===============================================================================================================
@@-@ VTun
#
# --- quote: <<VPNs.Illustrated.Tunnels.VPNs.and.IPsec>> / 8.2. VTun
#
---------------------------------------------------------------------------------------------------------------
VTun (Virtual Tunnel) is a simple VPN that uses the tun device (FreeBSD, OpenBSD, NetBSD) or the tun/tap device (Linux, Solaris) to copy packets between the TCP/IP stack and the vtund program running in user space. Architecturally, VTun is similar to the SSH VPN that we built in Chapter 7.
---------------------------------------------------------------------------------------------------------------
VTun supports four types of tunnels:
IP
IP datagrams, after encryption and optional compression, are carried as payload data in either TCP segments or UDP datagrams.
Serial
VTun provides a virtual PPP connection, similar to that in Figure 4.3, in which the PPP frames are encrypted, optionally compressed, and transported in either TCP segments or UDP datagrams
Ethernet
After encryption and optional compression, Ethernet frames are carried as payload data in either TCP segments or UDP datagrams. This type of tunnel is similar to the IP tunnel except that Ethernet frames instead of IP datagrams are tunneled. This means that any type of network-layer protocol, not just IP, can be carried in the tunnel as long as it can use Ethernet as the interface layer.
Pipe
This type of tunnel is similar to using SSH to tunnel a user command. The input and output of the tunnel are pipes, so the output from a local program can be fed directly to the tunnel, which pipes it to the input of another program on the remote host. This type of tunnel is a sort of superpipe that operates across a network while encrypting/compressing the data it carries.
---------------------------------------------------------------------------------------------------------------
All these tunnels are similar to ones that we saw in Chapter 4. The IP and Ethernet tunnels merely connect the user-space vtund application to the bottom of the TCP/IP stack through the tun or tun/tap device. This configuration is illustrated in Figure 8.1.
(^^Figure 8.1. IP and Ethernet Tunnels with VTun)
--- As with Figure 7.58, this diagram is a little misleading because the traffic flowing through the tunnel must first travel through the TCP/IP stack again.
---------------------------------------------------------------------------------------------------------------
The configuration for the serial tunnels is similar to that shown in Figure 8.1, except that IP datagrams from the stack are first delivered to the PPP routines, where they are encapsulated into PPP frames. In the case of Linux and Solaris, the PPP routines are part of the kernel. In the case of FreeBSD, the PPP functionality is provided by another user-space application. In either case, the PPP frame is delivered to vtund, which sends it through the tunnel to the peer PPP routines in the remote host.
The configuration for the VTun pipe tunnels is shown in Figure 8.2.
(^^Figure 8.2. The VTun Pipe Tunnel)
In this case, each user application talks directly to vtund through pipes rather than using the TCP/IP stack. With this type of tunnel, vtund is providing application-to-application connectivity rather than a network-to-network connectivity.
---------------------------------------------------------------------------------------------------------------
Data entering a VTun tunnel can be operated on by any combination of three modules. The first module compresses the data, using either ZLIB, when TCP carries the payload, or LZO, when UDP carries the payload. The second module encrypts the data, and the third module performs traffic shaping by limiting the amount of bandwidth that a particular tunnel can use. The modules to use are chosen by a configuration file, as are the other tunnel parameters.
===============================================================================================================
@@-@ CIPE
#
# --- quote: <<VPNs.Illustrated.Tunnels.VPNs.and.IPsec>> / 8.3. CIPE
#
CIPE (crypto IP encapsulation) is another lightweight VPN that, like VTun, has some serious security problems. Unlike VTun, CIPE is implemented as a combination of a kernel module and a user-space daemon. Because of the kernel component, CIPE runs only on Linux and Microsoft Windows NT. Information and source code are available at the CIPE home page, <http://sites.inka.de/bigred/devel/cipe.html>.
CIPE encapsulates encrypted IP datagrams in UDP datagrams, as shown in Figure 8.6.
(^^Figure 8.6. CIPE Encapsulation)
This has an advantage over the VPNs that we built using SSL and SSH in Chapter 6 and Chapter 7, because CIPE tunnels will not have nested TCP connections that interfere with each other and affect throughput. Because the UDP header has unencrypted port fields (Figure 2.14), CIPE can interoperate with NAT/PAT.
Encrypting, UDP encapsulating, and sending and receiving IP datagrams are done in the kernel module, which provides a network device to which IP datagrams are routed. The network devices at the local and remote hosts serve as the endpoints of the tunnel.
The user-space daemon, ciped, controls the configuration, starting, stopping, and key-exchange protocol of the VPN. In addition, ciped can run a script when a VPN is brought up or torn down. This facility is useful for configuring routes and logging.
===============================================================================================================
@@-@ Tinc
#
# --- quote: <<VPNs.Illustrated.Tunnels.VPNs.and.IPsec>> / 8.4. Tinc
#
Next, we consider tinc, a system that can provide a VPN network rather than just an encrypted tunnel between two hosts or networks. We can think of a tinc VPN network as a graph of nodes, such as that shown in Figure 8.20, where the edges between the nodes are encrypted and authenticated tunnels. Typically, each node serves as a VPN gateway for one or more subnets behind it. A node could also be a stand-alone host participating in the VPN network. We examine version 1.0.3 of tinc.
(^^Figure 8.20. A Typical Tinc Network)
Routing within the VPN network is handled by tinc itself. For example, if node A wants to send a packet to node B, it can send the packet directly through the encrypted tunnel between it and node B. On the other hand, if node A wants to send a packet to node C, it must first send it to node E through the tunnel between nodes A and E. Node E will decrypt and then reencrypt the packet for the tunnel between it and node C and send it through the tunnel to node C. The nodes exchange connectivity information and calculate routing maps in a way reminiscent of OSPF (Chapter 2). This information is continually updated as nodes join or leave the network or become unreachable.
Architecturally, tinc is similar to VTun in that it is implemented entirely in user space. As with VTun, outbound packets are read from the stack, and inbound packets are written to the stack by means of the tun/tap device.
Tinc uses two channels for each VPN: a UDP-based tunnel to carry the payload data of the VPN and a TCP-based connection for the so-called metaconnection that is used to carry control data, such as routing and key-exchange messages. The tinc daemons communicate with each other over the metaconnection, using the tinc metaprotocol.
As with the other lightweight VPNs we've discussed, tinc can operate at either the IP or link layer. When operating at the IP layer, tinc is restricted to carrying IP datagrams. The link-layer mode is used to create Ethernet switches and hubs. We consider only the IP mode, but the link-layer mode is similar.
......
(^^Figure 8.21. Tinc Encapsulation)
(^^Figure 8.22. The Tinc Binary Packet)
===============================================================================================================
@@-@ OpenVPN
#
# --- quote: <<VPNs.Illustrated.Tunnels.VPNs.and.IPsec>> / 8.5. OpenVPN
#
---------------------------------------------------------------------------------------------------------------
Our final lightweight VPN is OpenVPN. Although OpenVPN shares many of the features of the other lightweight VPNs that we have studied, it makes more intelligent use of SSL than the others do and is consequently more secure. We examine OpenVPN version 1.6.0.
Architecturally, OpenVPN is superficially similar to tinc and VTun in that it is a user-mode program that communicates with the TCP/IP stack through the TUN/TAP interface. Running as a user program brings the usual benefits of portability and easy maintenance that we have seen with VTun and tinc. Like tinc, OpenVPN multiplexes two channels onto the VPN: a data channel that carries the users' IP datagrams and a control channel that handles such protocol chores as key negotiation and configuration.
OpenVPN encapsulates both the control and data channels in UDP datagrams. It uses the same ports for both channels, so a given UDP datagram can contain either a control or a data channel message. Because OpenVPN uses the TLS protocol for authentication and key exchange and because TLS requires a reliable transport layer, OpenVPN adds a reliability layer to the control channel, while maintaining best-effort delivery on the data channel. This ensures that TLS gets the reliability that it requires but that there will not be competing reliability layers on the data channel, so the interference we experienced with SSL (Chapter 6) and SSH (Chapter 7) VPNs will not occur.
As with the other VPNs we have looked at in this chapter, OpenVPN can carry either IP datagrams or Ethernet frames, that is, it can operate at either the IP layer or the data link layer. We shall restrict our attention to its use in carrying IP datagrams, but the details of the other mode are similar.
---------------------------------------------------------------------------------------------------------------
--- The OpenVPN Security Models
......
---------------------------------------------------------------------------------------------------------------
--- The OpenVPN Data Channel
As we mentioned earlier, OpenVPN provides a best-effort data channel that uses UDP datagrams as its transport protocol.
--- OpenVPN can optionally use a TCP connection instead of UDP datagrams. Although this is convenient in certain circumstances, it reintroduces the problem of competing reliability layers and should be avoided when possible.
With UDP, we get the familiar encapsulation, shown in Figure 8.25, that we've seen before.
(^^Figure 8.25. The OpenVPN Data Channel Encapsulation)
(^^Figure 8.26. The OpenVPN Packet Header)
(^^Figure 8.28. The OpenVPN Data Packet)
===============================================================================================================
@@-@ pipsecd # a userspace IPSec implementation
#
# --- <quote>: $(kdoc)/networking/tuntap.txt # <<kdoc---networking---tuntap.txt>>
#
2. What is TUN/TAP driver used for?
As mentioned above, main purpose of TUN/TAP driver is tunneling.
It is used by VTun (http://vtun.sourceforge.net).
Another interesting application using TUN/TAP is pipsecd
(http://perso.enst.fr/~beyssac/pipsec/), a userspace IPSec
implementation that can use complete kernel routing (unlike FreeS/WAN).
===============================================================================================================
@@ end
0 0
- 对lightweight VPN的理解
- MPLS VPN中对RT和RD的理解
- VPN的简单理解
- VPN的简单理解
- 对vpn的认识
- postgreSQL 的 lightweight lock
- 【miscellaneous】VPN的简单理解
- 對Win7的VPN客戶端“加密”的理解
- 网对网VPN
- 对博客的理解
- 对动力的理解
- 对类的理解
- 对package的理解
- 对IRP的理解
- 对接口的理解
- 对String的理解
- 对https的理解
- 对SPRING的理解
- Tomcat6性能优化
- java常见异常
- ADO学习（七）ADOX相关知识
- 猴子吃桃问题
- C++作业
- 对lightweight VPN的理解
- Winform开发框架之读卡器和条码扫描枪的数据接收处理
- 设计模式问答（四）
- C语言结构体前加typedef与否的区别
- android 多线程下载文件大小不对的问题
- Unity3D Mathf数学函数
- List<String>与String数组之间的转换问题
- xml解析与xml的生成
- netlink AF_NETLINK的usage pattern
