TCP/IP卷一:21---链路层之（虚拟链路、单向链路(UDL)、隧道协议(GRE、PPTP、L2TP)）

一、隧道的概念

• 在某些情况下,两台计算机通过Intemet或其他网络建立一条虚拟链路是有用的。虚拟专用网络(vpN)提供这种服务。实现这类服务的最常用方法称为隧道

隧道技术

一般来说,隧道是 在高层(或同等层)分组中携带低层数据

• 例如，在一个IPv4或IPv6分组中携带IPv4数据, 在一个UDP、 IPv4或IPv6分组中携带以太网数据
• 隧道转变了在头部中协议严格分层的思路,并允许形成覆盖网络(即这些“链路”实际是其他协议实现的虚拟链路,而不是物理连 接的网络)。这是一个非常强大和有用的技术

二、隧道协议

为某个协议层的分组或另一层的分组建立隧道有多种方法。用于建立隧道的3个常见协 议包括：

• 用路由封装(GRE)
• Microsoft专用的点对点隧道协议(PPTP)
• 第2层隧道协议(L2TP)
• 其他协议包括早期非标准的IP-in-IP隧道协议

协议关系：

• GRE和IT2P后来发展成为标准,并分别代替了IP-in-IP和PPTP (但这两种协议仍在使用)。我们将重点放在GRE和PPTP,但更关注PPTP,因为它是个人用户的常用协 议,即使它并不是一个IETF标准。L2TP本身不提供安全保障,它常用于IP层安全
• 虽然GRE是PPTP的基础，并被PPTP使用,但这两个协议的目的不同。GRE隧道常 用于网络基础设施内的流量传输,例如ISP之间或企业内部网与分支机构之间,虽然GRE 隧道可与IPsec结合,但这个流量通常没必要加密。相反, PPTP常用于用户和ISP或企业内部网之间,并需要加密(例如使用MPPE)。PPTP本质上是GRE和PPP的结合,因此GRE 可基于PPP提供虚拟的点到点链路。GRE使用IPv4或IPv6携带流量,因此它更像是一种第3层隧道技术。ppTP常用于携带第2层帧(例如以太网),因此需要模拟一条直接的局域网 (链路层)连接。例如,它可用于对企业网络的远程访问

GRE头部帧

• 从图3-26中的头部可以看出,基本GRE规范[RFC2784]是相当简单的,它只提供了对 其他分组的最简化的封装。第一个位字段(C)指出是否存在校验和。如果是,校验和字段 中包含相同类型的校验和,它在很多Intemet相关协议中可看到(见5.2.2节)。如果校验和 字段存在,保留1字段也存在,并被设置为00 [RFC2890]扩展了基本格式,包括可选的密 钥和序列号字段,如果有这两个字段的话,图3-26中的k和S位字段分别被设置为10 密 钥字段在多个分组中被分配了一个同样的值,表示它们是属于同一流中的分组。如果分组顺 序被打乱(例如通过不同链路),可利用序列号字段对分组重新排序

PPTP头部帧

PPTP采用的是对标准GRE头部的改进方案(见图3-27)

• 我们可看到图3-27与标准GRE头部的一些差异,包括额外的R、 S和A位字段,以及 标志字段和回溯(Recur)字段。它们中的多数设置为0,并且没有使用(它们的分配是基于 一个旧的、非标准的GRE版本)。K、 S和A位字段分别表示密钥、序列号和确认号字段是 否存在。如果存在,序列号字段保存对方可看到的最大分组数

三、例子

• 我们现在建立一个PPTP会话,稍后对PPTP的其他功能进行简单讨论。下面的例子类 似于前面给出的PPP链路建立的例子,区别在于现在不常使用拨号连接, PPTP为PPP提供 了一条“原始”链路。第二个客户端使用Windows Vista系统,服务器使用Linux系统。当 调试选项启用时,这个输出保存在/var/10g/messages文件中：

