为什么你的 VPN 适配器停留在公用防火墙配置文件上
域登录并不会把网络归类为域，公用与专用也不能互相替代。先读规则所属的配置文件，再看真正执行它的那台机器。
隧道已经建立，账户也通过了域身份验证，但 Windows 仍把这条连接标记为公用。于是为域配置文件编写的防火墙规则不会生效，文件共享依旧不可达。常见的修法是把适配器改成专用，这只改变了哪些规则生效，对身份验证没有任何影响。标签和修法都被广泛误解，而要把两者分开需要三条命令。
拨入的账户不是网络的类别
一次 VPN 连接里会发生两个不同的判断，它们很容易被混为一谈。网关判断账户能否接入。Windows 判断如何归类由此产生的网络，而这个归类决定了哪些防火墙规则作用于该接口。
在网关处成功完成域身份验证，只是关于账户的证据。它不是端点让网络通过了域控制器验证的证据，而后者才是域类别真正代表的含义。
这就是为什么一台已加入域的机器可以用域账户拨入，却仍显示为公用。归类是对网络所做的本地判定，而不是对打开隧道所用凭据的陈述。账户完全有效，标签却可以原地不动。
三个类别，其中一个你无法设置
Windows 提供三个类别，其中只有两个可以由管理员指定。第三个由操作系统在成功让网络通过域控制器验证之后决定。
| Category | How it is assigned | What it affects |
|---|---|---|
| Public | Default for unidentified networks, or set manually | Rules scoped to the public profile |
| Private | Set manually, or by the user on a trusted network | Rules scoped to the private profile |
| DomainAuthenticated | Determined by Windows after domain authentication | Rules scoped to the domain profile |
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated第三条命令会失败，这是有文档记载的行为，而不是权限问题。该命令自身的参考文档说明，域类别不能这样指定，因为 Windows 是从域身份验证推导出它的。看到这个错误恰恰是有用的确认：类别是结果，不是设置。
在被封堵流量的那个端点上读第一条命令。网关自身接口的归类，完全不能说明每台接入的工作站如何归类自己的隧道。
规则跟随它编写时面向的配置文件
一旦知道类别，缺失的访问权限通常自己就解释清楚了。每条 Windows 防火墙规则都带有一个配置文件范围，而限定为域的规则在接口为公用时不生效。三条命令把这件事变成答案而不是推测，第三条还能抓到配置文件从来不是问题的情形：
(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction第二条命令才是把含糊报告变成修复的那一步。如果规则限定在不包含 VPN 地址池的远程地址范围内，改配置文件同样无济于事。
也要检查默认的入站操作。在入站默认被阻止的机器上，缺少允许规则产生的是沉默而不是拒绝。从客户端看，这与路由故障毫无区别，所以这类工单很多一开始就建立在错误假设上。
弄清是哪台机器在强制执行规则
改类别之前，先确定阻塞发生在哪里。承载共享的服务器可能自带防火墙，它的规则对来自 VPN 地址池的流量照常生效，与客户端如何标记适配器无关。那里的拒绝对你运行的任何本地命令都是不可见的，客户端一侧只会报告资源不可用。动客户端的归类之前，先测目标自己的规则。
从客户端测到具体端口，再与同一 VPN 上另一台主机的测试作对比。两者都失败，问题在目标或路径上。只有一个失败，差异就限于那台机器，配置文件类别便成为可能的原因。
还要记得方向。允许入站 SMB 的规则，对自身出站规则同样拦下这段流量的客户端毫无帮助。从文件资源管理器窗口看，两种失败无法区分，所以改动任何东西之前要分别测试每个方向。
与其重新打标签，不如做什么
为了让一条宽泛规则生效而把未知网络改成专用，是带有真实后果的真实变更。专用配置文件通常比公用允许更多的发现和更多的入站流量。
如果目标是让某个具体服务访问到 VPN 客户端，就按远程地址而不是按配置文件来限定规则。这精确表达了意图，不受归类影响，也不依赖 Windows 对虚拟适配器猜得准不准。它还能扛住一次重新归类接口的客户端更新。把地址池写进规则，下一个人不用问就能读出意图。
如果确实期待域类别却始终不出现，那是另一项排查。检查机器是否已加入域、能否通过隧道到达域控制器、安全通道是否健康。这三条命令不需要改一次注册表就能给出答案：
Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com这三条回答的是端点究竟有没有可能完成网络验证。如果它到不了控制器，无论把适配器重置多少次，域类别都不会被赋予。你一直在追的那条防火墙规则从来不是真问题，标签是路径断裂的症状，而不是原因。