Skip to main content

1. 简介 (Introduction)

PPTP 允许使用客户端-服务器架构将现有的网络接入服务器 (Network Access Server, NAS) 功能分离。传统上,NAS 实现以下功能:

  1. 物理原生接口到 PSTN 或 ISDN 以及外部调制解调器或终端适配器的控制

    NAS 可以直接接口到电信公司的模拟或数字电路,或通过外部调制解调器或终端适配器连接。电路交换连接的控制通过调制解调器控制或 DSS1 ISDN 呼叫控制协议完成。

    NAS 与调制解调器或终端适配器配合,可以执行速率适配、模拟到数字转换、同步到异步转换或对数据流进行许多其他改变。

  2. 点对点协议 (Point-to-Point Protocol, PPP) 链路控制协议 (Link Control Protocol, LCP) 会话的逻辑终止

  3. 参与 PPP 认证协议 [3,9,10]

  4. PPP 多链路协议 (Multilink Protocol) 的信道聚合和捆绑管理

  5. 各种 PPP 网络控制协议 (Network Control Protocol, NCP) 的逻辑终止

  6. NAS 接口之间的多协议路由和桥接

PPTP 将这些功能在 PAC 和 PNS 之间分配。PAC 负责功能 1、2 以及可能的功能 3。PNS 可能负责功能 3,并负责功能 4、5 和 6。PPTP 解决了在 PAC 和 PNS 之间承载 PPP 协议数据单元 (Protocol Data Unit, PDU) 以及呼叫控制和管理所使用的协议。

NAS 功能的解耦提供了以下好处:

灵活的 IP 地址管理。拨入用户可以在拨入不同的 PAC 时保持单一的 IP 地址,只要它们由同一个 PNS 提供服务。如果企业网络使用未注册的地址,则与企业关联的 PNS 分配对专用网络有意义的地址。

为 IP 网络后面的拨号网络提供非 IP 协议支持。例如,这允许 AppleTalk 和 IPX 通过仅支持 IP 的提供商进行隧道传输。PAC 不需要能够处理这些协议。

解决"多链路搜索组分割"问题。多链路 PPP (Multilink PPP) 通常用于聚合 ISDN B 信道,要求组成多链路捆绑的所有信道都分组在单个 NAS 上。由于多链路 PPP 捆绑可以由单个 PNS 处理,因此组成捆绑的信道可以分布在多个 PAC 上。

1.1. 协议目标和假设 (Protocol Goals and Assumptions)

PPTP 协议仅由 PAC 和 PNS 实现。其他系统不需要知道 PPTP。拨号网络可以连接到 PAC 而不需要知道 PPTP。标准 PPP 客户端软件应该继续在隧道化的 PPP 链路上运行。

PPTP 也可以用于通过 IP 网络隧道化 PPP 会话。在这种配置中,PPTP 隧道和 PPP 会话在相同的两台机器之间运行,呼叫方充当 PNS。

预计 PAC 和 PNS 之间将存在多对多关系。一个 PAC 可以为多个 PNS 提供服务。例如,互联网服务提供商可以选择为多个专用网络客户支持 PPTP 并为它们创建 VPN。每个专用网络可以运行一个或多个 PNS。单个 PNS 可以与多个 PAC 关联,以集中来自大量地理上分散站点的流量。

PPTP 使用扩展版本的 GRE 来承载用户 PPP 数据包。这些增强功能允许在用于在 PAC 和 PNS 之间承载用户数据的隧道上提供低级拥塞和流量控制。这种机制允许有效使用可用于隧道的带宽,并避免不必要的重传和缓冲区溢出。PPTP 不规定用于这种低级控制的特定算法,但它确实定义了必须传达的参数,以便允许这些算法工作。建议的算法包含在第 4 节中。


1.2. 术语 (Terminology)

模拟信道 (Analog Channel)
用于在每个方向承载 3.1 kHz 音频的电路交换通信路径。

数字信道 (Digital Channel)
用于在每个方向承载数字信息的电路交换通信路径。

呼叫 (Call)
PSTN 或 ISDN 上两个终端端点之间的连接或连接尝试,例如两个调制解调器之间的电话呼叫。

控制连接 (Control Connection)
为每个 PAC-PNS 对创建的连接,通过 TCP 运行。控制连接管理隧道和分配给隧道的会话的各个方面。

拨号用户 (Dial User)
连接到按需 PSTN 或 ISDN 的终端系统或路由器,可以是呼叫的发起者或接收者。

网络接入服务器 (Network Access Server, NAS)
为用户提供临时按需网络接入的设备。该接入使用 PSTN 或 ISDN 线路进行点对点连接。

PPTP 接入集中器 (PPTP Access Concentrator, PAC)
连接到一条或多条 PSTN 或 ISDN 线路的设备,能够进行 PPP 操作并处理 PPTP 协议。PAC 只需实现 TCP/IP 即可将流量传递给一个或多个 PNS。它也可以隧道传输非 IP 协议。

PPTP 网络服务器 (PPTP Network Server, PNS)
PNS 预期在通用计算/服务器平台上运行。PNS 处理 PPTP 协议的服务器端。由于 PPTP 完全依赖于 TCP/IP 并且独立于接口硬件,因此 PNS 可以使用任何 IP 接口硬件组合,包括 LAN 和 WAN 设备。

会话 (Session)
PPTP 是面向连接的。PNS 和 PAC 为连接到 PAC 的每个用户维护状态。当在拨号用户和 PNS 之间尝试端到端 PPP 连接时创建会话。与会话相关的数据报通过 PAC 和 PNS 之间的隧道发送。

