Condivisione SMB in errore solo via VPN: firma o conflitto di subnet?

Un’unità mappata che funziona in ufficio e va in timeout a casa non ti dice quasi nulla di utile da sola. Il tunnel sta chiaramente trasportando pacchetti, altrimenti nulla raggiungerebbe il server. Ciò che è fallito è uno di tre livelli: il nome è stato risolto all’indirizzo sbagliato, il client si è rifiutato di firmare la sessione, oppure una vecchia sessione è sopravvissuta alla connessione che la trasportava. Ognuno ha una riparazione diversa, e due dei tre sono lato client.

Tre guasti indossano lo stesso errore

La lettera di unità non dice quale livello si è rotto, e il testo dell’errore è di solito abbastanza generico da adattarsi a tutti e tre. Separali con due domande rapide: il server risponde per indirizzo IP, e la porta 445 accetta una connessione?

Quelle risposte producono una tabella di decisione anziché una supposizione. Se l’IP funziona e il nome no, il problema è la risoluzione. Se entrambi funzionano e l’accesso viene rifiutato, il problema è la firma. Se entrambi funzionano e una lettura di file si blocca dopo un’interruzione del tunnel, il problema è una sessione obsoleta.

Affrontali in quest’ordine, perché un nome che si risolve all’host sbagliato rende inutile ogni test successivo.

Risolvi il nome prima di toccare la condivisione

Se il server risponde al suo indirizzo e il nome della condivisione va in timeout, il tunnel sta facendo il suo lavoro e il client sta guardando nel posto sbagliato. Nell’accesso remoto, due cause spiegano la maggior parte di questo.

La prima è una sovrapposizione di indirizzi. Quando l’ufficio usa 192.168.70.0/24 e il router di casa assegna lo stesso intervallo, un nome host che si risolve in 192.168.70.20 può puntare a un dispositivo locale invece che al server dietro il tunnel. Windows può quindi inviare la richiesta in locale, rifiutare la rotta o risolvere verso una stampante che possiede quell’indirizzo. La riparazione è rinumerare un lato, non aggiungere un’altra rotta.

La seconda è l’ambito DNS. Un adattatore VPN senza server DNS interno, o con uno irraggiungibile attraverso il tunnel, lascia che i nomi brevi finiscano a un resolver pubblico. Leggi le voci DNS dell’adattatore e interroga direttamente il nome interno prima di toccare la condivisione:

> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15

Se quella ricerca restituisce l’indirizzo atteso, la risoluzione è chiarita e il problema è più in alto nello stack.

Leggi il requisito di firma su entrambe le estremità

Un server raggiungibile che rifiuta ogni accesso è il segno di un disallineamento di criteri più che di un guasto di rete. Windows può richiedere la firma SMB sul client, e un server o NAS che non firma non può completare la sessione, per quanto il tunnel sia sano.

Puoi leggere l’impostazione del client senza cercare nell’editor dei criteri:

> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection

Il valore corrispondente lato server si trova nella configurazione SMB del server, e i due devono concordare. In un caso segnalato il client aveva il requisito abilitato da criteri locali mentre il server non firmava affatto, e disabilitarlo più eseguire gpupdate /force ha ripristinato subito la condivisione. È un passo diagnostico per confermare la causa, non una correzione permanente.

Preferisci attivare la firma su entrambe le estremità dove il server la supporta. Cambiare un’impostazione di sicurezza per far funzionare una condivisione va registrato con il valore precedente e il motivo, così nessuno deve riscoprirlo al prossimo audit.

Pulisci la sessione obsoleta prima di regolare i timer

Una condivisione che si blocca solo dopo che la VPN cade e si riconnette di solito trattiene una sessione che il server ha già scartato. Il server chiude le sessioni SMB inattive con il timer Autodisconnect sotto LanmanServer\Parameters, che per impostazione predefinita è 15 minuti, mentre il client ha il proprio SessTimeout sotto LanmanWorkstation\Parameters. Un’interruzione più lunga di quei valori lascia ogni estremità con un’idea diversa della sessione.

Riproducilo in un ordine fisso perché il risultato significhi qualcosa: collega il tunnel, apri la condivisione, interrompi il tunnel per due minuti, ripristinalo, poi prova a leggere un file. Se il mount si riprende da solo, lascia stare i timer. Se si blocca finché non rimonti, ricollega la condivisione dopo che il tunnel è attivo invece di montarla prima che esista, e controlla se l’helper di mount riprova.

Alzare i timeout è un ultimo passo ragionevole per un collegamento instabile, ma cura il sintomo. Un client che aspetta più a lungo una sessione che il server ha dimenticato aspetta comunque.

Chiudi leggendo un file attraverso il mount, poi interrompendo e ripristinando il tunnel ancora una volta. Quel test di accettazione copre tutti e tre i livelli insieme, ed è l’unico che corrisponde a ciò che l’utente fa davvero.