Els recursos compartits de xarxa no es mostren en una VPN? El descobriment s’atura

El recurs compartit s’obre quan escriviu la seva ruta, i el navegador de xarxa no mostra res. Aquesta combinació és habitual per un túnel i normalment no és cap avaria. El descobriment pregunta al segment local; l’abastabilitat pregunta a un sol amfitrió. Un túnel enrutat porta el segon i no el primer.

El descobriment i l’abastabilitat són separats

La llista de navegació la produeixen protocols que anuncien serveis a un segment local i escolten aquests anuncis. Obrir un recurs compartit pel nom és una connexió directa a un sol amfitrió. El primer necessita un domini de difusió o multidifusió; el segon necessita una ruta i un port.

Per un túnel, el segon pot funcionar perfectament mentre el primer retorna una finestra buida. Si tracteu la finestra buida com l’avaria, anireu a buscar un túnel trencat que està fent la seva feina.

Per què la llista de navegació queda buida

Windows va retirar el servei Computer Browser i va desactivar SMB versió 1 per defecte, cosa que va eliminar la maquinària darrere de l’antic Network Neighborhood. Els substituts com WS-Discovery, SSDP i DNS multidifusió adrecen grups de difusió o multidifusió que només existeixen en un enllaç local. Un túnel punt a punt no té aquest enllaç, i els encaminadors no reenvien aquests grups per defecte. Tots els amfitrions poden ser abastables i la llista pot quedar buida.

Alguns programes afegeixen el seu propi assistent de descobriment. Quan aquest assistent funciona, és una característica del programa, no una propietat del túnel.

Feu servir noms explícits i després confirmeu l’accés

Una ruta UNC, una unitat assignada o una connexió del Finder a una adreça SMB funciona pel túnel un cop el nom es resol i el port és obert. La resolució pot venir del DNS, d’un sufix de cerca que proporcioni la VPN o d’una entrada hosts gestionada centralment. En un domini, una consulta al directori pot llistar objectes d’ordinador, i aquesta llista sol ser el substitut més proper a una vista de navegació en una xarxa enrutada. Un escaneig de ports de prefixos coneguts només és acceptable en xarxes que gestioneu o per a les quals esteu explícitament autoritzats a provar.

Un amfitrió que respon no promet que el recurs compartit s’obri. Un NAS pot tenir una llista d’autoritzacions limitada a la seva pròpia subxarxa, que rebutja les adreces del pool de la VPN. La regla de tallafoc d’un servidor de fitxers pot anomenar només la subxarxa local. El compte que proporcioneu per al recurs compartit pot ser un compte local que mai no es va crear en aquell servidor, i connectar-vos per la VPN no el crea.

Alguns programes corporatius bloquegen deliberadament el trànsit local i de màquines virtuals mentre el túnel és actiu. Aquest accés absent és política, i la solució pertoca a l’administrador, no a la taula d’encaminament del programa.

Un ordre de diagnòstic que val la pena repetir

Recorreu les capes en ordre: arribeu a l’adreça, resoleu el nom, obriu el port 445, autentiqueu-vos i després llegiu els permisos del recurs compartit. Cada resposta és separada, i saltar endavant produeix una conclusió errònia amb confiança. Només després que totes passin val la pena investigar el descobriment.

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

Deixeu una nota amb el nom del servidor, la ruta del recurs compartit, l’adreça a què es va resoldre i el compte que va funcionar. Si la llista de navegació s’omple més tard després de reiniciar un servei, tracteu-ho com una raresa del descobriment i no com a prova que la ruta anterior fos incorrecta. La nota és el que permet a la persona següent saltar-se la finestra buida.