如何通过虚拟机中的 VPN 访问私有服务

把来宾和 Mac 看作两个独立网络，只由一扇窄门相连。虚拟机保留自己的 VPN 客户端和独立的联网路径；Mac 只通过一个仅主机适配器和一个已转发端口访问恰好一个服务。其他流量都不应穿越。按顺序执行各步骤，任一步失败就停下，因为后面的每一步都以先前步骤成立为前提。

改动任何设置之前先记录两条路径

在来宾上，ipconfig /all 会显示承载 VPN 传输的适配器，以及它从虚拟网络 DHCP 获得的地址。在 Mac 上，记录虚拟机监控程序为该网段创建的虚拟接口；使用 VMware Fusion 时，仅主机设备通常是 vmnet1，Parallels 则会另起名称。留意那里由谁分配地址，然后把所有内容都写下来，因为重建虚拟网络时，仅主机子网经常被重新分配。要在虚拟机监控程序里核对虚拟机的网络模式，而不是凭记忆。面向互联网的适配器使用共享或 NAT 模式，面向 Mac 的适配器使用仅主机模式，这正是这些步骤假定的布局。

两个适配器，两种用途。把两者混在一起，让一个适配器同时服务 Mac 和互联网，正是把一扇窄门变成一条被路由的路径。

先确认来宾自己的 VPN

在 Windows 内启动客户端，并用厂商记载的任何测试确认它能正常结束。在来宾单独访问到私有服务之前不要继续，因为叠加在坏隧道上的转发问题有两个成因，而且没有可用的错误信息。记录服务在来宾内部解析到的私有地址。转发规则只应指向这个地址。

如果客户端推送全隧道，仅主机适配器仍承载本地流量，但要确认私有目标没有被隧道以改变其地址的方式接管。拆分隧道配置文件能让这一步更简单，值得向 VPN 的所有者申请。

添加仅主机一腿并单独测试

给来宾接上仅主机适配器，在无人使用的子网上给它一个静态地址，并确认 Mac 能 ping 通。分别在 VPN 连接和断开时测试，因为地址必须在这两种情况下都成立。只在隧道建立时才应答的来宾存在你尚未发现的路由问题。

Windows 可能把新适配器归类为公用网络，这会默认阻止入站流量。先设置好配置文件，再去排查其他问题。

只转发一个端口，而不是整个子网

优先使用单个转发端口，而不是通用的 IP 转发。Windows 自带 netsh interface portproxy，它把监听端口转发到目标主机和端口，并且需要 IP Helper 服务处于运行状态。

始终把 listenaddress 设为仅主机地址。省略它就会绑定所有接口，从而把服务暴露给虚拟机所在的任何网络。添加一条限定在仅主机接口和那一个端口上的防火墙规则，让监听与许可保持一致。了解代理的应用可能更愿意在来宾内部放一个小代理，它会终止连接，也不需要回程路由到 Mac。协议允许时就选代理，因为它在构造上就是失败关闭的。

验证，然后写下回滚

从 Mac 解析私有名称，执行既定操作，然后停用来宾的 VPN，确认操作失败而不是悄悄回退。正是最后这项检查证明路径就是你搭建的那条。记录网关看到的是哪个身份，以及谁有权使用该转发。

把回滚写成三个步骤：删除 portproxy 条目，删除防火墙规则，断开仅主机适配器。然后在真正需要之前先运行一次，确认来宾自己的 VPN 之后仍然可用。如果你的组织要求每台 Mac 各自注册，就停在这里并改用那种模型，因为共享的转发点会把访问集中在一台来宾上。无论如何，都要把地址和端口写进变更记录；下一个人不会想重新发现它们。