Windows Sandbox 的流量默认不跟随宿主机 VPN

你启动 Windows Sandbox，在其中打开浏览器，页面却通过你的普通连接加载，尽管一分钟前宿主机还在 VPN 上。并没有哪里坏掉。沙盒得到一块挂在宿主机默认交换机上的虚拟网络适配器，而宿主机的隧道是否覆盖这条路径属于 VPN 客户端的属性，而不是 Windows 的属性。

沙盒实际得到的是什么

沙盒是一台带自己网络适配器的轻量虚拟机。那块适配器通过宿主机的 Hyper-V 默认交换机接入，交换机在数据帧离开机器之前把沙盒的流量转换成宿主机的虚拟以太网接口。这个细节解释了人们就此报告的几乎所有症状。

所以沙盒不是你桌面上的一个进程。它是一个独立的网络端点，数据包由宿主机转发，而宿主机的防火墙和 VPN 客户端各自以不同方式看待这次转发。为浏览器进程编写的规则不会自动匹配来自虚拟交换机的转换后数据帧。

两个看起来像同一个的需求

访问私有资源和强制沙盒的每个请求都走隧道是两个不同的目标。前者需要一条能为沙盒端点工作的路由和名称解析。后者需要能在重连和故障后仍然生效的强制。两者互不推导，满足其中一个的检查对另一个毫无说明。

公网地址检查并不能完整回答这两个问题中的任何一个。在沙盒内部看到 VPN 出口只能说明有部分流量走了隧道。它既不能说明私有名称是否被解析，也不能说明隧道中断时开始的请求会怎样。

在测试任何东西之前，先写下你需要的是哪一个，因为这两个需求会导向不同的设计，而只有其中一个能用浏览器验证。

从沙盒内部检查

唯一有意义的观察来自沙盒自己的会话，而不是宿主机。在那里打开 PowerShell，查看适配器、名称解析以及通往某个文档地址的路径：

ipconfig /all
Resolve-DnsName files.corp.example
Test-NetConnection 198.51.100.7 -Port 443
Get-NetRoute -DestinationPrefix 0.0.0.0/0

适配器列表给出沙盒拿到的地址和网关。网关与宿主机不同对默认交换机来说是正常的，所以要比对出口而不是网关。解析测试显示私有名称到底有没有应答，而这通常正是分离式解析（split-horizon）配置与宿主机出现分歧的地方。路由那一行显示沙盒认为哪个网关拥有默认路由。

在隧道连接和断开两种状态下重复同样的三项检查。两种状态之间不发生变化的结果，就是隧道根本不在沙盒路径上的证据，无论公网检查显示了哪个地址。

沙盒不需要网络时就把它关掉

对于离线检查，自定义配置文件可以完全移除网络。该设置是配置文档中的单个元素：

<Configuration>
  <Networking>Disable</Networking>
</Configuration>

沙盒配置参考 记录了这个元素，并警告启用网络可能把内部网络暴露给你并不信任的应用程序。正是这条警告构成了显式设置它而不是接受默认值的全部理由。

不过这个开关并不选择某块 VPN 接口。它是关于有没有网络的二元决定，而不是把沙盒绑定到某条隧道的手段。一个点名出口的需求，无法靠只决定“有没有出口”的开关来满足。

在授予任何东西之前先设计边界

如果需求是严格隔离，那就选择一种能够强制实施它的虚拟机网络设计，并对转发流量或虚拟机流量使用 VPN 产品所支持的策略。猜测宿主机客户端的行为不是设计，一次成功的检查也不是实现。

不要让一个不受信任的沙盒拿到企业 VPN 配置或私有凭据来换取测试通过。那等于把你本想建立的边界换成一次绿色结果，而凭据会比测试活得更久。

把网络模式、观察到的出口以及重连行为记录到部署笔记里。当某次客户端更新改变了转发流量的处理方式时，正是这些笔记会告诉你需求其实从未真正满足。