Unità mappata su una VPN tra sedi: DNS, SMB e il percorso UNC

La pagina Rete di Esplora file mostra i dispositivi che si sono annunciati nel segmento locale, e un tunnel instradato non trasporta nessuno di questi annunci. Per questo un server può essere perfettamente raggiungibile mentre la finestra davanti all'utente resta vuota. Un percorso UNC con nome non dipende affatto dall'individuazione, e la soluzione è far risolvere il nome e far rispondere la porta. La finestra vuota è un sintomo dello strato sbagliato, non di una condivisione rotta.

Individuare non è la stessa cosa che raggiungere

Windows individua le macchine vicine tramite protocolli pensati per un dominio di broadcast e poi presenta ciò che ha trovato come un elenco di comodo. Nulla di quell'elenco serve per l'accesso ai file via SMB. Un client che conosce il nome del server e raggiunge TCP 445 aprirà la condivisione, che la macchina compaia o meno in Rete.

I due strati falliscono in modo indipendente, perciò "non lo vedo" e "non riesco ad aprirlo" meritano prove diverse. Guardare l'elenco dice qualcosa sull'individuazione; aprire il percorso dice qualcosa sul servizio.

Assegnate un nome al server prima di mappare la condivisione

Pubblicate il file server nel DNS con l'indirizzo che ha dall'altra parte e indirizzate la sede del client verso un resolver che sappia rispondere per quella zona. Un nome completo evita di dipendere da un elenco locale di suffissi di ricerca, che è la ragione abituale per cui un nome breve funziona in una sede e fallisce in un'altra.

Se l'ambiente usa Active Directory, la risoluzione dei nomi fa parte anche dell'autenticazione: il client deve raggiungere un controller di dominio per Kerberos, e un orologio troppo fuori tempo farà fallire lo scambio di ticket. È un problema diverso dalla raggiungibilità SMB e sembra un errore di credenziali. Provate il controller di dominio prima di riscrivere la password.

Instradare e filtrare in entrambe le direzioni

Un tunnel tra sedi richiede il prefisso remoto nella tabella di routing locale e il prefisso locale in quella remota, e il firewall su ciascun lato deve consentire il traffico in arrivo. Una configurazione unidirezionale produce una connessione che si apre e non risponde mai, cosa che gli utenti descrivono come una condivisione lenta. Controllate prima i contatori del tunnel stesso. Se i pacchetti escono e non torna nulla, cercate la rotta di ritorno o il filtro remoto.

Con WireGuard gli IP consentiti del peer e le rotte del sistema operativo devono concordare con quel progetto. Il tunnel trasporta pacchetti; non fornisce record DNS né autorizzazioni di condivisione su nessuno dei due lati.

Basate la regola del firewall sulla rete di origine reale che si collegherà e annotate l'eccezione. Se il progetto traduce indirizzi da qualche parte lungo il percorso, la regola deve usare l'origine tradotta, e l'indirizzo originale del client non è più visibile nei log.

Autenticatevi, poi mappate l'unità

Scendete gli strati con i comandi invece che con la finestra di Esplora file:

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

Il secondo comando dimostra il percorso TCP, non il diritto di leggere qualcosa. Il terzo è dove si esercitano autenticazione e autorizzazione, e un errore lì dovrebbe mandarvi alle autorizzazioni della condivisione e del file system, non di nuovo al router.

Mantenete intatti la firma SMB e la politica di autenticazione esistente. Riattivare SMB1 o inoltrare i broadcast di individuazione attraverso il tunnel non serve per un percorso esplicito, e TCP 445 deve restare sul percorso privato e non su un inoltro esposto a internet. Date agli utenti un collegamento gestito o un'unità mappata al nome approvato, e la pagina Rete vuota smette di contare.