Le condivisioni di rete non compaiono su una VPN? L’individuazione si ferma

La condivisione si apre quando si digita il suo percorso, e il browser di rete non mostra nulla. Questa combinazione è comune su un tunnel e di solito non è un guasto. L’individuazione interroga il segmento locale; la raggiungibilità interroga un solo host. Un tunnel instradato trasporta la seconda e non la prima.

Individuazione e raggiungibilità sono separate

Un elenco di esplorazione è prodotto da protocolli che annunciano servizi a un segmento locale e ascoltano quegli annunci. Aprire una condivisione per nome è una connessione diretta a un solo host. Il primo richiede un dominio di broadcast o multicast; il secondo richiede una rotta e una porta.

Su un tunnel il secondo può funzionare perfettamente mentre il primo restituisce una finestra vuota. Considerare la finestra vuota come il guasto porta a cercare un tunnel rotto che sta facendo il suo lavoro.

Perché l’elenco di esplorazione resta vuoto

Windows ha ritirato il servizio Computer Browser e disattivato SMB versione 1 per impostazione predefinita, il che ha rimosso il meccanismo dietro il vecchio Network Neighborhood. Sostituti come WS-Discovery, SSDP e DNS multicast indirizzano gruppi broadcast o multicast che esistono solo su un collegamento locale. Un tunnel punto a punto non ha tale collegamento, e i router non inoltrano quei gruppi per impostazione predefinita. Ogni host può essere raggiungibile e l’elenco può comunque restare vuoto.

Alcuni programmi aggiungono un proprio assistente di individuazione. Quando quell’assistente funziona, è una funzione del programma, non una proprietà del tunnel.

Usate nomi espliciti, poi confermate l’accesso

Un percorso UNC, un’unità mappata o una connessione del Finder a un indirizzo SMB funziona sul tunnel non appena il nome si risolve e la porta è aperta. La risoluzione può venire dal DNS, da un suffisso di ricerca fornito dalla VPN o da una voce hosts gestita centralmente. In un dominio, una query di directory può elencare oggetti computer, e quell’elenco è di solito il sostituto più vicino a una vista di esplorazione su una rete instradata. Una scansione delle porte di prefissi noti è accettabile solo su reti che gestite o che siete esplicitamente autorizzati a testare.

Un host che risponde non promette che la condivisione si apra. Un NAS può avere una lista di autorizzati limitata alla propria sottorete, che rifiuta gli indirizzi del pool VPN. La regola del firewall di un file server può nominare solo la sottorete locale. L’account che fornite per la condivisione può essere un account locale che non è mai stato creato su quel server, e connettersi tramite la VPN non lo crea.

Alcuni programmi aziendali bloccano deliberatamente il traffico locale e quello delle macchine virtuali mentre il tunnel è attivo. Quell’accesso mancante è una politica, e la correzione spetta all’amministratore, non alla tabella di routing del programma.

Un ordine diagnostico che vale la pena ripetere

Percorrete i livelli in ordine: raggiungere l’indirizzo, risolvere il nome, aprire la porta 445, autenticarsi, poi leggere le autorizzazioni della condivisione. Ogni risposta è separata, e saltare avanti produce una conclusione sbagliata e sicura di sé. Solo dopo che tutte sono superate vale la pena indagare sull’individuazione.

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

Lasciate una nota con il nome del server, il percorso della condivisione, l’indirizzo a cui si è risolta e l’account che ha funzionato. Se l’elenco di esplorazione in seguito si popola dopo un riavvio del servizio, trattatelo come una stranezza dell’individuazione e non come prova che la rotta precedente fosse sbagliata. La nota è ciò che permette alla persona successiva di saltare la finestra vuota.