对PPTP的术语感到困惑，谁是PNS，谁是PAC

Question 1

造成这种混乱的主要原因是，如今 PPTP 的使用方式与最初设想的方式不同。PPTP 协议并非作为 VPN 协议创建的，而是为了解决当时的一个常见问题：ISP 的 PPP 多链路聚合。

在创建该协议时，大多数人仍会使用电话线上的调制解调器连接来连接到互联网。这种连接的带宽相当有限，很快就成为一个限制因素。人们试图解决这个问题，只需获得一条以上的电话线并建立到同一 ISP 的多个调制解调器连接即可。只要 ISP 仅作为单个拨入集中器运行，所有互联网流量也会终止，这种方法就很好。但是，如果 ISP 运行多个这样的集中器，则两个连接可以拨入不同的集中器 - 它们的终止位置是随机的 - 然后聚合就不再可能了，因为来自互联网的流量只能终止于其中一个集中器，因此实际上只使用了一条调制解调器线路。然后人们会挂断电话并反复拨号，直到他们最终用所有线路到达同一个集中器。我想每个人都看到了这里的问题。

这正是 PPTP 应该解决的问题。拨入集中器被分成两个组件：PAC 和 PNS。用户拨入任意 PAC，PAC 将所有流量传输到中央 PNS，所有互联网流量也都在此终止。即使多次拨入多个 PAC，系统仍能按预期工作，因为互联网流量仅终止于中央 PNS，而不是各个 PAC。

来源：https://www.decodednode.com/2014/03/vpn-terminology-pptp-and-l2tpipsec.html

请注意，PPTP 仅在 PAC 和 PNS 之间使用；PAC 左侧和 PNS 右侧的组件对 PPTP 一无所知。

后来，PPTP 也用于电话运营商提供的 VPN 隧道服务。因此，PNS 被置于公司的专用网络中，而 PAC 仍由电话运营商运营，远程办公人员可以拨入该电话运营商的 PAC，进行身份验证，然后通过位于该处的 PNS 直接访问公司的专用网络。电话运营商将保证 PNS 和 PAC 之间交换的所有流量的安全性和保密性，但无论如何他们这样做，因为 PPTP 本身并不提供这样的服务。

随着调制解调器连接的消失，该协议变得相当过时，但它已被许多公司广泛采用用于 VPN 服务，并且由于 PNS 仍然存在，该协议被重新用作 VPN 隧道协议。现在，VPN 客户端计算机本身将假装是 PAC 并通过 Internet 连接到 PNS。为了确保在没有电话运营商提供安全保障的情况下数据仍然安全，Microsoft 只是通过添加加密 (MPPE) 扩展了 PPP 协议，该加密与 MS-CHAP(v2) 身份验证协议派生的密钥一起使用，现在隧道数据本身（包装在 PPP over GRE 中）可以加密。由于所有这些都发生在 PPP 协议中，因此不需要在任何 PPTP 客户端/服务器上触及一行 PPTP 代码（PPTP 本身仍然不知道所有这些）。

请注意，对于 PPTP 管理本身而言，角色并不重要。谁是 PAC、谁是 PNS 并不重要，因为任何一方都可以向另一方请求新连接，角色完全可以互换。角色只在呼叫管理（拨出和拨入电话呼叫请求）中是固定的，但整个呼叫管理已经过时，因为没有人再呼叫任何人，只需要注册一个呼叫 ID，因为在通过 GRE 隧道传输流量时需要该 ID。

因此微软只是交换了角色：

在本文档中，术语 PPTP 访问集中器 (PAC) 和服务器以及术语 PPTP 网络服务器 (PNS) 和客户端可互换使用。本文档指定自愿隧道的使用，其中 PPTP 隧道端点和 PPP 端点位于 PAC（作为服务器）和 PNS（作为远程客户端）上。

来源：[MS-PTPT]：点对点隧道协议 (PPTP) 配置文件

现在 PAC 充当服务器，而 PNS 充当远程客户端。PNS 建立与 PAC 的连接（RFC 允许），然后请求拨出电话以注册呼叫 ID。

有趣的是，微软自己在他们自己的文档中对此感到困惑：

以下示例显示了当运行 Windows Vista 操作系统 Service Pack 1 (SP1) 的计算机（名称：“testclient.contoso.com”）（IP 地址为 1.1.1.1（客户端 100 兆比特每秒连接）与运行 Windows Server 2008 操作系统的计算机（名称：“testserver.contoso.com”）（IP 地址为 2.2.2.2（服务器，100 兆比特每秒连接））建立 PPTP 隧道时交换的消息序列。

在此示例中，计算机“testclient.contoso.com”是 PAC，而计算机“testserver.contoso.com”是 PNS。

来源：PPTP 协议示例

最后一句话是错误的，按照那份文件的介绍应该是反过来的。

我猜大多数现代实现根本不在乎，因为它们实现了协议的所有部分，因此可以充当 PAC 或 PNS，甚至可以根据具体情况来充当。建立 PPTP 控制通道后，双方都不知道它应该充当 PAC 还是 PNS，因此任何一方都可以向另一方发送拨出呼叫请求，然后将角色设置为“该请求的发送者是 PNS，接收者是 PAC”，但在发送此类消息之前，角色是开放的。

考虑到目前协议的使用方式，如果服务器充当 PAC 的角色，那就更有意义了。当然反过来也行得通，但对于大多数网络开发人员来说，这似乎不合逻辑，因为客户端和服务器之间的消息传递似乎混杂在一起（服务器将向客户端发送请求，客户端将响应这些请求并主动通知服务器状态变化 - 大多数人期望相反）。

这实际上不是问题的一部分，但在谈论 PPTP 时必须提及：请注意，截至今天，PPTP 是完全不安全的！MS-CHAP(v2) 使用弱 DES 算法进行密码操作，可以使用自定义破解硬件进行暴力破解。此外，用于加密有效载荷数据的派生密钥（可以是 40 位或 128 位）始终与 RC4 密码一起使用，并且众所周知，NSA 能够实时破解 RC4。L2TP 已被引入以取代 PPTP，因为它的设计要好得多，但它也有些过度，而且 L2TP 的安全性仅由 IPSec 提供，因此，直接使用 IPSec 作为 VPN 隧道协议可以获得相同的安全级别，只是协议开销要少得多（仅使用 IPSec 就可以直接在 IP 中建立隧道，不需要其他协议）。IPSec 仍然是目前仍在使用的最佳 VPN 协议，基于 SSL 的协议（如 OpenVPN）可能更容易设置，并且在受限网络环境中造成的麻烦更少，但它们在安全性或速度方面都无法与 IPSec 匹敌。我只会在无法使用 IPSec 的情况下将它们用作后备。

Answer