¿Los recursos compartidos de red no aparecen en una VPN? El descubrimiento se detiene

El recurso compartido se abre cuando escribe su ruta, y el explorador de red no muestra nada. Esa combinación es habitual por un túnel y normalmente no es una avería. El descubrimiento pregunta al segmento local; la accesibilidad pregunta a un solo equipo. Un túnel enrutado transporta lo segundo y no lo primero.

El descubrimiento y la accesibilidad son cosas distintas

Una lista de exploración la producen protocolos que anuncian servicios a un segmento local y escuchan esos anuncios. Abrir un recurso compartido por nombre es una conexión directa a un solo equipo. Lo primero necesita un dominio de difusión o multidifusión; lo segundo necesita una ruta y un puerto.

Por un túnel, lo segundo puede funcionar a la perfección mientras lo primero devuelve una ventana vacía. Tratar la ventana vacía como la avería le lleva a buscar un túnel roto que está haciendo su trabajo.

Por qué la lista de exploración sigue vacía

Windows retiró el servicio Computer Browser y desactivó SMB versión 1 de forma predeterminada, lo que eliminó la maquinaria detrás del antiguo Entorno de red. Los reemplazos como WS-Discovery, SSDP y DNS multidifusión se dirigen a grupos de difusión o multidifusión que solo existen en un enlace local. Un túnel punto a punto no tiene ese enlace, y los enrutadores no reenvían esos grupos de forma predeterminada. Todos los equipos pueden ser accesibles y la lista puede seguir vacía.

Algunos programas añaden su propio asistente de descubrimiento. Cuando ese asistente funciona, es una función del programa, no una propiedad del túnel.

Use nombres explícitos y luego confirme el acceso

Una ruta UNC, una unidad asignada o una conexión del Finder a una dirección SMB funciona por el túnel en cuanto el nombre se resuelve y el puerto está abierto. La resolución puede venir de DNS, de un sufijo de búsqueda que proporcione la VPN o de una entrada hosts administrada centralmente. En un dominio, una consulta al directorio puede listar objetos de equipo, y esa lista suele ser el sustituto más cercano a una vista de exploración en una red enrutada. Un escaneo de puertos de prefijos conocidos solo es aceptable en redes que usted administra o para las que está explícitamente autorizado a probar.

Un equipo que responde no promete que el recurso compartido se abra. Un NAS puede tener una lista de permitidos limitada a su propia subred, que rechaza las direcciones del grupo de VPN. La regla de firewall de un servidor de archivos puede nombrar solo la subred local. La cuenta que proporcione para el recurso compartido puede ser una cuenta local que nunca se creó en ese servidor, y conectarse por la VPN no la crea.

Algunos programas corporativos bloquean deliberadamente el tráfico local y el de máquinas virtuales mientras el túnel está activo. Ese acceso ausente es política, y la corrección corresponde al administrador, no a la tabla de rutas del programa.

Un orden de diagnóstico que vale la pena repetir

Recorra las capas en orden: llegue a la dirección, resuelva el nombre, abra el puerto 445, autentíquese y luego lea los permisos del recurso compartido. Cada respuesta es independiente, y adelantarse produce una conclusión errónea con confianza. Solo después de que todas pasen vale la pena investigar el descubrimiento.

nslookup fileserver.example.com
nc -vz fileserver.example.com 445
smbclient -L //fileserver.example.com -U EXAMPLE/jdoe

Deje una nota con el nombre del servidor, la ruta del recurso compartido, la dirección a la que se resolvió y la cuenta que funcionó. Si la lista de exploración se llena más tarde tras reiniciar un servicio, trátelo como una rareza del descubrimiento y no como prueba de que la ruta anterior era incorrecta. La nota es lo que permite a la siguiente persona saltarse la ventana vacía.