PPTP协议工作原理

PPTP隧道技术

点对点隧道协议（英语：Point to Point Tunneling Protocol，缩写为PPTP）是实现虚拟专用网（VPN）的方式之一。PPTP使用传输控制协议（TCP）创建控制通道来发送控制命令，以及利用通用路由封装（GRE）通道来封装点对点协议（PPP）数据包以发送数据。这个协议最早由微软等厂商主导开发，但因为它的加密方式容易被破解，微软已经不再建议使用这个协议。
PPTP的协议规范本身并未描述加密或身份验证的部分，它依靠点对点协议（PPP）来实现这些安全性功能。因为PPTP协议内置在微软视窗系统家族的各个产品中，在微软点对点协议（PPP）协议堆栈中，提供了各种标准的身份验证与加密机制来支持PPTP。 在微软视窗系统中，它可以搭配PAP、CHAP、MS-CHAPv1/v2或EAP-TLS来进行身份验证。通常也可以搭配微软点对点加密（MPPE）或IPSec的加密机制来提高安全性。
在Windows或Mac OS平台之外，Linux与FreeBSD等平台也提供开放源代码的版本。

      PPP协议：点到点协议（Point to Point Protocol，PPP）是IETF（Internet Engineering Task Force，因特网工程任务组）推出的点到点类型线路的数据链路层协议。

      GRE协议：GRE（generic routing encapsulation，通用路由封装）协议是对某些网络层协议的数据报进行封装，使这些被封装的数据报能够在另一个网络层协议中传输。
 

一、控制连接和隧道维护 

     在PPTP建立连接过程中，客户端先向服务器1723端口发送TCP连接请求，这里的TCP连接不是标准的三次握手，第三次回应的ACK会随着载荷一起发送，这样做的好处是可以节省一些网络流量，减少不必要的开销。在TCP连接完成以后，PPTP进入控制连接的建立，首先客户端会发Start Control Connection Request报文给服务端要求建立连接，服务器端接到后发送应答报文，客户端再次发送Outgoing Call Request，等到服务器端响应后控制连接建立。

     接着是标准的PPP协商，上面说过，PPTP是建立在PPP的基础上的隧道协议。这样先进行LCP层的协商，客户端跟服务器端双方都要把自己的链路层配置发送给对方，客户端的配置一般比较简单，服务器端收到后就会接受 ，而服务器端发给客户端的配置报文，客户端会对Unknow选项和不接受选项向服务器反馈，服务器收到后删除这些选项再次发送配置，客户端接受，LCP协商完成。此时在PPTP的控制层会互发Set Link Info报文来对刚刚协商好的选项进行配置。

     LCP协商完成后，服务器开始对客户端进行身份验证，可以选的验证方式很多，有PAP、CHAP、MS-CHAP等方式，身份验证后就进行NCP层协商。主要是来确定双方网络层接口参数，配置虚拟虚拟端口，分配IP、DNS等信息。

之后PPTP连接过程就算是完成，PPTP开始发送GRE封装的数据包，但每隔60秒，连接双方会发送Echo Request来询问链路是否可用，如果对方在此后60秒内没有响应，连接就会被终止。正常的连接终止时通过发送Stop Control Connection Request来通知对方结束连接。

1.Start-control-connection-request报文

由PPTP客户端发出，请求建立控制连接；

Length ：该 PPTP 信息的八位总长，包括整个 PPTP 头。

Message Type ： 信息类型。可能值有：1、控制信息；2、管理信息。

Magic Cookie ： Magic Cookie 以连续的 0x1A2B3C4D 进行发送，其基本目的是确保接收端与 TCP数据流间的正确同步运行。

Control Message Type ：值为1；

Reserved 0 & 1 ： 保留字段，必须设置为0。

Protocol Version ： PPTP版本号。

Framing Capabilities ： 指出帧类型，该信息发送方可以提供：1、异步帧支持（Asynchronous Framing Supported）；2、同步帧支持（Synchronous Framing Supported）。

