通过热点使用 PPTP：TCP 1723 只是一半

按顺序逐项检查：控制连接是否建立，GRE 是否能穿过路径，服务器是否接受呼叫，以及认证是否完成。PPTP 客户端既需要 1723 上的 TCP 会话，也需要承载数据的 GRE 路径，而热点可能放行其中一个却丢掉另一个。按顺序做能告诉你该排查哪一道边界，而不是靠猜。Windows 的错误编号做不到这一点。

GRE 是 IP 协议 47。它不是 TCP 或 UDP 的 47 端口，这个区别解释了关于防火墙的大部分混乱。

两条路径，一个连接

控制连接是到目标端口 1723 的普通 TCP 会话，大多数网络都会放行而不抱怨。数据路径是 GRE，协议 47，而放行前者的防火墙可能对后者一无所知。这种组合会产生一个看起来已经启动、随后却什么都传不了的客户端，比连接被拒绝更缺乏信息。在对运营商下结论之前，请分别测试两条路径。

转换还有自己的要求。共享端口的网关通常需要能识别 PPTP 的 ALG，以便连同地址一起改写呼叫标识，而没有它的网关可能把会话弄坏成丢包的样子。这种行为很常见但取决于实现，所以应把任何厂商限制当作例子，而不是每个热点的属性。

热点又多了两道边界

客户端流量通常先经过手机自身的共享 NAT，再经过运营商级转换，然后才到达服务器。办公路由器上的规则修不好别人的中间盒，这就是家里的端口转发很少有用的原因。出站客户端也不需要为它开放入站端口；被转换连接的回应会沿网关创建的状态返回。托管在 NAT 后面的服务器则有一整套完全不同的要求。

名为 PPTP passthrough 的菜单项（如果有）决定该设备如何处理这个协议。它和手机上托管 VPN 或无条件转发所有协议不是同一个功能，启用它也不是放行 GRE 的通用许可。

把 807 读作中断，而不是判决

Windows 把 807 报告为连接被中断，这描述的是结果而不是原因。它的错误表把 806 单独列为与 GRE 相关的类别，在建立理论之前值得知道这个区别。这两个编号都不能说明运营商是否过滤了协议 47、服务器是否容量耗尽，或者凭据是否正确。错误说会话结束了；路径说在哪里结束。

在热点上通过的浏览器测试只能证明普通应用路径可用。它对 GRE 一无所知。

隔离失败的那个阶段

保持笔记本、服务器和配置文件不变，只把接入网络换成另一个获批的网络。如果结果改变，就在你能控制的边界抓取 TCP 与 GRE 交互，找出最早一个从未发生的阶段：控制建立、呼叫建立、数据交付或 PPP 认证。每个阶段在抓包里留下不同的特征。把正常网络与故障网络对比，比再读一遍错误文本有用得多。

这一切诊断的是已经存在的部署。它不是新建 PPTP 服务的理由，而且协议无法通过谈判绕过：安装不同的客户端并不能让未改动的服务器说出别的东西。

为了持续访问，请与 VPN 的所有者商定受支持的迁移方案。这份清单以决定收尾，而不是以绕行方案收尾。