Deljenje SMB ne uspe samo prek VPN: težava s podpisom ali konflikt podomrežij?

Povezan disk, ki deluje v pisarni in doma poteče, sam po sebi skoraj ne daje koristnih informacij. Tunel očitno prenaša pakete, sicer nič ne bi prišlo do strežnika. Kar je spodletelo, je v enem od treh slojev: ime se je razrešilo na napačen naslov, odjemalec je zavrnil podpis seje ali je stara seja preživela povezavo, ki jo je nosila. Vsak ima drugačno popravilo, in dva od treh sta na strani odjemalca.

Tri okvare nosijo isto napako

Črka diska ne pove, kateri sloj se je zlomil, besedilo napake pa je običajno dovolj splošno, da ustreza vsem trem. Ločite jih z dvema hitrima vprašanjema: ali strežnik odgovarja na svojem naslovu IP in ali vrata 445 sprejmejo povezavo?

Ti odgovori dajo odločitveno tabelo namesto ugibanja. Če IP deluje, ime pa ne, to kaže na razreševanje imen. Če oboje deluje, prijava pa je zavrnjena, to kaže na podpis. Če oboje deluje, branje datoteke pa se obesi po prekinitvi tunela, to kaže na zastarelo sejo.

Predelajte jih v tem vrstnem redu, ker ime, razrešeno na napačnega gostitelja, naredi vsak poznejši preizkus nesmiseln.

Razrešite ime, preden se dotaknete deljenja

Če strežnik odgovarja na svojem naslovu, ime deljenja pa poteče, tunel opravlja svoje delo in odjemalec išče na napačnem mestu. Pri oddaljenem dostopu dva vzroka pojasnita večino tega.

Prvi je prekrivanje naslovov. Ko pisarna uporablja 192.168.70.0/24 in domači usmerjevalnik dodeljuje isto območje, lahko ime gostitelja, razrešeno na 192.168.70.20, kaže na lokalno napravo namesto na strežnik za tunelom. Windows lahko nato zahtevo pošlje lokalno, zavrne pot ali jo razreši na tiskalnik, ki ima slučajno ta naslov. Popravilo je preštevilčenje ene strani, ne dodajanje druge poti.

Drugi je obseg DNS. VPN-adapter brez notranjega strežnika DNS ali s takim, ki prek tunela ni dosegljiv, pusti kratka imena javnemu razreševalniku. Preberite vnose DNS adapterja in neposredno vprašajte za notranje ime, preden se dotaknete deljenja:

> 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

Če ta poizvedba vrne pričakovani naslov, je razreševanje imen razjasnjeno in težava je višje v skladu.

Preberite zahtevo po podpisu na obeh koncih

Dosegljiv strežnik, ki zavrača vsako prijavo, je znak neusklajenosti pravil in ne omrežne okvare. Windows lahko zahteva podpis SMB na odjemalcu, strežnik ali NAS, ki ne podpisuje, pa seje ne more dokončati, ne glede na to, kako zdrav je tunel.

Nastavitev odjemalca lahko preberete, ne da bi brskali po urejevalniku pravil:

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

Ustrezna vrednost na strani strežnika je v konfiguraciji SMB strežnika in obe se morata ujemati. V enem poročanem primeru je imel odjemalec zahtevo vklopljeno z lokalnim pravilom, medtem ko strežnik sploh ni podpisoval; izklop in zagon gpupdate /force je deljenje takoj obnovil. To je diagnostični korak za potrditev vzroka, ne trajno popravilo.

Raje vklopite podpis na obeh koncih, kjer ga strežnik podpira. Spremembo varnostne nastavitve, da bi deljenje delovalo, je treba zabeležiti s prejšnjo vrednostjo in razlogom, da je nihče ne bi moral znova odkrivati ob naslednji reviziji.

Počistite zastarelo sejo, preden nastavite časovnike

Deljenje, ki se obesi šele potem, ko VPN pade in se znova poveže, običajno drži sejo, ki jo je strežnik že zavrgel. Strežnik zapre nedejavne seje SMB po časovniku Autodisconnect v LanmanServer\Parameters, ki je privzeto 15 minut, medtem ko ima odjemalec svoj SessTimeout v LanmanWorkstation\Parameters. Prekinitev, daljša od teh vrednosti, pusti vsak konec z drugačno predstavo o seji.

Ponovite v ustaljenem vrstnem redu, da bo rezultat kaj pomenil: povežite tunel, odprite deljenje, za dve minuti prekinite tunel, ga obnovite in nato poskusite prebrati datoteko. Če si priklop opomore sam, pustite časovnike pri miru. Če se obesi, dokler ne priklopite znova, znova povežite deljenje, ko je tunel pokonci, namesto da bi ga priklapljali, preden obstaja, in preverite, ali pomočnik za priklop poskuša znova.

Povečanje časovnih omejitev je razumen zadnji korak pri nestabilni povezavi, vendar zdravi simptom. Odjemalec, ki dlje čaka na sejo, ki jo je strežnik pozabil, še vedno čaka.

Končajte z branjem ene datoteke prek priklopa in nato še enkrat prekinite in obnovite tunel. Ta sprejemni preizkus pokrije vse tri sloje hkrati in je edini preizkus, ki ustreza temu, kar uporabnik dejansko počne.