Unitat assignada a través d'una VPN d'emplaçament: DNS, SMB i la ruta UNC

La pàgina Xarxa de l'Explorador mostra els dispositius que s'han anunciat al segment local, i un túnel encaminat no transporta cap d'aquests anuncis. Per això un servidor pot ser perfectament accessible mentre la finestra davant de l'usuari roman buida. Una ruta UNC amb nom no depèn gens de la detecció, i la solució és fer que el nom resolgui i que el port respongui. La finestra buida és un símptoma de la capa equivocada, no d'un recurs compartit trencat.

Detectar no és el mateix que poder arribar

Windows descobreix equips propers mitjançant protocols pensats per a un domini de difusió i després presenta el que ha trobat com una llista de comoditat. Res d'aquesta llista no cal per accedir a fitxers per SMB. Un client que coneix el nom del servidor i arriba a TCP 445 obrirà el recurs, aparegui o no la màquina algun cop a Xarxa.

Les dues capes fallen per separat, i per això "no ho veig" i "no puc obrir-ho" mereixen proves diferents. Mirar la llista informa sobre la detecció; obrir la ruta informa sobre el servei.

Anomeneu el servidor abans d'assignar el recurs

Publiqueu el servidor de fitxers al DNS amb l'adreça que té a l'altre costat i apunteu l'emplaçament del client a un resolutor que pugui respondre per aquesta zona. Un nom complet evita dependre d'una llista local de sufixos de cerca, que és la raó habitual que un nom curt funcioni en un emplaçament i falli en un altre.

Si l'entorn fa servir Active Directory, la resolució de noms també forma part de l'autenticació: el client ha d'arribar a un controlador de domini per a Kerberos, i un rellotge massa desfasat farà fallar l'intercanvi de tiquets. Això és un problema diferent de l'accessibilitat SMB i sembla un error de credencials. Probeu el controlador de domini abans de tornar a escriure la contrasenya.

Encaminar i filtrar en tots dos sentits

Un túnel d'emplaçament a emplaçament necessita el prefix remot a la taula de rutes local i el prefix local a la remota, i el tallafoc de cada costat ha de permetre el trànsit que arriba. Una configuració unilateral produeix una connexió que s'obre i mai no respon, cosa que els usuaris descriuen com que el recurs va lent. Reviseu primer els comptadors del mateix túnel. Si els paquets surten i no torna res, busqueu la ruta de retorn o el filtre remot.

Amb WireGuard, les IP permeses del parell i les rutes del sistema operatiu han de concordar amb aquest disseny. El túnel transporta paquets; no proporciona registres DNS ni permisos de recurs compartit en cap dels dos costats.

Baseu la regla de tallafoc a la xarxa d'origen real que es connectarà i anoteu l'excepció. Si el disseny tradueix adreces en algun punt del camí, la regla ha d'usar l'origen traduït, i l'adreça original del client ja no es veu als registres.

Autentiqueu-vos i després assigneu la unitat

Baixeu per les capes amb ordres en lloc de amb la finestra de l'Explorador:

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

La segona ordre demostra la ruta TCP, no el dret a llegir res. La tercera és on s'exerceixen l'autenticació i l'autorització, i una fallada allà us hauria de portar als permisos del recurs i del sistema de fitxers, no de tornada a l'encaminador.

Manteniu intactes la signatura SMB i la política d'autenticació existent. No cal reactivar SMB1 ni reenviar difusions de detecció pel túnel per a una ruta explícita, i TCP 445 ha de quedar-se a la ruta privada i no en un reenviament exposat a internet. Doneu als usuaris un accés directe gestionat o una unitat assignada al nom aprovat, i la pàgina Xarxa buida deixa d'importar.