PPTP协议介绍及其报文的分析

PPTP简介

PPTP(Point to Point Tunneling Protocol),即点对点隧道协议,是在PPP协议的基础上开发的一种新的增强型安全协议,支持多协议虚拟专用网(VPN),使远程用户能拨号连入本地ISP,通过 Internet 或其他网络安全链接到公司网络。
PPTP包括两条连接:PPTP控制连接和PPTP数据连接。控制连接承载在TCP协议上,是一个逻辑连接,负责创建、维持和终止的PPTP数据连接隧道;数据连接采用GRE包头封装,传输用户业务数据,是典型的多通道应用协议。
PPTP报文是基于TCP报文的,其使用端口号1723,当某个报文的源端口或目的端口使用1723端口号时,可以认为其属于PPTP类型的报文。
对于PPTP协议,进行交互的对象有两个,分别是PNS(PPTP网络服务器)和PAC(PPTP PPTP Access Concentrator访问集中器),按照普通理解可以将其表明为:客户端和服务器端。

PPTP处理的报文

在PPTP协议中,可以将传输的报文分为两大类:控制连接报文和数据连接报文。其中控制链路报文包括:
Start-Control-Connection-Request报文(PNS->PAC|PAC->PNS)
Start-Control-Connection-Reply报文(作为Request的回应)
Stop-Control-Connection-Request报文(PNS->PAC|PAC->PNS)
Stop-Control-Connection-Reply报文(作为Request的回应)
Echo-Request报文(PNS->PAC|PAC->PNS)
Echo-Reply报文(PAC->PNS|PNS->PAC)
Outgoing-Call-Request报文(PNS->PAC,PNS calling id)
Outgoing-Call-Reply报文(PAC->PNS,PAC calling id,PNS calling id)
Incoming-Call-Request报文(PAC->PNS,PAC calling id)
Incoming-Call-Reply报文(PNS->PAC,PNS calling id,PAC calling id)
Incoming-Call-Connected报文(PAC->PNS, PNS calling id)
Call-Clear-Request报文(PNS->PAC,PNS calling id)
Call-Clear-Notify报文 (PAC->PNS,PAC calling id)
WAN-Error-Notify报文(PAC发往PNS,表明支持PPP接口发生的问题,PNS calling id)
Set-Link-Info报文(PNS发往PAC,用于修改协商PPP选项的变化,PAC calling id)
数据链路报文可分为:
PNS->PAC方向的GRE报文(PAC calling id)
PAC->PNS方向的GRE报文(PNS calling id)

PPTP报文详情及流程

一个控制连接下面可以包含多个数据连接。每一个数据连接可以称作为一个call,每个call之间的区别是通过call Id来分辨的。而每一个call之间的协商可以有两种工作模式,分别是outgoing call模式(主动模式)和incoming call模式(被动模式)。不是通过报文配的,是通过软件来配的。(个人猜想)

当PPTP建立控制连接时,PNS与PAC之间会经历三次握手,以及Start-Control-Connection-Request报文和Start-Control-Connection-Reply报文的交互(PNS->PAC|PAC->PNS)。

在PNS和PAC建立好控制连接后,PNS和PAC之间将会进行call的协商,他们之间有两种工作模式。当是主动模式时,PNS将向PAC发送outgoing call request报文,该报文中包含了PNS的calling id。

当PAC收到PNS发送的outgoing call request报文后,其在判断报文所提供的条件满足要求后,其会返回一个outgoing call reply报文。该报文中不仅包含了PNS的calling id,还包含了PAC的calling id。

在控制链路的GRE报文交互中,所使用的正是此时协商好的calling id。

当使用被动模式进行工作时,PAC首先会发送一个incoming call request报文,在该阶段,会话表中将会记录PAC的calling id,之后PNS将会发送一个incoming call reply报文,在该报文下会带有其本身的PNS的calling id和PAC的calling id,最后PAC将会发送一个incoming call connected报文,其带有PNS的calling id。

