Kushiriki kwa SMB hushindwa tu kupitia VPN: tatizo la sahihi au mgongano wa subneti?
Shiriki inayofanya kazi kwenye LAN inaweza kushindwa kupitia handaki pekee. Tenganisha kukataliwa kwa sahihi, subneti zinazopishana na kipindi cha SMB kilichopitwa na wakati.
Hifadhi iliyounganishwa inayofanya kazi ofisini lakini inaisha muda nyumbani haitoi karibu taarifa yoyote muhimu yenyewe. Handaki kwa wazi linasafirisha pakiti, vinginevyo hakuna kingefika kwenye seva. Kilichoshindwa ni moja ya tabaka tatu: jina lilitatuliwa kwa anwani isiyo sahihi, mteja alikataa kusaini kipindi, au kipindi cha zamani kiliishi zaidi ya muunganisho uliokibeba. Kila moja ina ukarabati tofauti, na mawili kati ya matatu yako upande wa mteja.
Hitilafu tatu zinaivaa kosa moja
Herufi ya hifadhi haisemi tabaka gani lilivunjika, na maandishi ya kosa kwa kawaida ni ya jumla vya kutosha kutoshea zote tatu. Tenganisha kwa maswali mawili ya haraka: seva inajibu kwenye anwani yake ya IP, na bandari 445 inakubali muunganisho?
Majibu hayo hutoa jedwali la maamuzi badala ya kukisia. Ikiwa IP inafanya kazi na jina halifanyi, hiyo inaelekea kwenye utatuzi wa majina. Ikiwa yote mawili yanafanya kazi na kuingia kunakataliwa, hiyo inaelekea kwenye sahihi. Ikiwa yote mawili yanafanya kazi na usomaji wa faili unakwama baada ya kukatika kwa handaki, hiyo inaelekea kwenye kipindi cha zamani.
| 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 |
Zishughulikie kwa mpangilio huo, kwa sababu jina linalotatuliwa kwa mwenyeji asiye sahihi hufanya kila jaribio la baadaye lisilewe.
Tatua jina kabla ya kugusa shiriki
Ikiwa seva inajibu kwenye anwani yake na jina la shiriki linaisha muda, handaki linafanya kazi yake na mteja anatafuta mahali pasipofaa. Katika ufikiaji wa mbali, sababu mbili zinaeleza sehemu kubwa ya hili.
Ya kwanza ni mwingiliano wa anwani. Ofisi inapotumia 192.168.70.0/24 na kipanga njia cha nyumbani kikitoa masafa hayo hayo, jina la mwenyeji linalotatuliwa kwa 192.168.70.20 linaweza kuelekeza kwenye kifaa cha ndani badala ya seva iliyo nyuma ya handaki. Windows huenda likatuma ombi kwa ndani, likakataa njia, au likatatua kwa printa ambayo kwa bahati ina anwani hiyo. Ukarabati ni kuweka namba upya upande mmoja, si kuongeza njia nyingine.
Ya pili ni wigo wa DNS. Adapta ya VPN isiyo na seva ya DNS ya ndani, au iliyo na seva isiyofikika kupitia handaki, huacha majina mafupi yakienda kwa kitatuzi cha umma. Soma maingizo ya DNS ya adapta na uulize jina la ndani moja kwa moja kabla ya kugusa shiriki:
> 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
Ikiwa swali hilo linarudisha anwani inayotarajiwa, utatuzi wa majina umekamilika na tatizo liko juu zaidi kwenye rafu.
Soma sharti la sahihi kwenye ncha zote mbili
Seva inayofikika lakini inakataa kila kuingia ni ishara ya kutokubaliana kwa sera na si hitilafu ya mtandao. Windows inaweza kulazimisha sahihi ya SMB kwa mteja, na seva au NAS isiyosaini haiwezi kukamilisha kipindi, handaki likiwa na afya vipi.
Unaweza kusoma mpangilio wa mteja bila kupekua kihariri cha sera:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection
Thamani inayolingana upande wa seva iko katika usanidi wa SMB wa seva, na zote mbili zinapaswa kuafikiana. Katika kisa kimoja kilichoripotiwa, mteja alikuwa amewasha sharti kwa sera ya ndani wakati seva haikusaini kabisa; kuzima hilo na kuendesha gpupdate /force kulirudisha shiriki mara moja. Hiyo ni hatua ya utambuzi ili kuthibitisha sababu, si ukarabati wa kudumu.
Pendelea kuwasha sahihi kwenye ncha zote mbili pale seva inapowezesha. Kubadilisha mpangilio wa usalama ili shiriki lifanye kazi kunapaswa kurekodiwa pamoja na thamani ya awali na sababu, ili mtu asilazimike kuigundua upya katika ukaguzi ujao.
Ondoa kipindi cha zamani kabla ya kurekebisha vipima muda
Shiriki linalokwama tu baada ya VPN kuanguka na kuunganishwa tena kwa kawaida linashikilia kipindi ambacho seva tayari imekitupa. Seva hufunga vipindi vya SMB visivyotumika kwa kipima muda cha Autodisconnect chini ya LanmanServer\Parameters, ambacho kwa chaguo-msingi ni dakika 15, wakati mteja ana SessTimeout yake chini ya LanmanWorkstation\Parameters. Ukatizaji mrefu kuliko thamani hizo huacha kila ncha na dhana tofauti ya kipindi.
Zalisha tena kwa mpangilio maalum ili matokeo yawe na maana: unganisha handaki, fungua shiriki, kata handaki kwa dakika mbili, lirudishe, kisha jaribu kusoma faili. Ikiwa upachikaji unajirekebisha, acha vipima muda. Ikiwa linakwama hadi upachike upya, unganisha shiriki tena baada ya handaki kusimama badala ya kulipachika kabla halipo, na angalia kama msaidizi wa upachikaji anajaribu tena.
Kuongeza muda wa kukatika ni hatua ya mwisho inayofaa kwa kiungo kisicho imara, lakini inatibu dalili. Mteja anayesubiri kwa muda mrefu zaidi kipindi ambacho seva imesahau bado anasubiri.
Maliza kwa kusoma faili moja kupitia upachikaji, kisha kukata na kurudisha handaki mara moja zaidi. Jaribio hilo la kukubali linashughulikia tabaka zote tatu kwa wakati mmoja, na ndilo jaribio pekee linalolingana na kile mtumiaji anachofanya kwa kweli.