El recurs compartit SMB falla només per VPN: signatura o conflicte de subxarxa?
Un recurs que funciona a la LAN pot fallar només a través del túnel. Separeu un rebuig de signatura, una subxarxa solapada i una sessió SMB antiga.
Una unitat assignada que funciona a l’oficina i caduca a casa no us dona gairebé cap informació útil per si sola. El túnel transporta clarament paquets, o no arribaria res al servidor. El que va fallar és en una de tres capes: el nom es va resoldre a l’adreça incorrecta, el client es va negar a signar la sessió, o una sessió antiga va sobreviure a la connexió que la portava. Cadascuna té una reparació diferent, i dues de les tres són al costat del client.
Tres fallades porten el mateix error
La lletra d’unitat no diu quina capa es va trencar, i el text de l’error sol ser prou genèric per encaixar en les tres. Separeu-les amb dues preguntes ràpides: respon el servidor a la seva adreça IP, i accepta el port 445 una connexió?
Aquestes respostes produeixen una taula de decisió en lloc d’una conjectura. Si la IP funciona i el nom no, apunta a la resolució de noms. Si tots dos funcionen i es rebutja l’inici de sessió, apunta a la signatura. Si tots dos funcionen i una lectura de fitxer es penja després d’una caiguda del túnel, apunta a una sessió antiga.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
Recorreu-les en aquest ordre, perquè un nom que es resol a l’amfitrió incorrecte fa inútil qualsevol prova posterior.
Resoleu el nom abans de tocar el recurs
Si el servidor respon a la seva adreça i el nom del recurs caduca, el túnel fa la seva feina i el client busca al lloc equivocat. En accés remot, dues causes expliquen la major part d’això.
La primera és un solapament d’adreces. Quan l’oficina fa servir 192.168.70.0/24 i el router de casa entrega el mateix rang, un nom d’amfitrió que es resol a 192.168.70.20 pot apuntar a un dispositiu local en lloc del servidor darrere del túnel. Windows pot llavors enviar la petició localment, rebutjar la ruta o resoldre-la a una impressora que casualment té aquesta adreça. La reparació és renumerar un costat, no afegir una altra ruta.
La segona és l’abast de DNS. Un adaptador VPN sense servidor DNS intern, o amb un d’inabastable a través del túnel, deixa que els noms curts vagin a un resolutor públic. Llegiu les entrades DNS de l’adaptador i consulteu el nom intern directament abans de tocar el recurs:
> 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.15Si aquesta consulta retorna l’adreça esperada, la resolució de noms està aclarida i el problema és més amunt a la pila.
Llegiu el requisit de signatura als dos extrems
Un servidor accessible que rebutja tots els inicis de sessió és el senyal d’un desajust de política i no d’una fallada de xarxa. Windows pot exigir la signatura SMB al client, i un servidor o NAS que no signa no pot completar la sessió, per sa que estigui el túnel.
Podeu llegir la configuració del client sense recórrer l’editor de polítiques:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionEl valor corresponent al servidor és a la configuració SMB del servidor, i els dos han de coincidir. En un cas reportat, el client tenia el requisit activat per política local mentre el servidor no signava gens; desactivar-lo i executar gpupdate /force va restaurar el recurs immediatament. Aquest és un pas de diagnòstic per confirmar la causa, no una solució permanent.
Preferiu activar la signatura als dos extrems on el servidor ho admet. Canviar un paràmetre de seguretat perquè funcioni un recurs s’ha de registrar amb el valor anterior i el motiu, perquè ningú no l’hagi de redescobrir a la propera auditoria.
Netegeu la sessió antiga abans d’ajustar els temporitzadors
Un recurs que només es penja després que la VPN caigui i es reconnecti sol mantenir una sessió que el servidor ja ha descartat. El servidor tanca les sessions SMB inactives amb el temporitzador Autodisconnect a LanmanServer\Parameters, que per defecte són 15 minuts, mentre el client té el seu propi SessTimeout a LanmanWorkstation\Parameters. Una caiguda més llarga que aquests valors deixa cada extrem amb una idea diferent de la sessió.
Reproduïu-ho en un ordre fix perquè el resultat signifiqui alguna cosa: connecteu el túnel, obriu el recurs, talleu el túnel durant dos minuts, restabliu-lo i després intenteu llegir un fitxer. Si el muntatge es recupera sol, deixeu els temporitzadors en pau. Si es penja fins que torneu a muntar, reconnecteu el recurs un cop aixecat el túnel en lloc de muntar-lo abans que existeixi, i comproveu si l’auxiliar de muntatge reintenta.
Apujar els temps d’espera és un últim pas raonable per a un enllaç inestable, però tracta el símptoma. Un client que espera més temps una sessió que el servidor ha oblidat encara espera.
Acabeu llegint un fitxer a través del muntatge i després tallant i restablint el túnel una vegada més. Aquesta prova d’acceptació cobreix les tres capes alhora, i és l’única que coincideix amb el que fa realment l’usuari.