SMB bendrinimas nepavyksta tik per VPN: parašo ar potinklio konfliktas?

Sujungtas diskas, kuris veikia biure ir namie baigiasi skirtuoju laiku, pats savaime beveik nesuteikia naudingos informacijos. Tunelis akivaizdžiai perduoda paketus, kitaip niekas nepasiektų serverio. Nepavyko vienas iš trijų sluoksnių: vardas išspręstas į neteisingą adresą, klientas atsisakė pasirašyti sesiją arba sena sesija pergyveno ją nešusį ryšį. Kiekvienas turi skirtingą taisymą, o du iš trijų yra kliento pusėje.

Trys gedimai dėvi tą pačią klaidą

Disko raidė nepasako, kuris sluoksnis lūžo, o klaidos tekstas paprastai yra pakankamai bendras, kad tiktu visiems trims. Atskirkite juos dviem greitais klausimais: ar serveris atsako savo IP adresu, ir ar 445 prievadas priima ryšį?

Tie atsakymai pateikia sprendimų lentelę, o ne spėjimą. Jei IP veikia, o vardas ne, tai rodo vardų sprendimą. Jei abu veikia, o prisijungimas atmetamas, tai rodo parašą. Jei abu veikia, o failo skaitymas užstringa po tunelio nutrūkimo, tai rodo pasenusią sesiją.

Naršykite juos ta tvarka, nes vardas, išspręstas į netinkamą mazgą, daro kiekvieną vėlesnį testą beprasmį.

Išspręskite vardą prieš liesdami bendrinimą

Jei serveris atsako savo adresu, o bendrinimo vardas baigiasi skirtuoju laiku, tunelis atlieka savo darbą, o klientas ieško ne toje vietoje. Nuotolinėje prieigoje du veiksniai paaiškina didžiąją dalį to.

Pirmas yra adresų persidengimas. Kai biuras naudoja 192.168.70.0/24, o namų maršrutizatorius išduoda tą patį diapazoną, mazgo vardas, išspręstas į 192.168.70.20, gali rodyti į vietinį įrenginį, o ne į serverį už tunelio. Windows tada gali siųsti užklausą vietoje, atmesti maršrutą arba išspręsti į spausdintuvą, kuris atsitiktinai turi tą adresą. Taisymas yra pernumeruoti vieną pusę, o ne pridėti dar vieną maršrutą.

Antras yra DNS apimtis. VPN adapteris be vidinio DNS serverio arba su tokiu, kuris nepasiekiamas per tunelį, palieka trumpus vardus viešajam resolveriui. Perskaitykite adapterio DNS įrašus ir tiesiogiai paklauskite vidinio vardo prieš liesdami bendrinimą:

> 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

Jei ta užklausa grąžina lauktą adresą, vardų sprendimas išspręstas, o problema yra aukščiau kamino.

Perskaitykite parašo reikalavimą abiejuose galuose

Pasiekiamas serveris, atmetantis kiekvieną prisijungimą, yra politikos neatitikimo ženklas, o ne tinklo gedimas. Windows gali reikalauti SMB parašo kliente, o serveris ar NAS, kuris nepasirašo, negali užbaigti sesijos, kad ir koks sveikas būtų tunelis.

Kliento nuostatą galite perskaityti neieškoję politikos rengyklėje:

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

Atitinkama reikšmė serverio pusėje yra serverio SMB konfigūracijoje, ir abi turi sutapti. Vienu praneštu atveju klientas reikalavimą turėjo įjungtą vietine politika, o serveris visiškai nepasirašė; jo išjungimas ir gpupdate /force paleidimas iš karto atkūrė bendrinimą. Tai diagnostinis žingsnis priežasčiai patvirtinti, o ne nuolatinis taisymas.

Pirmenybę teikite parašo įjungimui abiejuose galuose, kur serveris tai palaiko. Saugumo nuostatos keitimą, kad bendrinimas veiktų, reikia užrašyti su ankstesne reikšme ir priežastimi, kad niekam nereikėtų jos vėl atrasti kitame audite.

Išvalykite pasenusią sesiją prieš derindami laikmačius

Bendrinimas, kuris užstringa tik po to, kai VPN nukrenta ir vėl prisijungia, paprastai laiko sesiją, kurią serveris jau išmetė. Serveris uždaro neaktyvias SMB sesijas pagal Autodisconnect laikmatį skiltyje LanmanServer\Parameters, kuris pagal nutylėjimą yra 15 minučių, o klientas turi savo SessTimeout skiltyje LanmanWorkstation\Parameters. Ilgesnis nei šios reikšmės sutrikimas palieka kiekvieną galą su skirtingu sesijos supratimu.

Pakartokite tai nustatyta tvarka, kad rezultatas ką nors reikštų: prijunkite tunelį, atidarykite bendrinimą, dviem minutėms nutraukite tunelį, atkurkite jį ir tada pabandykite perskaityti failą. Jei prijungimas atsistato pats, palikite laikmačius ramybėje. Jei jis stringa, kol prijungsite iš naujo, prijunkite bendrinimą iš naujo po to, kai tunelis pakilo, o ne prijunkite jį prieš jam atsirandant, ir patikrinkite, ar prijungimo pagalbininkas bando dar kartą.

Skirtųjų laikų didinimas yra pagrįstas paskutinis žingsnis nestabiliam ryšiui, bet jis gydo simptomą. Klientas, kuris ilgiau laukia sesijos, kurią serveris pamiršo, vis tiek laukia.

Užbaikite perskaitydami vieną failą per prijungimą ir tada dar kartą nutraukdami bei atkurdami tunelį. Tas priėmimo testas vienu metu apima visus tris sluoksnius, ir tai vienintelis testas, atitinkantis tai, ką vartotojas iš tikrųjų daro.