Partajarea SMB eșuează doar prin VPN: semnătură sau conflict de subrețea?

O partajare care funcționează în LAN poate eșua doar prin tunel. Separați un refuz de semnătură, o subrețea suprapusă și o sesiune SMB învechită.

O unitate mapată care funcționează la birou și expiră acasă nu vă spune aproape nimic util de la sine. Tunelul transportă clar pachete, altfel nimic nu ar ajunge la server. Ce a eșuat se află într-unul din trei straturi: numele s-a rezolvat la adresa greșită, clientul a refuzat să semneze sesiunea sau o sesiune veche a supraviețuit conexiunii care o purta. Fiecare are o reparație diferită, iar două din trei sunt pe partea clientului.

Trei defecțiuni poartă aceeași eroare

Litera unității nu spune care strat s-a rupt, iar textul erorii este de obicei suficient de generic pentru toate trei. Separați-le cu două întrebări rapide: răspunde serverul la adresa sa IP și acceptă portul 445 o conexiune?

Acele răspunsuri produc un tabel de decizie în loc de o presupunere. Dacă IP-ul funcționează și numele nu, indică rezolvarea. Dacă ambele funcționează și autentificarea este refuzată, indică semnătura. Dacă ambele funcționează și o citire de fișier se blochează după o cădere a tunelului, indică o sesiune învechită.

SymptomLayer to inspect
IP works, hostname times outDNS or subnet overlap
TCP 445 opens, logon refusedSMB signing policy
Hangs after reconnectSession state and timers

Parcurgeți-le în această ordine, pentru că un nume care se rezolvă la gazda greșită face fiecare test ulterior lipsit de sens.

Rezolvați numele înainte de a atinge partajarea

Dacă serverul răspunde la adresa sa și numele partajării expiră, tunelul își face treaba, iar clientul caută în locul greșit. În accesul la distanță, două cauze explică cea mai mare parte.

Prima este suprapunerea de adrese. Când biroul folosește 192.168.70.0/24, iar routerul de acasă distribuie același interval, un nume de gazdă care se rezolvă la 192.168.70.20 poate indica un dispozitiv local în locul serverului din spatele tunelului. Windows poate trimite atunci cererea local, poate refuza ruta sau poate rezolva către o imprimantă care are întâmplător acea adresă. Reparația este renumerotarea unei părți, nu adăugarea unei alte rute.

A doua este sfera DNS. Un adaptor VPN fără server DNS intern, sau cu unul inaccesibil prin tunel, lasă numele scurte să meargă la un resolver public. Citiți intrările DNS ale adaptorului și interogați direct numele intern înainte de a atinge partajarea:

> 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

Dacă acea interogare returnează adresa așteptată, rezolvarea este lămurită, iar problema este mai sus în stivă.

Citiți cerința de semnătură la ambele capete

Un server accesibil care refuză fiecare autentificare este semnul unei nepotriviri de politică, nu al unei defecțiuni de rețea. Windows poate cere semnătura SMB pe client, iar un server sau NAS care nu semnează nu poate finaliza sesiunea, oricât de sănătos ar fi tunelul.

Puteți citi setarea clientului fără să căutați în editorul de politici:

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

Valoarea corespunzătoare din partea serverului se află în configurația SMB a serverului, iar cele două trebuie să fie de acord. Într-un caz raportat, clientul avea cerința activată prin politică locală, în timp ce serverul nu semna deloc; dezactivarea ei plus rularea gpupdate /force a restaurat partajarea imediat. Acesta este un pas de diagnostic pentru a confirma cauza, nu o soluție permanentă.

Preferați să activați semnătura la ambele capete acolo unde serverul o acceptă. Modificarea unei setări de securitate pentru ca o partajare să funcționeze trebuie consemnată cu valoarea anterioară și motivul, ca nimeni să nu o redescopere la următorul audit.

Curățați sesiunea învechită înainte de a regla cronometrele

O partajare care se blochează doar după ce VPN-ul cade și se reconectează ține de obicei o sesiune pe care serverul a aruncat-o deja. Serverul închide sesiunile SMB inactive după cronometrul Autodisconnect din LanmanServer\Parameters, care implicit este de 15 minute, în timp ce clientul are propriul SessTimeout din LanmanWorkstation\Parameters. O cădere mai lungă decât aceste valori lasă fiecare capăt cu o idee diferită despre sesiune.

Reproduceți-o într-o ordine fixă, ca rezultatul să însemne ceva: conectați tunelul, deschideți partajarea, întrerupeți tunelul două minute, restabiliți-l, apoi încercați să citiți un fișier. Dacă montarea se recuperează singură, lăsați cronometrele în pace. Dacă se blochează până remontați, reconectați partajarea după ce tunelul este sus în loc să o montați înainte de a exista, și verificați dacă ajutorul de montare reîncearcă.

Creșterea timpilor limită este un ultim pas rezonabil pentru o legătură instabilă, dar tratează simptomul. Un client care așteaptă mai mult o sesiune pe care serverul a uitat-o așteaptă în continuare.

Încheiați citind un fișier prin montare, apoi întrerupând și restabilind tunelul încă o dată. Acel test de acceptare acoperă toate cele trei straturi deodată și este singurul care corespunde cu ceea ce face utilizatorul de fapt.

Articole similare