VPN 上的 SQL：直连客户端还是内部工作站？

团队希望在自己的笔记本上使用 SSMS，而快速方案是把 SQL 端口发布到 VPN 地址池。更慢的答案要先问客户端进程应该在哪里运行，因为直连访问和内部工作站会产生不同的源地址、端点信任以及数据路径。两者都不是自动安全的，仅凭 VPN 成员身份什么都决定不了。在出现允许规则之前，先把两种设计比较清楚。

两条路径，两个源地址

直连访问时，笔记本持有客户端配置并自行打开数据库连接。使用远程工作站时，笔记本打开桌面会话，由工作站以自己的地址发起 SQL 连接。因此第一种设计里数据库看到的是 VPN 地址池或经过转换的网关，第二种里看到的是工作站地址。这个差别决定了实际生效的是哪条防火墙规则、哪项 SQL 权限。

笔记本仍然控制着远程会话，因此工作站不能替代用户身份验证或会话策略。

核实数据库实际看到的内容

源地址需要实测，而不是从架构图上推断。请在活动连接的服务器侧读取它。

Test-NetConnection sql.example.com -Port 1433
sqlcmd -S tcp:sql.example.com,1433 -N -d appdb -Q "select SUSER_SNAME() as login_name, DB_NAME() as db"

连通性测试证明监听器接受来自该网络的 TCP，查询则证明会话到达了哪个登录名和哪个数据库。要查看服务器记录的地址，请对当前会话查询 sys.dm_exec_connections，它会在任何地址转换之后返回客户端地址。如果该值是网关而不是笔记本，按用户配置的主机规则就无法在数据库机器上生效。把观测到的值写在所选设计旁边，因为重连和地址池变更都会让它移动。

只打开监听器，不多开

只打开部署所需的服务。熟悉的 1433 是默认实例的端口，并不是通用常量。

Get-NetTCPConnection -State Listen -LocalPort 1433

命名实例常常监听动态端口，由 SQL Server Browser 在 UDP 1434 上应答发现请求，而这一依赖是需要单独论证的暴露面。为实例固定端口就不再需要 Browser，防火墙规则也更稳定。保留客户端已有的加密和证书检查，不要为了让测试通过而关闭它们。然后为工作负载授予数据库角色，而不是把整个 VPN 组加进服务器角色。

证明被允许的路径和被拒绝的路径

以普通已批准用户的身份打开新会话，确认服务器身份、数据库和所需操作。然后确认排除项：策略之外的来源或账户必须在同一测试中失败。对于工作站设计，要验证笔记本无法通过直接访问数据库来绕过边界。对于直连访问，要验证重连后路由和源规则依然成立。

记录客户端在哪里运行、数据库观测到哪个来源、由哪条规则放行。这就是下一次评审会索要的证据。