地球另一端的用户无法连接到我们的 PPTP VPN。该 VPN 是常规的 Windows Server 2003 VPN，对于大多数美国用户来说运行良好，但对于这个特定用户来说，它根本无法连接。
登录窗口在“验证用户名/密码”处挂起，并在约 30 秒后消失。我在服务器端进行了网络跟踪，这就是我看到的。10.250.10.10 是服务器的内部 IP，121.XX255 是用户的公共 IP。
显然，用户端没有新的网络设备，并且服务器端肯定没有任何变化。
知道如何诊断吗？
答案1
NAT= 网络地址转换器（设备）或网络地址转换（概念），取决于上下文。
拍= 端口地址转换器（设备）或端口地址转换（概念），取决于上下文
当任一端（客户端或服务器）位于不支持 PPTP+GRE 协议（或不能很好地支持该协议）的 NAT/PAT 边界之后时，这个问题非常常见。
在 PPTP 领域，TCP/1723 是一个简单的控制通道，其唯一目的是建立 Microsoft 特定的辅助 GRE (IP/47) 隧道。此 GRE 隧道包含封装的 PPP 帧，用于协商身份验证、加密和传递实际数据。
并非所有 NAT（防火墙、路由器、设备）都支持将辅助 GRE 隧道传递到客户端/服务器。PPTP VPN 客户端将显示连接，然后出现“验证用户名和密码”消息并挂起。“验证用户名和密码”阶段需要 GRE 隧道正常运行。
某些 NAT/PAT 可能支持单个用户在 NAT/PAT 后面使用单个 PPTP+GRE，但来自同一用户或 NAT/PAT 后面不同用户的第二个 PPTP+GRE 可能会失败。我见过消费者级、商业级和企业级 NAT/PAT 中通过 NAT/PAT 的 PPTP+GRE 出现多种严重故障
在您的具体情况下 - 如果其他用户能使用 PPTP+GRE 可以正常连接到您的 RRAS，但该单个用户无法连接 - 这可能是该用户网络上的 NAT/PAT 边界。
如果该特定用户的互联网和边缘硬件不达标，请准备好花费大量时间来诊断此问题——尤其是如果它来自执行运营商级 NAT（CGN）的提供商。
如果你可以访问用户的 PC 并在其 PC 上运行 Wireshark，同时尝试连接并查找 GRE 数据报到和从RRAS 服务器。如果 GRE 隧道失败，您可能会看到发往 RRAS 服务器公共 IP 的 GRE 数据报，但看不到来自 RRAS 服务器公共 IP 的返回 GRE 数据报。
如果是这种情况，则问题出在 PC 的上游。查看所有上游 NAT/PAT，确保它们支持 PPTP+GRE 修复/直通/检查或供应商所称的任何功能。请注意，有些供应商尽管“支持”PPTP+GRE，但仅以有限的方式支持它 — 如前所述。Cisco ASA 和 PIX 长期以来一直非常出色地支持 PPTP+GRE 修复/检查 — 通常默认情况下不启用。
通过 NAT/PAT 运行 PPTP、L2TP 和 IPsec VPN 都相当麻烦，除非小心克服 NAT/PAT。根据我的经验，唯一能够轻松穿透 NAT/PAT 的 VPN 技术是基于 SSL/TLS 的 VPN。
答案2
我没有看到客户端对服务器 SYN-ACK 的 ACK。以下是从我的工作站到内部 RRAS 服务器的 Microsoft Network Monitor 捕获的片段。您可以清楚地看到在进行任何 PPTP 协商之前发生的 TCP 三向握手。如果客户端没有对服务器 SYN-ACK 进行 ACK，那么我会说问题就出在这里。
编辑
这次在服务器上使用 Wireshark，我在查看对话流时看到的内容与您相同。如下面的屏幕截图所示，两者略有不同。我的捕获中有 3 条 Set-Link-Info 控制消息，而您的捕获中只有 1 条。我猜服务器和客户端无法协商连接参数。除此之外，我一无所知。很抱歉，我无法提供更多帮助。
