Unidad asignada a través de una VPN de sitio: DNS, SMB y la ruta UNC

La página Red del Explorador muestra los dispositivos que se anunciaron en el segmento local, y un túnel enrutado no transporta ninguno de esos anuncios. Por eso un servidor puede ser perfectamente accesible mientras la ventana frente al usuario permanece vacía. Una ruta UNC con nombre no depende en absoluto de la detección, y la solución es hacer que el nombre resuelva y que el puerto responda. La ventana vacía es un síntoma de la capa equivocada, no de un recurso compartido roto.

Detectar no es lo mismo que poder llegar

Windows descubre equipos cercanos mediante protocolos pensados para un dominio de difusión y luego presenta lo encontrado como una lista de comodidad. Nada de esa lista hace falta para acceder a archivos por SMB. Un cliente que conoce el nombre del servidor y alcanza TCP 445 abrirá el recurso, aparezca o no la máquina alguna vez en Red.

Las dos capas fallan por separado, y por eso "no lo veo" y "no puedo abrirlo" merecen pruebas distintas. Mirar la lista informa sobre la detección; abrir la ruta informa sobre el servicio.

Nombre el servidor antes de asignar el recurso

Publique el servidor de archivos en DNS con la dirección que tiene al otro lado y apunte el sitio del cliente a un resolutor que pueda responder por esa zona. Un nombre completo evita depender de una lista local de sufijos de búsqueda, que es la razón habitual de que un nombre corto funcione en un sitio y falle en otro.

Si el entorno usa Active Directory, la resolución de nombres también forma parte de la autenticación: el cliente debe llegar a un controlador de dominio para Kerberos, y un reloj demasiado desfasado hará fallar el intercambio de tickets. Eso es un problema distinto de la accesibilidad SMB y se parece a un error de credenciales. Pruebe el controlador de dominio antes de volver a escribir la contraseña.

Enrutar y filtrar en ambos sentidos

Un túnel de sitio a sitio necesita el prefijo remoto en la tabla de rutas local y el prefijo local en la remota, y el cortafuegos de cada lado debe permitir el tráfico que llega. Una configuración unilateral produce una conexión que se abre y nunca responde, lo que los usuarios describen como que el recurso va lento. Revise primero los contadores del propio túnel. Si los paquetes salen y no vuelve nada, busque la ruta de retorno o el filtro remoto.

Con WireGuard, las IP permitidas del par y las rutas del sistema operativo deben concordar con ese diseño. El túnel transporta paquetes; no proporciona registros DNS ni permisos de recurso compartido en ninguno de los dos lados.

Base la regla de cortafuegos en la red de origen real que se va a conectar y anote la excepción. Si el diseño traduce direcciones en algún punto del camino, la regla debe usar el origen traducido, y la dirección original del cliente ya no se ve en los registros.

Autentíquese y luego asigne la unidad

Baje por las capas con comandos en lugar de con la ventana del 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

El segundo comando demuestra la ruta TCP, no el derecho a leer nada. El tercero es donde se ejercen la autenticación y la autorización, y un fallo allí debería llevarle a los permisos del recurso y del sistema de archivos, no de vuelta al enrutador.

Mantenga intactos la firma SMB y la política de autenticación existente. No hace falta reactivar SMB1 ni reenviar difusiones de detección por el túnel para una ruta explícita, y TCP 445 debe quedarse en la ruta privada y no en un reenvío expuesto a internet. Dé a los usuarios un acceso directo administrado o una unidad asignada al nombre aprobado, y la página Red vacía deja de importar.