需要说明的是PNS和PAC之间可以协商多个call。

当PNS与PAC在60秒之内没有报文的交互时,他们会发送一个echo request报文,另外一方当收到该报文时会发送echo reply报文,两者的状态将继续保持成连接状态。但当在60s后没有收到echo reply报文时,一方将直接断开该连接。

当某个call要断开连接时,PNS将会向PAC 发送call clear request报文,PAC收到该报文后将会发送call clear notify报文,表明该call将会被中断。其中 call clear request报文中携带的时其本身的calling id,即PNS calling id,call clear notify报文携带的也是本身的calling id,即PAC calling id。目的:有可能PNS或PAC根本没有拿到对方的calling id。

对于WAN-Error-Notify报文,其是由PAC发往PNS的,其表明了支持PPP接口发生的问题,其携带PNS的calling id。

对于Set-Link-Info报文,其是由PNS发往PAC的,其发生在PNS的PPP协商选项发生变化时,需动态通知PAC,并展开相应的动作。

当PNS或PAC需要断开控制链接时,一方会发送Stop -Control-Connection-Request报文,而另一方作为回应会发送Stop-Control-Connection-Reply报文,当发送Request报文时,除了控制链路会被端口,其连在控制链路下的数据链路(call)也会被默认断开。

PNS与PAC之间控制链路的老化是以TCP四次挥手来结束的。

incoming模式(被动模式)与outgoing模式(主动模式)的区别

被动模式和主动模式是PPTP所具有的两种工作模式。被动模式的PPTP会话通过一个一般是位于ISP处的前端处理器发起,在客户端不需要安装任何与 PPTP有关的软件。ISP在拨号连接到ISP的过程中,为用户提供所有的相应服务和帮助。被动方式的好处是降低了对客户的要求,缺点是限制了客户对因特网其他部分的访问。

PPTP的主动模式是建立一个与网络服务器直接连接的PPTP隧道,这种方式不需要ISP去提供透明的传输通道,也不再需要位于ISP 处的前端处理器。这种方式的优点是客户拥有对PPTP的绝对控制,缺点是对用户的要求较高,并需要在客户端安装支持PPTP 的相应软件。

PPTP数据链路报文格式

PPTP数据链路的报文通过一个增强型的GRE报文来封装。GRE报文使用协议号48。位于IP报文头之后。
普通的GRE报文格式
普通GRE报文格式如上图所示。
报文中各字段的含义分别为:
字段 长度 描述
C 1 bit 校验和验证位。如果该位置1,表示GRE头插入了校验和(Checksum)字段;该位为0表示GRE头不包含校验和字段。
K 1 bit 关键字位。如果该位置1,表示GRE头插入了关键字(Key)字段;该位为0表示GRE头不包含关键字字段。
Recursion 3 bits 用来表示GRE报文被封装的层数。完成一次GRE封装后将该字段加1。如果封装层数大于3,则丢弃该报文。该字段的作用是防止报文被无限次的封装。
Flags 5 bits 预留字段。其中第一位是Acknowledgement=1,则是YES,在Key字段中要包含该字段。
Version 3 bits 版本字段,若为Enhanced GRE,则视之为.001。
Protocol Type 16 bits 乘客协议的协议类型。(PPP)
Checksum 16 bits 对GRE头及其负载的校验和字段。
Key 31 bits 关键字字段,隧道接收端用于对收到的报文进行验证。

PPTP下数据链路使用的是增强型GRE报文,其格式为:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
|C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| Key (HW) Payload Length | Key (LW) Call ID |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| Sequence Number (Optional) |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+
| Acknowledgment Number (Optional) |
±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±+

在Ver字段下为1,同时Payload Length为不包含GRE头部的报文长度,Call ID保存的是对端的calling id。

其他

PPTP的其他详细信息可查看RFC2637。

http://www.faqs.org/rfcs/rfc2637.html。

  • 2
    点赞
  • 12
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值