RDP 更换了客户端：数据库为何看到另一台主机

你的 VPN 规则拒绝了数据库，工单也以防火墙故障结案；可同一个用户打开已发布桌面后，却能顺利查询那台数据库。两句话都是真的。桌面是另一个客户端，它在规则本就信任的网段上有自己的地址，继续向外连接时又有自己的身份。看起来自相矛盾的规则，往往是一条没人放进评审的第二请求。

第二请求有自己的客户端地址

当会话内的应用向数据库发起连接时，TCP 握手从会话主机开始。它的源地址属于该主机所在网络，因此沿途每个路由器和数据库防火墙评估的都是桌面所在网段，而不是你笔记本来自的隧道地址池。VPN 地址根本不会出现在这条流里。这就是为什么一条基于源地址的拒绝规则可以同时既正确又无关。

要从会话内部而不是笔记本上读取来源，然后再从同一位置测试后续路径。两个答案应当就“是哪台主机在发起请求”达成一致。

whoami
ipconfig /all
Test-NetConnection db01.corp.internal -Port 5432

把会话报告的内容与数据库在同一时刻记录的地址做比较。当服务器日志显示的是桌面网段而不是隧道地址池时，问题就不再是规则有没有触发，而变成了是哪台主机发的请求。那是另一个责任人负责的另一项调查。

身份也随之改变，不只是地址

向外连接通常以会话令牌、已存储的凭据或应用服务账号完成认证，资源记录的是它实际拿到的那一个。因此，数据库上出现服务账号的审计记录，并不能证明查询由人执行。它也并未指出是哪个人。只有桌面自身的会话日志才能把这两条记录连起来。

授权发生两次，第二次决策所用的输入并不相同。第一次给某个具名用户授予桌面登录权，第二次授予的是该用户令牌或应用账号对资源能做什么。能打开桌面的服务台组，并不会自动成为能读取客户表的组。

在写访问说明之前，先看令牌和委派路径。两者都能从会话内部看到，而这也是唯一让答案不再是猜测的地方。

whoami /groups
klist
query session

如果应用使用服务账号，真正影响下游的是它的权限。轮换那份凭据属于访问评审，而不是事后的运维感想。

为什么直连路径依然被正确地阻断

拒绝规则并不因为目标另有路径可达就是错的。分段是按源逐条评估的，而桌面所在网段早在有人把它当成通往数据库的路之前就已放行。没有任何东西绕过了策略。策略只是描述了两种不同的源会得到两种不同的结果。

评审要回答的是：该主机上每一个被授权的会话能启动什么。带保存会话的浏览器、映射的驱动器、持有凭据的代理，以及本地监听的服务，都在扩大桌面的触达范围，而它们没有一个出现在批准登录的那张工单里。那份清单才是真正的权限面。

要在测试会话内部枚举它，而不是在表格里。几条命令就能覆盖大部分表面。

Get-NetTCPConnection -State Listen | Select-Object LocalAddress,LocalPort,OwningProcess
net use
Get-ChildItem Env: | Where-Object Name -match 'PROXY|DATABASE|API'

有意识地选择边界

三种形态适合不同任务，选择应当跟随任务，而不是碰巧存在的工具。已发布应用暴露的是带自身权限的单个程序，完整桌面暴露的是用户配置文件能做的一切，带源限制的窄口径数据库账号则完全不需要桌面就能暴露一个资源。能完成工作的最窄形态才是该记录的那个。任何更宽的做法，都需要在旁边写明理由。

对单份报表来说，已发布应用或受限账号是比通用桌面更小的授权。对确实需要多种工具的维护来说，桌面可能是对的，但那时审批描述的是整台主机而不是一个应用。要问资源所有者，他们同意的究竟是哪一种。

数据流动是另一个开关。剪贴板、驱动器重定向和下载都可能把公司数据带到客户端，而远程运行应用本身并不能让数据留在远端。

两项审批和移除路径都要检查

记录里应有两项审批：到达并打开桌面的权利，以及从桌面内部使用资源的权利。为每一项指定所有者，并让第二项对所有评审该资源的人可见。审计人员会问的正是第二条，因为它描述的是触达而不是进入。两项都要在变更获批之前写下，而不是在第一次出事之后。

然后测试移除，因为断开的会话可能比它存在的理由活得更久。会话表是查看还有什么在运行的最快位置。

query session
query user
qwinsta /server:rdsh01.corp.internal

断开客户端会让远程会话继续运行，它的网络连接和缓存凭据在该会话结束前可能仍然可用。要注销，或者显式结束会话，并确认此后下游计数不再前进。只合上笔记本盖子的移除测试什么都证明不了。同一测试要做两次：一次停用账号，一次移除桌面权限，然后记录每种情况下资源留下了什么日志。