SMB partekatzea VPN bidez bakarrik huts egiten du: sinadura edo azpisare gatazka?

LANean funtzionatzen duen partekatzeak tunelaren bidez soilik huts egin dezake. Bereizi sinadura ukoa, gainjartzen den azpisarea eta SMB saio zaharra.

Bulegoan funtzionatzen duen eta etxean denbora-muga gainditzen duen mapatutako unitateak ia ez du informazio erabilgarririk ematen bere horretan. Tunelak paketeak daramatzala argi dago, bestela ezer ez litzateke zerbitzarira iritsiko. Huts egin zuenak hiru geruzetako bat da: izena helbide okerrean ebaztu zen, bezeroak saioa sinatzeari uko egin zion, edo saio zahar batek eraman zuen konexioak baino gehiago iraun zuen. Bakoitzak konponketa desberdina du, eta hiruretatik bi bezeroaren aldean daude.

Hiru hutsegitek errore bera daramate

Unitatearen letrak ez du esaten zein geruza hautsi zen, eta errore-testua normalean hirurei egokitzeko adina orokorra da. Bereizi itzazu bi galdera bizirekin: zerbitzariak bere IP helbidean erantzuten du, eta 445 atakak konexioa onartzen du?

Erantzun horiek erabaki-taula bat ematen dute, asmakizunaren ordez. IPak funtzionatzen badu eta izenak ez, izenen ebazpena seinalatzen du. Biek funtzionatzen badute eta saio-hasiera ukatzen bada, sinadura seinalatzen du. Biek funtzionatzen badute eta fitxategi-irakurketa tunelaren eten baten ondoren blokeatzen bada, saio zaharra seinalatzen du.

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

Landu itzazu ordena horretan, host okerrean ebazten den izen batek geroagoko proba guztiak zentzurik gabe uzten baititu.

Ebatzi izena partekatzeari ukitu aurretik

Zerbitzariak bere helbidean erantzuten badu eta partekatzearen izena denbora-muga gainditzen badu, tunelak bere lana egiten ari da eta bezeroa leku okerrean bilatzen ari da. Urruneko sarbidean, bi kausek azaltzen dute horren zatirik handiena.

Lehena helbideen gainjartzea da. Bulegoak 192.168.70.0/24 erabiltzen duenean eta etxeko routerrak barruti bera ematen duenean, 192.168.70.20ra ebazten den host izen batek tokiko gailu bat seinala dezake tunelaren atzeko zerbitzariaren ordez. Windows-ek orduan eskaera tokian bertan bidal dezake, ibilbidea ukatu edo kasualitatez helbide hori duen inprimagailu batera ebatzi. Konponketa alde bat berriz zenbakatzea da, ez beste ibilbide bat gehitzea.

Bigarrena DNS esparrua da. Barneko DNS zerbitzaririk ez duen edo tunelen bidez iristezina den zerbitzari bat duen VPN egokitzaileak izen laburrak resolver publiko batera uzten ditu. Irakurri egokitzailearen DNS sarrerak eta galdetu barneko izena zuzenean partekatzeari ukitu aurretik:

> 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

Kontsulta horrek espero den helbidea itzultzen badu, izenen ebazpena argitu da eta arazoa pilaren goiko aldean dago.

Irakurri sinadura-baldintza bi muturretan

Sarbide duen zerbitzari batek saio-hasiera guztiak ukatzea politiken desadostasunaren seinalea da, ez sare-akatsarena. Windows-ek SMB sinadura eska dezake bezeroan, eta sinatzen ez duen zerbitzari edo NAS batek ezin du saioa osatu, tunela zenbat ere osasuntsu egon.

Bezeroaren ezarpena irakur dezakezu politika-editorean bilatu gabe:

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

Zerbitzariaren aldeko balio baliokidea zerbitzariaren SMB konfigurazioan dago, eta biek bat etorri behar dute. Jakinarazitako kasu batean, bezeroak baldintza politika lokalaren bidez gaituta zuen bitartean zerbitzariak batere sinatzen ez zuen; hura desgaitzeak eta gpupdate /force exekutatzeak partekatzea berehala berrezarri zuen. Hau kausa baieztatzeko diagnostiko-urratsa da, ez irtenbide iraunkorra.

Hobetsi sinadura bi muturretan gaitzea zerbitzariak onartzen duen lekuetan. Partekatze bat funtziona dezan segurtasun-ezarpen bat aldatzeak aurreko balioa eta arrazoia erregistratu behar ditu, inork hurrengo auditorian berriro aurkitu ez dezan.

Garbitu saio zaharra tenporizadoreak doitu aurretik

VPN-a erori eta berriz konektatu ondoren soilik blokeatzen den partekatze batek zerbitzariak jada baztertutako saio bat eusten du normalean. Zerbitzariak SMB saio inaktiboak ixten ditu LanmanServer\Parameters azpiko Autodisconnect tenporizadorearekin, lehenespenez 15 minutu, bezeroak LanmanWorkstation\Parameters azpiko bere SessTimeout duen bitartean. Balio horiek baino luzeagoa den etendurak mutur bakoitza saioaren ideia desberdinarekin uzten du.

Erreproduzitu ordena finko batean emaitzak zentzua izan dezan: konektatu tunela, ireki partekatzea, moztu tunela bi minutu, berrezarri, eta gero saiatu fitxategi bat irakurtzen. Muntaiak bere kabuz errekuperatzen badu, utzi tenporizadoreei bakean. Berriro muntatu arte blokeatzen bada, konektatu berriz partekatzea tunela altxatu ondoren existitu aurretik muntatu beharrean, eta egiaztatu muntatze-laguntzaileak berriro saiatzen duen.

Denbora-mugak igotzea azken urrats zentzuzkoa da esteka ezegonkor baterako, baina sintomari egiten dio aurre. Zerbitzariak ahaztu duen saio baten zain luzeago egoten den bezeroa oraindik zain dago.

Amaitu muntaiaren bidez fitxategi bat irakurriz eta gero tunela berriro moztuz eta berrezarriz. Onarpen-proba horrek hiru geruzak aldi berean hartzen ditu, eta erabiltzaileak benetan egiten duenarekin bat datorren proba bakarra da.

Erlazionatutako artikuluak