为什么你的客户机 VPN 在 VirtualBox NAT 后面失败？

虚拟机里的浏览器能用，同一台客户机上的 VPN 客户端却传不了数据。客户机显然有连通性，所以故障出在 VPN 外层协议需要什么、虚拟 NAT 又会放行什么。结果由三个条件决定：哪个进程拥有 VPN、外层交换在线上是什么样子，以及适配器模式是不是你以为的那个。点明你能改变的那个条件，就是整个决策。

先找到 VPN 进程，再怪网络

先判断 VPN 跑在客户机里还是宿主机上，因为这两种安排的失败方式不同。客户机内的客户端通过客户机适配器及其背后的任何转换来建立自己的外层连接。宿主机 VPN 按宿主机和虚拟机监控程序策略捕获客户机流量，那是一个有自身规则的独立捕获点。两者可能同时运行并混淆证据，所以在动手之前，先确认该由哪一个承载这些流量。

在改动任何东西之前，先把客户机的适配器模式记下来。这一个值能解释后面的大部分情况，也是之后别人最先会问你的东西。

外层交换决定兼容性

VirtualBox 网络指南列出了这里要紧的 NAT 限制：它不传递 TCP 和 UDP 之外的协议，GRE 被列为不受支持，PPTP 被作为受影响的例子。PPTP 用 TCP 控制交换和 GRE 承载数据，因此控制连接可以成功，而数据路径无法越过同一条边界。这是两件不同的证据，只有一件关于承载流量。在防火墙规则里放行 TCP 端口 47 与放行 IP 协议 47 不是一回事，两者经常被混淆。

把这条限制系在当前的 NAT 安排上，而不是系在每个使用 NAT 一词的设备上。物理路由器可能毫不抱怨地放行 GRE，而虚拟 NAT 把它丢掉，另一个虚拟机监控程序对转发什么有自己的选择。当组织在 TCP 或 UDP 内提供获准的传输方式时，就用它受支持的客户端和配置走那条路。兼容性只是若干要求之一，它既不能确立对服务器的信任，也不能确立账户权限，更不能确立可用的专有路由。

桥接真正改变了什么

网桥把客户机的 MAC 地址交给物理网段，而不是把它藏在转换后面。客户机随后从服务该网段的任意 DHCP 服务器取得地址，为该地址应答 ARP，并在上游交换机看来是多出一个端口。这去掉了虚拟转换路径，也正是老配方推荐它的原因，同时它还改变了另外三件事。寻址现在来自本地网段而不是虚拟机监控程序，暴露意味着客户机对该网段可见，准入则取决于交换机端口及其策略。其中任何一条都可能成为拒绝改动的理由，而没有一条是关于 VPN 协议的。

桥接不会安装缺失的插件，不会提供不可用的秘密代理，也不会修复认证被拒。它同样不会让过时的协议变成好选择；当运维方有受维护的替代方案时，决定就是采用它，而不是改动虚拟机监控程序。端口转发完全是第三种角色：它发布入站服务，对出站客户端的外层协议毫无帮助。

两条隧道，两条证据线索

客户机 VPN 需要一条从客户机接口到对端的可用路径，之后内层地址或专有路由才有意义。如果存在宿主机 VPN，它可能按自己的策略中继或阻断这层外部交换，而客户机的内层隧道要等外层成功后才开始。任何一层的覆盖范围都无法从单个已连接的图标或宿主机浏览器的公网地址读出来。

保留第一条错误信息而不是最后一条，因为最早的失败才点明层次。一次只改一种受支持的网络安排，使用同一份客户机配置和同一组凭据，这样比较才有意义。根据失败判断坏在哪一阶段：本地集成、传输、认证，还是隧道建立后的资源访问。每一阶段有不同的负责人，只有一个是虚拟机监控程序的问题。

究竟是哪个条件在挡你

到这里，决策收窄为三个答案不同的问题。如果外层协议落在 TCP 和 UDP 之外，约束就是 NAT 模式，出路是桥接或获准的 TCP/UDP 传输。如果外层交换完成而数据路径不通，约束就是第二件证据里看到的同一个。如果隧道起来了但资源不响应，问题已经越过虚拟机监控程序，进入路由或策略。

把答案连同适配器模式一起写下来，否则下一个人会重复同一个下午。任何修正之后，都要在客户机内测试真实应用和名称解析，然后重新连接并演练失败策略。一条能通过隧道打开的网页只证明网页路径可用，这比当时感觉的要小得多。