Zdieľanie SMB zlyháva iba cez VPN: podpisovanie alebo kolízia podsietí?

Zdieľanie, ktoré funguje v sieti LAN, môže zlyhať iba cez tunel. Oddeľte odmietnutie podpisu, prekrývajúcu sa podsieť a zastaranú reláciu SMB.

Namapovaná jednotka, ktorá v kancelárii funguje a doma vyprší, sama o sebe neposkytne takmer žiadnu užitočnú informáciu. Tunel zjavne prenáša pakety, inak by sa na server nedostalo nič. Zlyhala jedna z troch vrstiev: meno sa preložilo na nesprávnu adresu, klient odmietol reláciu podpísať, alebo stará relácia prežila spojenie, ktoré ju nieslo. Každá má inú opravu a dve z troch sú na strane klienta.

Tri poruchy nesú tú istú chybu

Písmeno jednotky nehovorí, ktorá vrstva sa pokazila, a text chyby je zvyčajne dosť všeobecný, aby sedel na všetky tri. Oddeľte ich dvoma rýchlymi otázkami: odpovedá server na svojej IP adrese a prijíma port 445 spojenie?

Tie odpovede dajú rozhodovaciu tabuľku namiesto dohadu. Ak IP funguje a meno nie, ukazuje to na preklad mien. Ak obe fungujú a prihlásenie je odmietnuté, ukazuje to na podpisovanie. Ak obe fungujú a čítanie súboru sa po výpadku tunela zasekne, ukazuje to na zastaranú reláciu.

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

Prechádzajte ich v tomto poradí, pretože meno preložené na nesprávny hostiteľ robí každý ďalší test bezvýznamným.

Vyriešte meno, skôr než sa dotknete zdieľania

Ak server odpovedá na svojej adrese a meno zdieľania vyprší, tunel robí svoju prácu a klient hľadá na nesprávnom mieste. Pri vzdialenom prístupe to väčšinou vysvetľujú dve príčiny.

Prvá je prekrytie adries. Keď kancelária používa 192.168.70.0/24 a domáci router prideľuje rovnaký rozsah, meno hostiteľa preložené na 192.168.70.20 môže ukazovať na miestne zariadenie namiesto servera za tunelom. Windows potom môže požiadavku odoslať lokálne, odmietnuť trasu alebo ju preložiť na tlačiareň, ktorá tú adresu náhodou má. Opravou je prečíslovať jednu stranu, nie pridať ďalšiu trasu.

Druhou je rozsah DNS. Adaptér VPN bez interného DNS servera alebo s takým, ktorý je cez tunel nedostupný, necháva krátke mená chodiť na verejný resolver. Prečítajte záznamy DNS adaptéra a pred dotykom zdieľania sa spýtajte priamo na interné meno:

> 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

Ak tento dotaz vráti očakávanú adresu, je preklad mien vyriešený a problém je vyššie v zásobníku.

Prečítajte požiadavku na podpisovanie na oboch stranách

Dostupný server, ktorý odmieta každé prihlásenie, je znakom nesúladu pravidiel, nie poruchy siete. Windows môže vyžadovať podpisovanie SMB na klientovi a server alebo NAS, ktorý nepodpisuje, nemôže reláciu dokončiť, nech je tunel akokoľvek zdravý.

Nastavenie klienta môžete prečítať bez hľadania v editore pravidiel:

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

Zodpovedajúca hodnota na strane servera je v konfigurácii SMB servera a obe sa musia zhodovať. V jednom nahlásenom prípade mal klient požiadavku zapnutú miestnymi pravidlami, zatiaľ čo server vôbec nepodpisoval; vypnutie a spustenie gpupdate /force zdieľanie okamžite obnovilo. Je to diagnostický krok na potvrdenie príčiny, nie trvalá oprava.

Uprednostnite zapnutie podpisovania na oboch stranách, kde to server podporuje. Zmena bezpečnostného nastavenia, aby zdieľanie fungovalo, by mala byť zaznamenaná s predchádzajúcou hodnotou a dôvodom, aby ju nikto nemusel znovu objavovať pri ďalšom audite.

Vymažte zastaranú reláciu, skôr než začnete ladiť časovače

Zdieľanie, ktoré sa zasekne až po páde a opätovnom pripojení VPN, zvyčajne drží reláciu, ktorú server už zahodil. Server zatvára nečinné relácie SMB podľa časovača Autodisconnect v LanmanServer\Parameters, štandardne 15 minút, zatiaľ čo klient má svoj vlastný SessTimeout v LanmanWorkstation\Parameters. Výpadok dlhší ako tieto hodnoty nechá každú stranu s inou predstavou o relácii.

Zopakujte to v pevnom poradí, aby výsledok niečo znamenal: pripojte tunel, otvorte zdieľanie, na dve minúty tunel prerušte, obnovte ho a potom skúste prečítať súbor. Ak sa pripojenie spamätá samo, časovačov si nevšímajte. Ak visí, kým znova nepripojíte, pripojte zdieľanie znova potom, čo tunel beží, namiesto toho, aby ste ho pripájali predtým, a skontrolujte, či pomocník pripojenia skúša znova.

Zvyšovanie časových limitov je rozumný posledný krok pri nestabilnom spoji, ale lieči príznak. Klient, ktorý čaká dlhšie na reláciu, na ktorú server zabudol, stále čaká.

Skončite prečítaním jedného súboru cez pripojenie a potom ešte raz prerušením a obnovením tunela. Tento akceptačný test pokrýva všetky tri vrstvy naraz a je jediný, ktorý zodpovedá tomu, čo používateľ skutočne robí.

Súvisiace články