通过站点 VPN 映射网络驱动器：DNS、SMB 与 UNC 路径
网络发现无法跨越路由链路，但带名称的 UNC 路径可以。把 DNS 指向服务器，双向放行 SMB，然后映射驱动器。
资源管理器里的“网络”页面只显示在本地网段广播过自己的设备，而经过路由的隧道不会承载这些通告。这就是为什么服务器明明完全可达，用户面前的窗口却空空如也。带名称的 UNC 路径根本不依赖发现，解决办法是让名称能解析、端口能应答。空窗口是层次不对的症状，而不是共享坏了。
发现与可达不是一回事
Windows 通过为广播域设计的协议找到附近的机器，再把找到的结果当作便利列表呈现。那份列表里的任何内容都不是 SMB 文件访问所必需的。只要客户端知道服务器名称并能连到 TCP 445，无论这台机器是否出现在“网络”里，它都能打开共享。
两层各自独立失败，所以“我看不到”和“我打不开”值得分别测试。看列表说明的是发现；打开路径说明的是服务。
先给服务器命名，再映射共享
在 DNS 中发布文件服务器，填入它在对端持有的地址，并把客户端站点指向能为该区域作答的解析器。完全限定名称可以避免依赖本地后缀搜索列表——短名称在一个站点可用、在另一个站点失效，通常就是这个原因。
如果环境使用 Active Directory，名称解析也是身份验证的一部分：客户端必须能连到域控制器以完成 Kerberos，时钟偏差过大会让票据交换失败。这属于另一类问题，看起来却像凭据错误。重新输入密码之前，先测试域控制器。
| Layer | What it needs | Symptom when missing |
|---|---|---|
| Name resolution | A DNS answer for the server name | Path cannot be found, ping by IP still works |
| Transport | TCP 445 open in both directions | Connection times out or is refused |
| Authentication | A reachable domain controller and correct clock | Access is denied after the port connects |
| Authorization | Share permission and filesystem permission | The share opens but the folder is inaccessible |
双向路由与过滤
站点到站点隧道需要本地路由表里有远端前缀、远端表里有本地前缀，并且两端防火墙都要放行到达的流量。单向配置会得到一条能建立却永不回应的连接，用户会称之为共享很慢。先看隧道自身的计数器。如果数据包只出不回，就去查回程路由或远端过滤。
在 WireGuard 中，对端的允许 IP 与操作系统路由必须与该设计保持一致。隧道只负责传输数据包；它既不提供 DNS 记录，也不提供共享权限，两端都是如此。
把防火墙规则建立在真正会发起连接的源网段上，并把例外记录下来。如果设计在路径上某处做了地址转换，规则就必须使用转换后的源地址，而原始客户端地址在日志里就看不到了。
先认证，再映射驱动器
用命令而不是资源管理器窗口逐层往下排查：
Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:no第二条命令证明的是 TCP 通路，而不是读取权限。第三条才是真正检验身份验证与授权的地方，那里失败应当让你去查共享与文件系统权限，而不是回到路由器。
保持 SMB 签名与现有身份验证策略不变。对于显式路径，重新启用 SMB1 或把发现广播翻过隧道都没有必要，TCP 445 也应留在私有路径上，而不是放在面向互联网的转发上。给用户一个指向已批准名称的托管快捷方式或映射驱动器，空的“网络”页面就不再重要了。