Ndarja SMB dështon vetëm përmes VPN: problem firmës apo konflikt i nënrrjetit?

Një disk i hartëzuar që funksionon në zyrë dhe skadon në shtëpi nuk ju jep pothuajse asnjë informacion të dobishëm në vetvete. Tuneli po transporton qartë paketa, përndryshe asgjë nuk do të arrinte te serveri. Ajo që dështoi është në një nga tre shtresat: emri u zgjidh në adresën e gabuar, klienti refuzoi të nënshkruante sesionin, ose një sesion i vjetër mbijetoi më shumë se lidhja që e mbante. Secila ka një riparim të ndryshëm, dhe dy nga tre janë në anën e klientit.

Tre dështime mbajnë të njëjtin gabim

Shkronja e diskut nuk tregon se cila shtresë u thye, dhe teksti i gabimit është zakonisht mjaft i përgjithshëm për t’u përshtatur me të tre. Ndajini me dy pyetje të shpejta: a përgjigjet serveri në adresën e tij IP, dhe a pranon porti 445 një lidhje?

Ato përgjigje prodhojnë një tabelë vendimi në vend të një hamendjeje. Nëse IP funksionon dhe emri jo, kjo tregon zgjidhjen e emrave. Nëse të dyja funksionojnë dhe hyrja refuzohet, kjo tregon firmën. Nëse të dyja funksionojnë dhe leximi i një skedari ngec pas një ndërprerjeje të tunelit, kjo tregon një sesion të vjetër.

Përshkoni ato në atë rend, sepse një emër që zgjidhet te hosti i gabuar e bën çdo test të mëvonshëm të pakuptimtë.

Zgjidhni emrin përpara se të prekni ndarjen

Nëse serveri përgjigjet në adresën e tij dhe emri i ndarjes skadon, tuneli po bën punën e tij dhe klienti po kërkon në vendin e gabuar. Në aksesin në distancë, dy shkaqe shpjegojnë pjesën më të madhe të kësaj.

I pari është mbivendosja e adresave. Kur zyra përdor 192.168.70.0/24 dhe ruteri i shtëpisë jep të njëjtin interval, një emër hosti që zgjidhet në 192.168.70.20 mund të tregojë një pajisje lokale në vend të serverit pas tunelit. Windows më pas mund ta dërgojë kërkesën lokalisht, ta refuzojë rrugën ose ta zgjidhë te një printer që ndodh të ketë atë adresë. Riparimi është të rinumërosh njërën anë, jo të shtosh një rrugë tjetër.

I dyti është shtrirja e DNS-së. Një adaptor VPN pa server DNS të brendshëm, ose me një që nuk arrihet përmes tunelit, i lë emrat e shkurtër të shkojnë te një zgjidhës publik. Lexoni hyrjet DNS të adaptorit dhe pyesni drejtpërdrejt emrin e brendshëm përpara se të prekni ndarjen:

> 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

Nëse ai kërkim kthen adresën e pritur, zgjidhja e emrave është sqaruar dhe problemi është më lart në pirg.

Lexoni kërkesën e nënshkrimit në të dy skajet

Një server i arritshëm që refuzon çdo hyrje është shenjë e mospërputhjes së politikave dhe jo e një defekti rrjeti. Windows mund të kërkojë nënshkrim SMB në klient, dhe një server ose NAS që nuk nënshkruan nuk mund ta përfundojë sesionin, sado i shëndetshëm të jetë tuneli.

Mund ta lexoni cilësimin e klientit pa kërkuar në redaktorin e politikave:

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

Vlera përkatëse në anën e serverit është në konfigurimin SMB të serverit, dhe të dyja duhet të përputhen. Në një rast të raportuar, klienti e kishte kërkesën të aktivizuar me politikë lokale, ndërsa serveri nuk nënshkruante fare; çaktivizimi i saj dhe ekzekutimi i gpupdate /force e riktheu ndarjen menjëherë. Ky është një hap diagnostik për të konfirmuar shkakun, jo një rregullim i përhershëm.

Preferoni të aktivizoni nënshkrimin në të dy skajet aty ku serveri e mbështet. Ndryshimi i një cilësimi sigurie që një ndarje të funksionojë duhet të regjistrohet me vlerën e mëparshme dhe arsyen, që askush të mos ketë nevojë ta rizbulojë në auditimin tjetër.

Pastro sesionin e vjetër përpara se të rregullosh kohëmatësit

Një ndarje që ngec vetëm pasi VPN bie dhe rilidhet zakonisht mban një sesion që serveri tashmë e ka hedhur. Serveri i mbyll sesionet SMB joaktive sipas kohëmatësit Autodisconnect nën LanmanServer\Parameters, që si parazgjedhje është 15 minuta, ndërsa klienti ka SessTimeout të vetin nën LanmanWorkstation\Parameters. Një ndërprerje më e gjatë se ato vlera e lë çdo skaj me një ide tjetër për sesionin.

Riprodhoni atë në një rend fiks që rezultati të ketë kuptim: lidhni tunelin, hapni ndarjen, ndërpritni tunelin për dy minuta, rikthejeni atë dhe pastaj provoni të lexoni një skedar. Nëse montimi rikuperohet vetë, lërini kohëmatësit në paqe. Nëse ngec derisa të rimontoni, rilidhni ndarjen pasi tuneli të jetë ngritur në vend që ta montoni përpara se të ekzistojë, dhe kontrolloni nëse ndihmësi i montimit provon përsëri.

Rritja e afateve është një hap i fundit i arsyeshëm për një lidhje të paqëndrueshme, por trajton simptomën. Një klient që pret më gjatë për një sesion që serveri e ka harruar vazhdon të presë.

Përfundoni duke lexuar një skedar përmes montimit dhe pastaj duke ndërprerë dhe rikthyer tunelin edhe një herë. Ai test pranimi mbulon të tre shtresat njëherësh, dhe është i vetmi test që përputhet me atë që përdoruesi bën në të vërtetë.