• 这个输出类似于前面看过的PPP的例子,区别在于一个pppd过程和一个pptpd过程。 这些进程协同工作以建立到服务器的PPTP会话。整个建立过程开始于用pptpd接收1个类 型为1的控制消息,表示客户机希望建立一个控制连接。ppTP使用分离的控制流和数据流, 因此首先需要建立一个控制流。在响应这个请求之后,服务器接收到一个类型为7的控制消 息(表示对方发送的呼叫请求)。最大速度(b/s)设置为一个很大的值100000000,实际上 意味着它是无限制的。窗口设置为64,这是在传输协议例如TCP (见第15章)中经常看到 的一个概念。这里,窗日用于流量控制。也就是说, PPTP使用自已的序列号和确认号来确 定多少帧成功到达目的地。如果成功交付的帧太少,发送者需要减小发送速率。为了确定帧 确认的等待时间, PPTP使用一种自适应的超时机制,根据链路的往返时间进行估算。当我 们学习TCP时将看到这种计算过程
• 在设置窗口后不久, PPPd应用开始运行和处理PPP数据,就像我们之前在拨号例子中 看到的那样。两者之间唯一的区别在于: PPtPd在分组到达和离开时转发给pppd过程,以及 PPtPd处理的少量特殊PPTP消息(例如set link infO和echo request)。这个例子说明了PPTP 协议如何实际运行,就像一个针对PPP分组的GRE隧道。由于现有PPP实现(这里是pppd) 可处理封装的PPP分组,因此它是很方便的。注意,虽然GRE本身通常封装在IPv4分组 中,但类似功能也可使用IPv6隧道分组[RFC2473]

四、单向链路（UDL）

• 当链路仅在一个方向工作时出现一个有趣的问题。这种在一个方向工作的链路称为单向链路(UDL),由于它们需要交换信息(例如PPP配置消息),因此前面介绍的很多协议在这 种情况下不能正常运行
• 为了解决这种问题提出了一种标准,可在辅助Intemet接日上创建 隧道,它可与UDL操作相结合[RFC3077]。典型情况是由卫星提供下行流量(流向用户)而 形成一条Intemet连接,或者是调制解调器提供上行流量而形成一条拨号链路。这在卫星连接的用户主要是下载而不是上传的情况下是有用的,并且通常用于早期的卫星Intemet连接。 它使用GRE将链路层的上行流量封装在IP分组中
• 为了在接收方自动建立和维护隧道, [RFC3077]规定了一种动态隧道配置协议(DTCP)。DTCP涉及在下行链路中发送组播Hello消息,因此任何有兴趣的接收方都可知道已有UDL 及其MAC和IP地址。另外, Hello消息表示网络中一个隧道端点的接口,它可通过用户端的辅助接口到达。在用户选择隧道端点之后, DTCP在GRE隧道中将同一MAC作为UDL 封装返回流量。服务提供商接收由GRE封装的这些第2层帧(通常是以太网),将它们从隧 道中提取并适当转发。因此,上游(提供商) uDL需要手工配置隧道,下游(很多用户)自 动配置隧道。注意,这种UDL处理方法实际上是为上层协议不对称地“隐藏”链路。因此, 这条链路∵两个”方向上的性能(延迟、带宽)可能非常不对称,并可能对高层协议产生不 利影响[RFC3449]
• 这个例子说明,隧道的一个重要问题是配置的工作量,这个工作从前一直由手工完咸。 在通常情况下,隧道配置涉及选择一个隧道端点,以及用对方的IP地址配置位于隧道端点 的设备,也许还需要选择协议和提供认证信息。一些相关技术已经出现,以协助自动配置或 使用隧道。一种从IPv4向IPv6的过渡方法称为6to4 [RFC3056]。在6to4中, IPv6分组在一 个IPv4网络中通过隧道传输, [RFC3056]中规定它采用的封装方式。当相应主机经过了网络 地址转换(见第7章),采用这种方法就会出现一个问题。这在当前是常见的,特别是对于家 庭用户。自动配置隧道的IPv6过渡处理方法规定在Teredo技术方案中[RFC4380]。Teredo 在UDP/IPv4分组上形成IPv6分组的隧道。理解这种方法需要一些IPv4、 IPv6和UDP的背 景知识,我们将在第10章详细讨论这种隧道自动配置选项