隧道 (Tunnel)
隧道由 PNS-PAC 对定义。隧道协议由修改版的 GRE 定义。隧道在 PAC 和 PNS 之间承载 PPP 数据报。多个会话在单个隧道上复用。通过 TCP 运行的控制连接控制会话和隧道本身的建立、释放和维护。

1.3. 协议概述 (Protocol Overview)

PPTP 有两个并行组件:1) 在每个 PAC-PNS 对之间通过 TCP 运行的控制连接;2) 在同一 PAC-PNS 对之间运行的 IP 隧道,用于在该对之间传输用户会话的 GRE 封装 PPP 数据包。

1.3.1. 控制连接概述 (Control Connection Overview)

在 PAC 和 PNS 之间进行 PPP 隧道传输之前,必须在它们之间建立控制连接。控制连接是一个标准的 TCP 会话,通过它传递 PPTP 呼叫控制和管理信息。控制会话在逻辑上与通过 PPTP 隧道进行隧道传输的会话相关联,但是分离的。对于每个 PAC-PNS 对,既存在隧道也存在控制连接。控制连接负责通过隧道承载的会话的建立、管理和释放。它是 PNS 被通知相关 PAC 上的传入呼叫的手段,也是 PAC 被指示发起出站拨号呼叫的手段。

控制连接可以由 PNS 或 PAC 建立。在建立所需的 TCP 连接后,PNS 和 PAC 使用 Start-Control-Connection-Request 和 -Reply 消息建立控制连接。这些消息还用于交换有关 PAC 和 PNS 的基本操作能力的信息。一旦建立了控制连接,PAC 或 PNS 可以通过请求出站呼叫或响应入站请求来发起会话。控制连接可以使用 Set-Link-Info 消息传达单个用户会话的操作特性的变化。单个会话可以由 PAC 或 PNS 释放,也通过控制连接消息进行。

控制连接本身通过保持活动回显消息来维护。这确保可以及时检测到 PNS 和 PAC 之间的连接故障。其他故障可以通过控制连接上的 Wan-Error-Notify 消息报告。

控制连接将来还将携带与管理相关的消息,例如允许 PNS 请求给定 PAC 的状态的消息;这些消息类型尚未定义。

1.3.2. 隧道协议概述 (Tunnel Protocol Overview)

PPTP 要求为每个通信的 PNS-PAC 对建立隧道。此隧道用于承载涉及给定 PNS-PAC 对的所有用户会话 PPP 数据包。GRE 头部中存在的密钥指示特定 PPP 数据包属于哪个会话。

通过这种方式,PPP 数据包在给定 PNS-PAC 对之间的单个隧道上进行复用和解复用。在密钥字段中使用的值由在控制连接上进行的呼叫建立过程确定。

GRE 头部还包含确认和序列信息,用于在隧道上执行某种程度的拥塞控制和错误检测。控制连接再次用于确定速率和缓冲参数,这些参数用于调节通过隧道的特定会话的 PPP 数据包流。PPTP 不规定用于拥塞控制和流量控制的特定算法。本文档的第 4.4 节包含了用于确定自适应超时以从隧道上丢弃的数据或确认中恢复的建议算法。

1.4. 消息格式和协议可扩展性 (Message Format and Protocol Extensibility)

PPTP 定义了一组在 PNS 和给定 PAC 之间的控制连接上作为 TCP 数据发送的消息。控制连接的 TCP 会话通过向端口 1723 发起 TCP 连接来建立。源端口分配给任何未使用的端口号。

每个 PPTP 控制连接消息都以 8 字节固定头部开始。此固定头部包含以下内容:消息的总长度、PPTP 消息类型指示符和"魔术 Cookie"。

PPTP 消息类型字段指示两种控制连接消息类型:

  • 1 - 控制消息 (Control Message)
  • 2 - 管理消息 (Management Message)

管理消息目前未定义。

魔术 Cookie 始终作为常量 0x1A2B3C4D 发送。其基本目的是允许接收方确保它与 TCP 数据流正确同步。在发送方发出格式不正确的消息的情况下,不应将其用作重新同步 TCP 数据流的手段。同步丢失必须导致立即关闭控制连接的 TCP 会话。

为清楚起见,下一节中的所有控制连接消息模板都包含完整的 PPTP 控制连接消息头部。以 0x 开头的数字是十六进制值。

当前定义的控制消息(按功能分组)如下:

控制连接管理 (Control Connection Management)

  • Start-Control-Connection-Request (1)
  • Start-Control-Connection-Reply (2)
  • Stop-Control-Connection-Request (3)
  • Stop-Control-Connection-Reply (4)
  • Echo-Request (5)
  • Echo-Reply (6)

呼叫管理 (Call Management)

  • Outgoing-Call-Request (7)
  • Outgoing-Call-Reply (8)
  • Incoming-Call-Request (9)
  • Incoming-Call-Reply (10)
  • Incoming-Call-Connected (11)
  • Call-Clear-Request (12)
  • Call-Disconnect-Notify (13)

错误报告 (Error Reporting)

  • WAN-Error-Notify (14)

PPP 会话控制 (PPP Session Control)

  • Set-Link-Info (15)

Start-Control-Connection-Request 和 -Reply 消息确定将使用哪个版本的控制连接协议。这些消息中携带的版本号字段由高字节中的版本号和低字节中的修订号组成。版本处理在第 2 节中描述。版本号字段的当前值为 0x0100,表示版本 1,修订版 0。

用于封装 PPP 用户数据包的类 GRE 头部的使用在第 4.1 节中规定。

在 GRE 中封装的用户数据包的 MTU 为 1532 字节,不包括 IP 和 GRE 头部。