VPN之PPTP

PPTP产生的背景

在经济全球化的今天，随着网络，尤其是网络经济的发展，客户分布日益广泛，合作伙伴增多，移动办公人员也随之剧增。传统企业网基于固定地点的专线连接方式，已难以适应现代企业的需求。在这样的背景下，远程办公室、公司各分支机构、公司与合作伙伴、供应商、公司与客户之间都可能要建立连接通道以进行信息传送。

	而在传统的企业组网方案中，要进行远程LAN 到 LAN互联，除了租用DDN(Digital Date Network数字数据网，即平时说的专线上网)专线或帧中继之外，并没有更好的解决方法。对于移动用户与远端用户而言，只能通过拨号线路进入企业各自独立的局域网。这样的方案必然导致高昂的长途线路租用费及长途电话费。于是，虚拟专用网VPN（Virtual Private Network）的概念与市场随之出现。利用VPN网络能够获得语音、视频方面的服务，如IP电话业务、电视会议、远程教学，甚至证券行业的网上路演、网上交易等等。

VPN简介

虚拟专用网(Virtual Private Network)简称VPN，是建立在公共网络平台上的虚拟专用网络。顾名思义，虚拟，是因为它不提供物理上的端到端的专有连接；专用，是因为它可以在LAN、WAN等之间的网络通道里共享信息，为某一企业、团体服务。

虚拟专用网络是专用网络的延伸，它包含了类似 Internet 的共享或公共网络链接。通过VPN可以以模拟点对点专用链接的方式通过共享或公共网络在两台计算机之间发送数据。这个学名叫"虚拟专用网络"的VPN到底是个什么呢？

比方说：从北京到广州的班机，VPN就如机场在众多的的主干班机上辟出的一条临时专用班机来供贵宾直通到广州。并且，VPN的存在不会影响其它信息照常传递，又能像传统的专网一样保障内部信息在公共信道上传输时的机密性、完整性和可用性。

如果说得再通俗一点，VPN实际上是"线路中的线路"，类型于城市大道上的"公交专用线"，所不同的是，由VPN组成的"线路"并不是物理存在的，而是通过技术手段模拟出来，即是"虚拟"的。不过，这种虚拟的专用网络技术却可以在一条公用线路中为两台计算机建立一个逻辑上的专用"通道"，它具有良好的保密和不受干扰性，使双方能进行自由而安全的点对点连接，因此被网络管理员们非常广泛地关注着。

VPN的隧道协议主要有三种，PPTP，L2TP和IPSec，其中PPTP和L2TP协议工作在OSI模型的第二层，又称为二层隧道协议；IPSec是第三层隧道协议，也是最常见的协议。

PPTP简介

