Unidade asignada a través dunha VPN de sitio: DNS, SMB e a ruta UNC

A páxina Rede do Explorador mostra os dispositivos que se anunciaron no segmento local, e un túnel encamiñado non transporta ningún deses anuncios. Por iso un servidor pode ser perfectamente accesible mentres a xanela diante do usuario permanece baleira. Unha ruta UNC con nome non depende en absoluto da detección, e a solución é facer que o nome resolva e que o porto responda. A xanela baleira é un síntoma da capa equivocada, non dun recurso compartido roto.

Detectar non é o mesmo que poder chegar

Windows descobre equipos próximos mediante protocolos pensados para un dominio de difusión e despois presenta o atopado como unha lista de comodidade. Nada desa lista fai falta para acceder a ficheiros por SMB. Un cliente que coñece o nome do servidor e acada TCP 445 abrirá o recurso, apareza ou non a máquina algunha vez en Rede.

As dúas capas fallan por separado, e por iso "non o vexo" e "non podo abrirlo" merecen probas distintas. Mirar a lista informa sobre a detección; abrir a ruta informa sobre o servizo.

Nomea o servidor antes de asignar o recurso

Publica o servidor de ficheiros no DNS co enderezo que ten do outro lado e apunta o sitio do cliente a un resolvedor que poida responder por esa zona. Un nome completo evita depender dunha lista local de sufixos de busca, que é a razón habitual de que un nome curto funcione nun sitio e falle noutro.

Se a contorna usa Active Directory, a resolución de nomes tamén forma parte da autenticación: o cliente ten que acadar un controlador de dominio para Kerberos, e un reloxo demasiado desfasado fará fallar o intercambio de tickets. Iso é un problema distinto da accesibilidade SMB e parece un erro de credenciais. Proba o controlador de dominio antes de volver escribir o contrasinal.

Encamiñar e filtrar nos dous sentidos

Un túnel de sitio a sitio necesita o prefixo remoto na táboa de rutas local e o prefixo local na remota, e a devasa de cada lado ten que permitir o tráfico que chega. Unha configuración unilateral produce unha conexión que abre e nunca responde, o que os usuarios describen como que o recurso vai lento. Revisa primeiro os contadores do propio túnel. Se os paquetes saen e non volve nada, busca a ruta de retorno ou o filtro remoto.

Con WireGuard, os IP permitidos do par e as rutas do sistema operativo teñen que concordar con ese deseño. O túnel transporta paquetes; non proporciona rexistros DNS nin permisos de recurso compartido en ningún dos dous lados.

Basea a regra de devasa na rede de orixe real que se vai conectar e anota a excepción. Se o deseño traduce enderezos nalgunha altura do camiño, a regra ten que usar a orixe traducida, e o enderezo orixinal do cliente xa non se ve nos rexistros.

Autentícate e despois asigna a unidade

Baixa polas capas con comandos en lugar de coa xanela do 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

O segundo comando demostra a ruta TCP, non o dereito a ler nada. O terceiro é onde se exercen a autenticación e a autorización, e un fallo alí debería levarte aos permisos do recurso e do sistema de ficheiros, non de volta ao encamiñador.

Mantén intactos a sinatura SMB e a política de autenticación existente. Non fai falta reactivar SMB1 nin reenviar difusións de detección polo túnel para unha ruta explícita, e TCP 445 debe quedar na ruta privada e non nun reenvío exposto a internet. Dálles aos usuarios un acceso directo xestionado ou unha unidade asignada ao nome aprobado, e a páxina Rede baleira deixa de importar.