在个人 VPN 上使用工作笔记本：真正越界的是什么

把公司笔记本接入家庭 VPN，等于让它同时身处两个地方，而真正有意思的问题比那个令人警觉的问题更小、也更有用。没有人真正在办公室和家之间拉过一根以太网线，也没有哪条路由能让家庭网络神奇地变成公司子网的延伸。实际存在的是一个能同时访问两侧环境的端点，而真正决定什么能在这两者之间流动的，是三套彼此独立的机制。从端点向外逐一走完这三处，得到的是一份管理员能据以行动的答案，而不是一场关于标签的争论。

从端点开始，而不是从网络图开始

端点才是两个连接交汇的地方，所以审查必须从这里开始：哪些进程在运行，它们能触达什么，又由谁来控制。一张画着两朵云接到笔记本上的图是准确的，却毫无用处，因为它暗示了一条可能并不存在的链路。把它换成一份能同各个环境对话的应用程序清单，并记下每一项以哪个账户运行。这样的框架也让审查保持相称：一台带两条隧道的笔记本，并不等于两张被连起来的网络。

这份清单就是后续审查所依据的盘点表。如果其中有一台同步客户端、一个同时登录两侧环境的浏览器配置文件，以及一个带有凭据的构建代理，那么审查的对象就已经齐备了。

三处越界点，逐一审视

应用程序访问是第一处越界点，它根本不需要任何转发。端点上的浏览器标签页、同步客户端或构建代理，可以从一侧环境的资源读取数据，再提交给另一侧环境的资源。无论操作系统是否在接口之间转发数据包，这种能力都存在，而这正是人们在得出没有网桥就没有风险时最容易忽略的机制。因此，读应用清单比读接口清单更有信息量。

身份与数据构成第二处越界点。公司凭据、会话 cookie、已下载的文档和管理权限都存放在端点上，而接入另一张网络本身并不会把它们泄露出去。真正改变的是：当端点持有这些凭据时，能够影响它的当事方集合变了，这是关于个人网络可信度的问题，而不是关于路由的问题。这个判断端点所有者无法独自做出，也不因为缺少某条转发规则就有了答案。

第三处是网络转发，也是唯一能把笔记本变成中转设备的一处。IP 转发、互联网连接共享、代理或桥接功能都能做到，而每一项都是要么开启、要么关闭的配置。请直接检查这个状态，而不是从某个 VPN 客户端的存在去推断。在受管机器上答案通常是否，而把它验证一遍，就把假设变成了值得记录的结论。

要的是一个资源，不是两张网络

大多数真实需求比第一眼看上去要窄：一个控制台、一份文件共享、一个内部 Web 应用。把需求这样陈述，再让资源的归属方决定它是否该落在端点上。以两张网络对接为框架的申请很难获批，也很容易被拒；针对某一项具名服务的申请则有明确答案。

如果答案是肯定的，就优先选择最窄的受支持路径，并把它留在组织现有的管控之内。受管的第二个配置文件或范围受限的应用条目能保留监控与策略；与之竞争的个人配置则会悄悄取代它们，而下一次更新之后谁也说不清哪个会赢。

把 DNS 与路由的影响算进去

第二个配置文件一激活，名称解析就变了。个人客户端可能推送自己的解析器，浏览器可能使用自己的加密 DNS，策略表也可能把内部名称送到公司配置并不预期的另一台服务器上。这些都不需要转发，而任何一项都可能把内部主机名送到错误的地方。

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

在第二个配置文件连接前后，各采集这三项输出。两者之差才是真正落到用户身上的效果，而它往往大于工单里描述的路由变化。把两次采集都留下，好让后来复核的人看到实际变了什么，而不是当初打算做什么。

验证，并留一条退路

要从真实的进程和用户上下文去测试那个获批的应用，而不是在同一台机器上用管理员 shell。然后再确认：在设计要求的地方，无关目的地确实仍然不可达，因为没人测过的边界，就是没人敢声称的边界。断开个人隧道应当恢复先前的状态，而这次恢复值得在还有人盯着的时候验证一遍。

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

NIST 关于零信任架构的指南在这里很有用，因为它把网络位置从自动获得信任的来源里剔除，而这恰恰是有争议的那个假设。问题不在于家庭网络是否天生可信，而在于谁能从哪个端点、经由哪个执行点、访问哪个资源。把这三问答清楚，并把证据和决定放在一起。