Os recursos compartidos de rede non aparecen nunha VPN? O descubrimento detense

O recurso compartido ábrese cando escribes a súa ruta, e o explorador de rede non mostra nada. Esa combinación é habitual por un túnel e normalmente non é unha avaría. O descubrimento pregunta ao segmento local; a accesibilidade pregunta a un só equipo. Un túnel encamiñado transporta o segundo e non o primeiro.

O descubrimento e a accesibilidade son distintos

Unha lista de exploración prodúcena protocolos que anuncian servizos a un segmento local e escoitan eses anuncios. Abrir un recurso compartido polo nome é unha conexión directa a un só equipo. O primeiro necesita un dominio de difusión ou multidifusión; o segundo necesita unha ruta e un porto.

Por un túnel, o segundo pode funcionar perfectamente mentres o primeiro devolve unha xanela baleira. Tratar a xanela baleira como a avaría lévao a buscar un túnel roto que está facendo o seu traballo.

Por que a lista de exploración segue baleira

Windows retirou o servizo Computer Browser e desactivou SMB versión 1 de forma predeterminada, o que eliminou a maquinaria detrás do antigo Entorno de rede. Os substitutos como WS-Discovery, SSDP e DNS multidifusión diríxense a grupos de difusión ou multidifusión que só existen nunha ligazón local. Un túnel punto a punto non ten esa ligazón, e os encamiñadores non reenvían eses grupos de forma predeterminada. Todos os equipos poden ser accesibles e a lista pode seguir baleira.

Algúns programas engaden o seu propio asistente de descubrimento. Cando ese asistente funciona, é unha función do programa, non unha propiedade do túnel.

Use nomes explícitos e despois confirme o acceso

Unha ruta UNC, unha unidade asignada ou unha conexión do Finder a un enderezo SMB funciona polo túnel en canto o nome se resolve e o porto está aberto. A resolución pode vir de DNS, dun sufixo de busca que proporcione a VPN ou dunha entrada hosts xestionada centralmente. Nun dominio, unha consulta ao directorio pode listar obxectos de equipo, e esa lista adoita ser o substituto máis próximo a unha vista de exploración nunha rede encamiñada. Unha análise de portos de prefixos coñecidos só é aceptable en redes que vostede administra ou para as que está explicitamente autorizado a probar.

Un equipo que responde non promete que o recurso compartido se abra. Un NAS pode ter unha lista de permitidos limitada á súa propia subrede, que rexeita os enderezos do grupo de VPN. A regra de devasas dun servidor de ficheiros pode nomear só a subrede local. A conta que proporcione para o recurso compartido pode ser unha conta local que nunca se creou nese servidor, e conectarse pola VPN non a crea.

Algúns programas corporativos bloquean deliberadamente o tráfico local e o de máquinas virtuais mentres o túnel está activo. Ese acceso ausente é política, e a corrección corresponde ao administrador, non á táboa de rutas do programa.

Unha orde de diagnóstico que paga a pena repetir

Percorra as capas en orde: chegue ao enderezo, resolva o nome, abra o porto 445, autentíquese e despois lea os permisos do recurso compartido. Cada resposta é independente, e adiantarse produce unha conclusión errónea con confianza. Só despois de que todas pasen paga a pena investigar o descubrimento.

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

Deixe unha nota co nome do servidor, a ruta do recurso compartido, o enderezo ao que se resolveu e a conta que funcionou. Se a lista de exploración se enche máis tarde tras reiniciar un servizo, tráteo como unha rareza do descubrimento e non como proba de que a ruta anterior era incorrecta. A nota é o que permite á seguinte persoa saltarse a xanela baleira.