Bearer Capabilities ： 指出承载性能，该信息发送方可以提供：1、模拟访问支持（Analog Access Supported）；2、数字访问支持（Digital access supported）。

Maximum Channels ： 该 PPTP服务器 可以支持的个人 PPP 会话总数。

Firmware Revision ： 若由 PPTP服务器 出发，则包括发出 PPTP服务器时的固件修订本编号；若由 PPTP客户端 出发，则包括 PPTP客户端 PPTP 驱动版本。

Host Name ： 包括发行的 PPTP服务器 或 PPTP客户端的 DNS 名称。

Vendor Name ： 包括特定供应商字串，指当请求是由 PPTP客户端 提出时，使用的 PPTP服务器 类型或 PPTP客户端软件类型。

2.Start-Control-Connection-Reply报文

   PPTP服务器对Star-Control-Connection-Request回应；

大部分字段的含义与Start-control-connection-request一致。不同的字段含义如下：

Control Message Type ：值为2；

Result Code：表示建立channal是否成功的结果码，值为1表示成功，值为2表示通用错误，暗示着有问题。值为3表示channal已经存在，值为4表示请求者未授权，值为5表示请求的PPTP协议版本不支持。

Error Code：表示错误码，一般值为0，除非Result Code值为2，不同的错误码表示不同的含义。（即：只有当Result Code值为2时，Error Code才有其它值）

3.Outgoing-call-request报文

  由PPTP客户机发出，请求创建PPTP隧道，该消息包含GRE报头中call id，                         

  该id可唯一地标识一条隧道 ；

Length、PPTP Message、Magic cookie与Start-control-connection-request一致。不同的字段含义如下：

Control Message Type ：值为7。

Call ID：由PPTP客户端指定的唯一的会话ID。

Call Serial Number：是由PPTP客户端指定的唯一标识符，用于在记录会话信息中标识特定会话，与Call ID不一样的是，Call Serial Number PPTP客户端与PPTP服务器来说，唯一绑定到一个给定的会话，且是相同的。

Minimum BPS：对于此次会话可接受的最低传输速度，单位为位/秒；

Maximum BPS：对于此次会话可接受的最大传输速度，单位为位/秒；

Bearer Type： 指出承载访问支持，该信息发送方可以提供：1、模拟访问支持（Analog Access Supported）；2、数字访问支持（Digital access supported）。3、可支持的任何类型。

Framing Type： 指出帧类型，该信息发送方可以提供：1、异步帧支持（Asynchronous Framing Supported）；2、同步帧支持（Synchronous Framing Supported）。 3、异步或同步帧支持。

Packet Receive window size：PPTP客户端为此次会话提供最大接收缓冲大小；

Packet  Processing Delay：表示PPTP客户端对数据包处理的延时度量，对于PPTP客户端来说，一般设置比较小越好。

Phone number length：拔号号码长度；

Phone number：建立会话向外拔号的号码，一般对于ISDN或模拟方式拔号来说，此字段域为一个ASCII串。一般长度少于64个字节。

Sub address：额外信息域，一般长度少于64个字节。

4.Outgoing-Call-Reply报文

PPTP服务器对Outgoing-Call- Request t回应；

Length、PPTP Message、Magic cookie与Start-control-connection-request一致。不同的字段含义如下：

Control Message Type ：值为8。

Call ID：由PPTP服务器指定的唯一的会话ID。主要用于在PPTP服务器与PPTP客户端建立的会话上，复用与解封装隧道包使用的。

Peer’s Call ID：设置的值是从接收到的Outgoing-call-request中Call ID值，是由PPTP客户端指定的，用于GRE中对于隧道数据解封与复用。

Result Code：表示响应Outgoing-call-request握手是否成功，值为1表示成功，值为2表示通用错误，暗示着有问题。值为3表示无载波，值为4表示服务器忙，无法及时响应，值为5表示无拔号音，值为6表示呼号超时，值为7表示未授权。

Error Code：表示错误码，一般值为0，除非Result Code值为2，不同的错误码表示不同的含义。

Cause Code：表示进一步错误信息描述；

