握手期间PPTP连接失败

NAT =networking地址转换器（设备）或networking地址转换（概念）取决于上下文。

PAT =端口地址转换器（设备）或端口地址转换（概念）取决于上下文

当任何一端（客户端或服务器）位于不支持PPTP + GRE协议的NAT / PAT边界之后，或者不能很好地支持时，这个问题非常普遍。

在PPTP领域，TCP / 1723是一个简单的控制通道，其唯一目的是提出一个Microsoft特定的辅助GRE（IP / 47）通道。 GRE隧道包含封装的PPP帧，用于协商authentication，encryption和传递实际数据。

并非所有的NAT（防火墙，路由器，设备）都支持将辅助GRE隧道传递给客户端/服务器。 PPTP VPN客户端将显示连接，获取“validation用户名和密码”消息并挂在那里。 “validation用户名和密码”阶段要求GRE隧道function正常。

某些NAT / PAT可能支持NAT / PAT之后的单个用户的单个PPTP + GRE，但来自同一用户或NAT / PAT之后的另一个用户的第二个PPTP + GRE可能会失败。 通过NAT / PAT，PPTP + GRE在消费者，企业级和企业级NAT / PAT上都看到了许多令人惊叹的失败

在您的特定情况下 – 如果其他用户可以使用PPTP + GRE连接到您的RRAS，但是这个用户不能 – 它可能是该用户networking上的NAT / PAT边界。

如果这个特定的用户具有不合标准的互联网和边缘硬件，尤其是从提供商执行运营商级NAT（CGN）的提供商那里准备花费大量的时间来诊断这个问题。

如果您可以访问用户的PC并在PC上运行Wireshark，同时尝试连接并查找来自 RRAS服务器的GRE数据报。 如果GRE隧道出现故障，您可能会看到一个GRE数据报发往RRAS服务器的公有IP，但没有看到来自RRAS服务器公用IP的返回GRE数据报。

如果是这种情况，那么PC的上游就是问题。 查看所有上游的NAT / PAT，以确保它们支持PPTP + GRE fixup / passthrough / inspection或任何供应商称之为的。 要知道，一些供应商，尽pipe“支持”PPTP + GRE，只能以有限的方式支持它 – 如前所述。 思科ASA和PIX对PPTP + GRE修复/检测的支持已经相当长一段时间了 – 通常不会默认启用。

通过NAT / PAT运行PPTP，L2TP和IPsec VPN都是相当有问题的，除非注意克服NAT / PAT。 关于唯一可以轻松穿透NAT / PAT的VPN技术是基于SSL / TLS的VPN – 以我的经验。

我没有看到从客户端的ACK到服务器的SYN-ACK。 这是从我的工作站到内部RRAS服务器的Microsoftnetworking监视器捕获片段。 您可以清楚地看到在进行任何PPTP协商之前发生的TCP三方握手。 如果客户端确认服务器的SYN-ACK没有发生，那么我会说这是问题所在。

编辑

这次在服务器上使用Wireshark，在查看对话stream时，我看到了和你一样的东西。 下面的屏幕截图显示了一个细微的差异。 在我的捕捉中有3个Set-Link-Info控制消息，而不是捕捉中的1。 我的猜测是，服务器和客户端无法协商连接参数。 除此之外，我不知道。 对不起，我不能有更多的帮助。