PPTP：点对点隧道协议 (Point to Point Tunneling Protocol）缩写

点对点隧道协议（PPTP）是一种支持多协议虚拟专用网络的网络技术,它工作在第二层。通过该协议，远程用户能够通过 Microsoft Windows NT 工作站、Windows xp 、 Windows 2000 和windows2003、windows7操作系统以及其它装有点对点协议的系统安全访问公司网络，并能拨号连入本地 ISP，通过 Internet 安全链接到公司网络

PPTP协议假定在PPTP客户机和PPTP服务器之间有连通并且可用的IP网络。因此如果PPTP客户机本身已经是IP网络的组成部分，那么即可通过该IP网络与PPTP服务器取得连接；而如果PPTP客户机尚未连入网络，譬如在Internet拨号用户的情形下，PPTP客户机必须首先拨打NAS以建立IP连接。这里所说的PPTP客户机也就是使用PPTP协议的VPN客户机，而PPTP服务器亦即使用PPTP协议的VPN服务器。

PPTP 只能通过 PAC 和 PNS 来实施，其它系统没有必要知道 PPTP。拨号网络可与 PAC 相连接而无需知道 PPTP。标准的 PPP 客户机软件可继续在隧道 PPP 链接上操作。

PPTP 使用 GRE 的扩展版本来传输用户 PPP 包。这些增强允许为在 PAC 和 PNS 之间传输用户数据的隧道提供低层拥塞控制和流控制。这种机制允许高效使用隧道可用带宽并且避免了不必要的重发和缓冲区溢出。PPTP 没有规定特定的算法用于底层控制，但它确实定义了一些通信参数来支持这样的算法工作。

PPTP控制连接数据包包括一个IP报头，一个TCP报头和PPTP控制信息

客户（PAC）：它负责向服务器建立安全的链接，将PPP数据报通过隧道的形式发送给服务器。

服务器（PNS）：负责断开来自PAC的隧道，从隧道中取出受保护的PPP数据报，检验这个保护，解密数据报，并转发被封装的PPP有效负载信息。

PPTP连接过程

PPTP是一种面向链接的协议，PAC和PNS维护他们的链接状态，当PAC发起到PNC的PPP链接时，会话建立，会话建立了两个链接，一个控制链接，一种数据链接。一旦会话建立，PAC和PNS就可以通过数据链接使用GRE来传输用户数据。一般地，我们将此数据链接称为隧道。

1，控制连接：

控制链接负责建立，维护和拆除数据隧道；它使用TCP作为传输协议来携带这个消息，目标的端口号为1723；这个链接可以从PAC或PNS建立。
在控制链接中，可以使用控制，管理两种基本的PPTP消息。

建立控制连接：

建立控制联系时，有两个初始消息的交换；
Start——Control——Connection——Request；
Start——Control——Connection——Reply。
发起者使用第一个消息，接受者用第二个消息回应。
当两个一起发送第一个请求起冲突时，IP地址高的起效果，另一个被拆除。
如果是版本不同，则以版本低的相链接。

维护控制连接：

Keepalive用于控制连接来确保PAC和PNS之间的连接存在，两台设备间的任何故障都可以快速检测到。有两种类型的Keepalive用于控制连接：
Echo——Request;
Echo——Reply.
PAC和PNS都可以发起Keepalive，如果在60S之内没有收到对等体任何类型的控制消息，将会产生Keepslive消息。当PAC或PNS一方没有收到发送请求的Echo——Reply回应包，控制连接将会终止。

终止控制连接：

控制连接也负责终止任何数据连接，以及它自身的连接。为了终止控制连接，使用2种消息：
Stop——Control——Connection——Request；
Stop——Control——Connection——Reply。
PAC和PNS都可以在控制连接中发起拆除过程，无论何时控制连接被终止，任何数据连接都将会终止。

隧道连接：

隧道携带所有用户PPP协议数据包，GRE是用于传这些PPP数据报的传输协议。

建立隧道连接：

当PAC和PNS之间Start——Control——Connection——Request，Start——Control——Connection——Reply两个信息交换，控制连接号后，下一步就是隧道连接的建立，下面的消息可能参与这个过程：
Outgoing——Call——Request;
Outgoing——Call——Reply;
Incoming——Call——Request;
Incoming——Call——Reply
Incoming——Call——Connected;
外出呼叫是由PNS发给PAC的，让PAC建立一条到PNS的隧道，这条信息也提供了PAC传输数据到PNS的传输规则。回应信息是由PAC发出的。
进入呼叫是由PAC发给PNS的，用于指明一个进入的呼叫正由PAC到PNS建立；回应消息是由PNS发送给PAC的，表示接受或者拒绝连接请求；已连接信息由PAC发给PNS由于响应回应包。

维护隧道连接：

隧道的参数，是在隧道连接时协商好的，也可以基于当前的网络条件改变参数，PNS通过Set——Link——Info消息来共享隧道操作参数。通常PNS将这个消息发送给PAC，告知它任何隧道/PPP配置变化。

拆除隧道连接：

当隧道连接不再需要的时候，它被PPTP设备拆除，用到下面2个消息：
Call——Clear——Request；
Call——Disconnect——Notify。

下面从数据报来解析PPTP的连接过程：

一、建立TCP连接

1，Client端向PPTP Server的1723端口发TCP SYN包，请求建立TCP连接；
2，PPTP Server接受TCP连接请求，回SYN ACK；

二、建立PPTP控制层连接

3. PPTP Client发送Start Control Connection Request；（有一点需要注意：这里的TCP的三次握手协议只运行了SYN和SYN ACK，我们的产品抓包是有三次握手。网上说很多实现都是这样做的，请不要死记书本上的“三次”握手。）
4. PPTP Server回Start Control Connection Reply。在PPTP的这几个数据包都是基于TCP连接的，需要特别注意的是TCP Flag中的PUSH位都是被置成1的。那么，PUSH是干嘛的呀？PUSH被置1表示发送端要求接收端在收到该message后立即送到应用层，而不是等到缓冲区满再发往应用层；
5. PPTP Client发Outgoing Call Request；（1999版本RFC介绍由PNS发起见附加）
6. PPTP Server回Outgoing Call Reply。到此为止，PPTP的控制层连接就已经建立起来了。下面的相当一部分工作都是由PPP协议来完成的。另外还有一个需要注意的变化，如果你足够细心的话，你会发现之后的packet是基于IP发送的，而不再是基于TCP了

三、PPTP协议的LCP协商

7. 接下来我们看到，Client和Server互发了一大堆LCP包，这实际是PPP协议中的LCP（Link Control Protol）协议。LCP is used for estabishing, configuring and testing data-link connection. 其中有几点要注意：
   （1） Client发送一个Configure-Request，把自己的link layer configure发给Server，Client端的Configure一般比较简单，所以Server一下子就接受了，立即回了一个Configure-Ack；
   （2） Server同时也必须发送一个Configure-Request，把自己的link layer configure发给Client，而这个configure包含的内容往往比较多；
   （3） 如果Client收到的Configure-Request中，有unknow的配置项，就会把这些项列出来发一个Configure-Reject包给Server；
   （4） Server端把Client不认识的配置项删掉，再次重发Configure-Request；
   （5） 这次Client收到的配置项全都认识了，开始检查是不是所有的配置都可以接受，如果接受的话LCP过程结束，否则把不能接受的配置项列出来发送Configure-Nak给Server；
   （6） Server再次修改配置项，再次发送Configure-Request；
   （7） Client发现这次的配置项全都认识，而且全都是自己可以接受的，回发Configure-Ack。
   （8） 到此为止，LCP就算完事了。其中如果有一个过程失败就会导致LCP协商失败。
8. Client和Server接受彼此的配置之后，PPTP的控制层会彼此互发Set Link Info；

四、PPP协议的身份验证

9. LCP协商完毕后，PPP协议的Server端会对Client端进行身份验证；
10. 可以选CHAP（PAP）、MS-CHAP、MS-CHAP-v2…进行验证，具体选项我们会在解析PPP协议时讲述，现在以CHAP为例，需要注意到以下几点：
    （1） Server发送Challenge，其中包括一个challenge string和server name；
    （2） Client回Response，其中包括用户名，和密码和challeng string。其中用户名以明文发送（这个需要特别注意），密码的challenge string经过单向hash算法后以密文形式发送；
    （3） Server发送success，表示身份验证成功。

五、PPP协议的NCP协商

11. 身份验证通过后，PPP双方会进行NCP协商，用来确定互相通信的网络层接口参数；
12. 接下来你会看到一大堆IPCP协商数据包，它是NCP基于TCP/IP的接口协商协议。Server和Client都要把自己的Miniport信息发给对方，告诉对方我以后就用它和你通信了，你同不同意请给回个话。具体过程如下：
    （1） Server把自己的Miniport信息通过Configure-Request发送给Client；
    （2） Client也把自己的Miniport信息通过Configure-Request发送给Server；（这个时候Client发出的配置信息是完全无效的数据，之所以要故意发无效数据，是要求Server来给自己分配IP等信息）
    （3） Client接受Server的接口配置，发送Configure-Ack；
    （4） Server发现Client的配置是无效的，自己给Client发送一组有效的配置信息，通过Configure-Nak发送给Client，其中主要是给他分配IP；
    （5） Client根据Server端发出的Configure-Nak，提取出给自己分配的IP、DNS等信息，并设置Miniport接口；
    （6） Client根据修改后的配置，再次发送Configure-Request；
    （7） Server接受Client的配置，发送Configure-Ack

六、CCP是干嘛的？

大家应该很少看到介绍CCP的资料，至少我是没看到过。它看起来像PPTP的Control Connection Protol的简写，但是是跑在PPP协议上的，所以应该和PPTP的控制层协议没有关系。我们发现在IPCP协商过程中穿插了很多CCP包，所以虽然少见但最好还是解释一下它是干嘛的；
CCP中包括了MPPC和MPPE的参数协商，也就是Microsoft Point-to-Point Compression 和 Microsoft Point-to-Point Encryption的参数协商，用来确定数据包中的压缩和加密算法和参数。

七、GRE协议发送Packets

13. 之后就是PPTP数据链路之间发送packets了，发送的是经过GRE封装过的PPP包。

八、PPTP链路维护
14. PPTP跑起来之后就是一大堆GRE包，但是每隔一段时间仍然会看到一些control message，是用来维护链路的；
15. 一端发送Echo-Request，注意是双方任意一端都可以发送该消息，不一定非得是Client或者Server。
16. 另一端收到Echo-Request之后必须返回Echo-Relpy。
17. 如果某一端在一段时间内不能收到Echo-Relpy，就会主动断开PPTP的控制层连接。

数据包过程总结

PPTP协议解析

PPTP协议大体上可以分为两部分：控制层连接和隧道，下面简要介绍两部分的功能。如果要详细了解PPTP协议请阅读RFC文档。

一、 Control Connection Protol

控制层连接是基于TCP建立的，PPTP Server监听TCP1723端口，等待Client的连接请求。

控制层的主要功能包括：

1. 彼此交换基本信息；

2. 负责创建、维护、删除Session；

3. 负责创建、维护、删除Tunnel；

4. 更新通信参数；（Set-Link-Info）

5. 维护控制层自身的连接状态。（Echo-Request、Echo-Reply）

其中需要注意的是控制层自身的状态维护。PPTP连接双方在一段时间内（60秒）如果没有收到任何控制层信息，就会发Echo-Request查询控制层连接状态，接收方会应答Echo-Reply。如果发送方在60秒内还没有收到应答就会断开控制层连接。（看上去很多，其实很简单。）

二、 Tunnel Protol

看了上面的叙述不难发现，控制层本身不负责传输有效载荷。那么真正的应用层数据是怎么传输的呢？答案是Tunnel。

RFC里给出的Tunnel的定义是这样的"A tunnel is defined by a PNS-PAC pair"。简单说就是一对CS就是一个tunnel。那么tunnel到底是怎么工作的呢？

在发送端，要把一个数据包发出去，需要首先把packet发到VPN的虚拟网卡，虚拟网卡把它变成GRE frame，然后发往IP层再次进行路由。数据包这次会被发往物理网络，并最终抵达PPTP Server端。

在接收端，从物理网卡上收到frame之后交给IP层，IP对其解包之后转发给VPN虚拟网卡，虚拟网卡再解包把它变成普通IP packet再次发往IP层，这次IP层知道是VPN对端发来的数据，直接交给TCP/UDP并最终抵达应用层

通过上面的过程你就可以理解为什么叫tunnel了。在应用层看来，Server和Client是直接点对点连接的，他们之间的媒介就是GRE。而这个GRE的底层并不是真正的点对点连接，而是建立在物理网络上的一个Tunnel，保护其中传输的数据，所以称之为隧道。与控制层相比，tunnel的结构要复杂得多。我们来看一下数据在tunnel的传输过程。

下图描述了数据在发送端的处理过程，下面解释一下每一个step在干什么。（接收端的处理过程完全相反）

1. 应用层调用TCP/UDP发送message；

2. TCP/UDP调用IP发送packets；

3. packets被路由到VPN的miniport；

4. Miniport调用PPP协议发包；

5. packets被封装成PPP包；

6. PPP包被发往PPTP；

7. PPP包被封装成GRE包；

8. GRE调用IP协议发送packets；

9. 新的packets被路由到物理网卡；

10. 调用网卡驱动发frame。

怎么样，挺乱的吧。其实际过程还要更乱一些。需要特别注意的是，最终从网卡上发出去的数据包被IP层封装过两次。第一次封装是在PPTP虚拟网络之上的，第二次封装是在物理网络之上的。注意看下面的图，在灰色部分已经有一次网络层的封装了，然后在GRE外围还会有一次网络层封装。