引言为什么我们需要“套娃”式的网络传输你肯定遇到过这样的场景在公司外面出差想用咖啡馆的公共 Wi-Fi 访问公司内网的 ERP 系统或者内部文件服务器。但咖啡馆的 Wi-Fi 是不安全的如果直接传输数据你的账号密码甚至公司商业机密都可能被抓包窃取。为了解决这个问题工程师们发明了VPN虚拟专用网络。而支撑 VPN 这项神奇技术的底层骨架就是我们今天要聊的“隧道Tunneling”。让我们先来看看书上是怎么定义它的【穿插原文 1】“在某些情况下两台计算机通过 Internet 或其他网络建立一条虚拟链路是有用的。虚拟专用网络VPN提供这种服务。实现这类服务的最常用方法称为隧道。一般来说隧道是在高层或同等层分组中携带低层数据。例如在一个 IPv4 或 IPv6 分组中携带 IPv4 数据或在一个 UDP、IPv4 或 IPv6 分组中携带以太网数据。”【通俗解析】这段话的核心关键就在“在高层分组中携带低层数据”。简单来说就是**“套娃”。你在公司内网发出一个正常的以太网数据包内网 IP到了网关这里网关不会直接把它扔到公网去。网关会把它当成一封信塞进一个新的、外面套着公网 IP 的“大信封”里**。然后这个“大信封”在公网上飞到目的地目的地另一端的网关再把里面的“小信”拆出来还原成内网数据包。这种**“双层包装”**的技术就叫隧道技术。公共互联网只是它的一层“通道外壳”真正的数据在隧道里面“安全行驶”。【图片占位符VPN 隧道概念图】此处可插入一张示意图左侧内部网络内网 IP- VPN 隧道外层公网 IP 包裹 - 公共互联网云朵 - VPN 隧道拆包 - 右侧企业内部网络。第一部分GRE——隧道最基础的“砖块”实现隧道有很多种协议但在互联网早期最基础、最通用的就是GRE通用路由封装。它是隧道技术的“地基”。1.1 基础版的 GRE 报头RFC 2784书里先给我们展示了最经典的 GRE 报头结构。【穿插原文 2】“图 3-26 中基本的 GRE 头部只有 4 字节包括一个 16 位的校验和选项很多 Internet 协议中的典型选项。后来这个头部被扩展为包括一个标识符密钥字段、该标识符是同一流中的多个分组所必须的还包括一个序列号用于顺序混乱的分组重新排序。”结合书中的图 3-26我们来看看这个 4 字节的基础报头长什么样【图片占位符基础 GRE 报头结构图RFC 2784】此处需插入图 3-26 的第一部分展示C标志位1位、保留012位、版本3位、协议类型16位、校验和可选16位、保留1可选16位。C 位Flag表示这个包里是否包含了“校验和”字段。协议类型Protocol Type极其重要它告诉外层的解包器“我这个大信封里装的是什么协议的包”比如装的是 PPP 协议的包或者以太网协议。校验和Checksum用来检查整个 GRE 头和数据是否在路上损坏了。1.2 进化版的 GRE 报头RFC 2890原始的 GRE 有个致命弱点它不负责区分“这是哪一个 VPN 连接的数据”。如果公司有 100 个员工同时连到 VPN 服务器谁的数据是谁的传统的 GRE 分不清。所以后来出现了扩展版的 GRE 报头RFC 2890。【穿插原文 3】“RFC 2890 扩展了基本格式包括可选的密钥和序列号字段如 3-26 中的 K 和 S 位字段分别被设置为 1。如果校验和字段在多个分组中被分配了同样的值表示它们是属于同一流中的分组。如果分组顺序被打乱例如通过不同链路可利用序列号字段对分组重新排序。”【图片占位符扩展 GRE 报头结构图RFC 2890】此处需插入图 3-26 的第二部分增加 K位、S位以及后续的 密钥可选16位或32位、序列号可选16位或32位。看到书里的公式了吗密钥Key相当于给同一个 VPN 隧道里的所有数据包发了同一个“通行证”。只有持有同样密钥的数据包才是一家人。序列号Sequence Number数据包有可能因为走得不同网络路径导致后发的先到了。有了序列号接收方就能把它们重新按 1、2、3 的顺序排好保证数据不乱。第二部分PPTP——PPP 与 GRE 的绝佳联姻PPTP点对点隧道协议是我们在上一章刚学完的 PPP 协议与 GRE 隧道结合出来的产物。它是早期 Windows 系统如 XP、Vista最常用的 VPN 协议。【穿插原文 4】“PPTP 本质上是在 GRE 和 PPP 的结合因此 GRE 可基于 PPP 提供虚拟的点到点链路。GRE 使用 IPv4 或 IPv6 携带流量因此它更像是一种第 3 层隧道技术。PPTP 常用于携带第 2 层帧例如以太网因此需要模拟一条直接的局域网链路层连接。例如它可用于对企业网络的远程访问。”通俗理解我们在拨号时PPPoE 把 PPP 包套在以太网里。在 VPN 中PPTP 把 PPP 包套在GRE 隧道里。这样不论你的家庭网络用的什么 IP你的 PPP 包都能牢牢地通过 GRE 隧道传回公司。【图片占位符PPTP 报头结构图】此处需插入图 3-27。这是一个比标准 GRE 报头更复杂的 PPTP 特定报头展示了 C, R, K, S, Recurs, A, 标志, 版本, 协议类型, 密钥, 序列号, 确认号等。第三部分一场真实的 PPTP VPN 拨号“战役”——深读 Linux 日志上理论说完了书本接下来的篇幅给我们展示了一段极度经典的Linux PPTP 服务器与 Windows Vista 客户端的连线真实日志。这段日志比我们上次学的 PPP 拨号更全面因为它包含了“建立控制隧道”和“建立数据隧道”的完整流程。【穿插原文 5】“我们建立一个 PPTP 会话稍后对 PPTP 的其他功能进行简单讨论。下面的例子类似于前面给出的 PPP 链路建立的例子区别在于现在不使用拨号连接PPTP 为 PPP 提供了一条‘原始’链路。第二个客户端使用 Windows Vista 系统服务器使用 Linux 系统。当调试选项启用时这个输出保存在 /var/log/messages 文件中”让我们把它切成三个阶段来细致观察。3.1 第一阶段握手准备建立 TCP 控制连接PPTP 和普通的 GRE 隧道最大的不同是PPTP 建立隧道之前必须先跑一个 TCP 连接。这个 TCP 连接就是“VPN 的总指挥”它位于 TCP 端口1723。pptp: MGR: Manager process started pptp: MGR: Maximum of 100 connections available pptp: CTRL: Local address 192.168.0.1 pptp: CTRL: Remote address 192.168.1.1 pptp: CTRL: Received PPTP Control Message (type: 1) pptp: CTRL: Made a START CTRL CONN REPLY packet pptp: CTRL: I wrote 156 bytes to the client. pptp: CTRL: Sent packet to client pptp: CTRL: Received PPTP Control Message (type: 7) pptp: CTRL: Set parameters to 100000000 maxbps, 64 window size pptp: CTRL: Made a OUT CALL REPLY packet【通俗解析】type: 1客户端发来第一个消息要求**“建立控制连接”**。type: 7客户端发来第二个消息要求**“发起外呼请求”**。这相当于在向 VPN 服务器申请“我想连接你的内部网络”window size 64里面出现了“64 窗口大小”。这是 TCP 协议里的流量控制后面书里特意提到 “设置非常大的值 100 000 000 bps”这是不限制带宽的玩法。3.2 第二阶段隧道正式开挖协商 GRE 隧道TCP 控制连接打通后服务器开始正式建立基于GRE 协议协议号 47的隧道。GRE: accepting packet #0 GRE: accepting packet #1 ... GRE: accepting packet #2【通俗解析】GRE: accepting packet #x表示 PPTP 的 GRE 隧道已经正式上线后续所有经过 VPN 的真实数据包都会通过 GRE 协议来传输。3.3 第三阶段安全审查与网络注册隧道内的 PPP 握手现在数据隧道通了但是**“谁有资格上车呢”** 这个时候PPP 的经典套路在 GRE 隧道内部上演了。pppd: sent [LCP ConfReq id0x1 asyncmap 0x0 auth chap MS-v2 magic 0x4e2ca200 pcomp accomp] pppd: rcvd [LCP ConfAck id0x0 mru 1400 magic 0x5e565505 pcomp accomp] ... pppd: sent [CHAP Challenge id0x1 ...] pppd: rcvd [CHAP Response id0x1 ...] pppd: sent [CHAP Success id0x1 S...MAccess granted] ... pppd: sent [CCP ConfReq id0x1 mppe H -M S L -D -C] pppd: sent [IPCP ConfReq id0x1 addr 0.0.0.0 ...] pppd: sent [IPCP ConfAck id0x1 addr 192.168.0.1]【通俗解析】你看这三行太熟悉了就是我们上一章分析过的 PPP 握手流程LCP协商链路参数。CHAP加密身份验证顺利拿到Access granted。CCP商议使用 128 位的 MPPE 加密。IPCP分配 VPN 内部 IP 地址。第四部分隧道内部与流量控制——深读日志下VPN 建立完成数据开始传输后还有哪些有趣的事情书里继续给出了后续的日志。pppd: local IP address 192.168.0.1 pppd: remote IP address 192.168.1.1 GRE: accepting packet #15 ppptd: CTRL: Sending ECHO REQ id 1 ppptd: CTRL: Made a ECHO REQ packet ppptd: CTRL: Sent packet to client【通俗解析】local IP 192.168.0.1、remote IP 192.168.1.1宣告拨号成功VPN 链路正式成立。Sending ECHO REQ这也是一个极为亮眼的细节在 VPN 运行期间VPN 服务器会定期发送ECHO REQ类似 TCP 的 Keep-Alive 心跳包。它用来探测“客户端还在线吗没掉线吧”如果客户端没在规定时间内回复ECHO REP服务器就知道 VPN 断了自动清空资源并重连。这就是 PPTP 的自愈流量控制机制。第五部分3.9.1 单向链路——不对等的“单行道”在最后书本抛出了一个新的挑战单向链路UDL。【穿插原文 6】“当链路仅在一个方向工作时出现一个有趣的问题。这种在一个方向工作的链路称为单向链路UDL由于它们需要交换信息例如 PPP 配置消息因此前面介绍的很 多协议在这种情况下不能正常运行。为了解决这种问题提出了一种标准可在辅助 Internet 接口上创建一条隧道它可与 UDL 操作相结合。”“典型情况是由卫星提供下行流量流向用户而拨号调制解调器提供上行流量而形成一条拨号链路。”【通俗解析】这在早期的卫星上网时代非常常见。你家有一个小锅卫星天线接收下行数据极快比如几十 Mbps但你要发数据上去比如点播一个电影由于没有上行天线只能用家里的 56k 老式电话线拨号发请求。这就导致“下发飞快上行极慢”。传统的 TCP 协议是无法在这种极不对称的链路上正常工作的因为 TCP 必须两方都有来有回请求-确认。因此工程界专门发明了UDL单向链路路由协议。它的解决思路类似于让“快车道”卫星下行负责运货让“慢车道”电话线上行只负责拿个对讲机喊话“货收到了”。结语隧道——穿越公共互联网的隐形捷径今天我们通过这几页书完成了从“单点直连”到“跨越公网穿行”的宏大飞跃。我们明白了什么是隧道技术把内部数据装进外层包裹搭建一座横跨互联网的空中天桥。我们看清了GRE协议的内核通过基本的 4 字节报头赋予隧道以“通行证密钥”和“顺序序列号”。我们拆解了PPTP协议的真实日志见证了一个 VPN 连接从控制通道TCP 1723开启到数据通道GRE建立再到内部 PPP 安全认证的完整历程。我们瞥见了单向链路的奇观即使在卫星与电话线这种极不对称的链路上工程界依然能用隧道和路由协议巧妙地解决问题。当你现在连接到公司的企业 VPN并看到右下角网络图标亮起时你可以默默回想刚才那段日志在那座看不见的空中天桥GRE 隧道里您的账号密码经过了 CHAP 的质询握手您的数据被加上了 128 位的 MPPE 加密锁正安全地穿梭在互联网的广阔云端。