Connect Speed：连接使用的实际速率；

Physical Channel ID：由PPTP服务器指定的物理信道ID。

5.Set-Link-Info报文

  由PPTP客户机或服务器任一方发出，设置PPP协商选项；

Control Message Type ：值为15。

Peer’s Call ID：设置的值是从接收到的Outgoing-call-request中Call ID值，是由PPTP客户端指定的，用于GRE中对于隧道数据解封与复用。

Reserved0/Reserve1：保留位，必须为0;

Send ACCM：发送的ACCM值，默认值为0XFFFFFFFF；

Receive ACCM：接收的ACCM值，默认值为0XFFFFFFFF；

6.Echo request报文

PPTP隧道维护报文，每60S发送一次；

Control Message Type ：值为5。

Peer’s Call ID：设置的值是从接收到的Outgoing-call-request中Call ID值，是由PPTP客户端指定的，用于GRE中对于隧道数据解封与复用。

Reserved0：保留位，必须为0;

Identifier：发送者用来标识Echo request与Echo reply对应标识。

7.Echo-reply报文

PPTP隧道维护报文，对Echo request的回应报文；

Control Message Type ：值为6。

Peer’s Call ID：设置的值是从接收到的Outgoing-call-request中Call ID值，是由PPTP客户端指定的，用于GRE中对于隧道数据解封与复用。

Reserved0/1：保留位，必须为0;

Identifier：标识值，为接收者从Echo request里标识字段复制填入。

Result Code：结果码，为1表示Echo-reply是有效的，为2表示出现一般性错误。

8.Call-Clear-Request报文

   由PPTP客户机发出，请求终止隧道；

   Control Message Type ：值为12。

Call ID：由PPTP客户端指定的会话ID。

9.Call-Disconnect-Notify报文

   PPTP服务器对Call-Clear-Request回应或者其他原因指示必须终止隧道；

Control Message Type ：值为13。

Call ID：由PPTP客户端指定的会话ID。

Result Code：结果码，为1表示媒介断开，为2表示出现一般性错误，为3表示为管理员关闭连接，为4表示收到Call-Clear-Request；

Error code：同上面所描述的。

Cause Code：此域表示额外说明断开原因。

10.Stop-Control-Connection-Request报文

   由PPTP客户机或者服务器任一方发出，通知对端控制连接将被终止；

Control Message Type ：值为3。

Resverve：保留位，必须为0;

Reason：表示会话连接关闭的原因，为1表示响应会话清除请求，为2表示不支持对端PPTP版本，为3表示本地系统关闭。

11.Stop-Control-Connection-Reply报文

  回应Stop-Control-Connection-Request消息；

  Control Message Type ：值为4。

Resverve：保留位，必须为0;

Result Code：表示关闭连接结果码，为1表示正常关闭成功，为2表示发生一般性错误。

Error Code：表示当结果为2时，对应具体的一般性错误，Result Code为1时，必须为0。

二、PPP协商过程

当PPTP控制通道建立完成后，发起PPP协商

1.LCP协商

 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、Client和Server接受彼此的配置之后，PPTP的控制层会彼此互发Set Link Info；

2.PPP协议的身份验证

      9.  LCP协商完毕后，PPP协议的Server端会对Client端进行身份验证；

      10. 可以选CHAP、MS-CHAP、MS-CHAP-v2...进行验证，现在以CHAP为例，需要注意到以下几点：

        （1） Server发送Challenge，其中包括一个challenge string和server name；

        （2） Client回Response，其中包括用户名，和密码和challeng string。其中用户名以明文发送（这个需要特别注意），密码的challenge string经过单向hash算法后以密文形式发送；

        （3） Server发送success，表示身份验证成功。

3.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；

4.CCP报文

     CCP中包括了MPPC和MPPE的参数协商，也就是Microsoft

Point-to-Point Compression 和 Microsoft Point-to-Point Encryption的参数协商，用来确定数据包中的压缩和加密算法和参数。

三、数据传输

      PPTP隧道建立完成后，使用GRE封装PPP报文在IP网络环境中传输。