SMB dijeljenje ne radi samo preko VPN-a: potpis ili sukob podmreža?

Mapirani pogon koji radi u uredu i kod kuće istekne ne daje vam gotovo nikakvu korisnu informaciju sam po sebi. Tunel očito prenosi pakete, inače ništa ne bi stiglo do poslužitelja. Ono što je zakazalo nalazi se u jednom od tri sloja: ime se razriješilo na pogrešnu adresu, klijent je odbio potpisati sesiju ili je stara sesija nadživjela vezu koja ju je nosila. Svaki ima drugu popravku, a dva od tri su na strani klijenta.

Tri kvara nose istu pogrešku

Slovo pogona ne govori koji se sloj slomio, a tekst pogreške obično je dovoljno općenit za sva tri. Razdvojite ih s dva brza pitanja: odgovara li poslužitelj na svojoj IP adresi i prihvaća li port 445 vezu?

Ti odgovori daju tablicu odluka umjesto nagađanja. Ako IP radi, a ime ne, upućuje na razrješavanje imena. Ako oboje radi, a prijava je odbijena, upućuje na potpis. Ako oboje radi, a čitanje datoteke visi nakon prekida tunela, upućuje na zastarjelu sesiju.

Prođite ih tim redom, jer ime koje se razrješava na pogrešnog hosta čini svaki kasniji test besmislenim.

Razriješite ime prije nego dodirnete dijeljenje

Ako poslužitelj odgovara na svojoj adresi, a ime dijeljenja istekne, tunel radi svoj posao, a klijent traži na pogrešnom mjestu. Kod daljinskog pristupa dva uzroka objašnjavaju većinu toga.

Prvi je preklapanje adresa. Kada ured koristi 192.168.70.0/24, a kućni usmjerivač dodjeljuje isti raspon, ime hosta koje se razrješava na 192.168.70.20 može upućivati na lokalni uređaj umjesto na poslužitelj iza tunela. Windows tada može poslati zahtjev lokalno, odbiti rutu ili ga razriješiti na pisač koji slučajno ima tu adresu. Popravak je prenumeracija jedne strane, ne dodavanje druge rute.

Drugi je doseg DNS-a. VPN adapter bez internog DNS poslužitelja ili s onim koji je nedostupan kroz tunel pušta kratka imena na javni resolver. Pročitajte DNS zapise adaptera i izravno upitajte interno ime prije nego dodirnete dijeljenje:

> 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

Ako taj upit vrati očekivanu adresu, razrješavanje je riješeno, a problem je više u stogu.

Pročitajte zahtjev za potpisom na oba kraja

Dostupan poslužitelj koji odbija svaku prijavu znak je neusklađenosti pravila, a ne mrežnog kvara. Windows može zahtijevati SMB potpis na klijentu, a poslužitelj ili NAS koji ne potpisuje ne može dovršiti sesiju, koliko god tunel bio zdrav.

Postavku klijenta možete pročitati bez pretraživanja uređivača pravila:

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

Odgovarajuća vrijednost na strani poslužitelja nalazi se u SMB konfiguraciji poslužitelja i obje se moraju slagati. U jednom prijavljenom slučaju klijent je imao zahtjev uključen lokalnim pravilom, dok poslužitelj uopće nije potpisivao; isključivanje i pokretanje gpupdate /force odmah je vratilo dijeljenje. To je dijagnostički korak za potvrdu uzroka, ne trajna popravka.

Preferirajte uključiti potpis na oba kraja gdje poslužitelj to podržava. Promjenu sigurnosne postavke da bi dijeljenje radilo treba zabilježiti s prethodnom vrijednošću i razlogom, kako je nitko ne bi morao ponovno otkrivati na sljedećem auditu.

Očistite zastarjelu sesiju prije podešavanja mjerača

Dijeljenje koje visi samo nakon što VPN padne i ponovno se poveže obično drži sesiju koju je poslužitelj već odbacio. Poslužitelj zatvara neaktivne SMB sesije prema mjeraču Autodisconnect u LanmanServer\Parameters, koji je standardno 15 minuta, dok klijent ima svoj SessTimeout u LanmanWorkstation\Parameters. Prekid dulji od tih vrijednosti ostavlja svaki kraj s različitom predodžbom o sesiji.

Reproducirajte ga u fiksnom redoslijedu da rezultat nešto znači: spojite tunel, otvorite dijeljenje, prekinite tunel na dvije minute, vratite ga, pa pokušajte pročitati datoteku. Ako se montaža sama oporavi, ostavite mjerače na miru. Ako visi dok ne montirate ponovno, ponovno spojite dijeljenje nakon što je tunel podignut umjesto da ga montirate prije nego postoji, i provjerite pokušava li pomoćnik za montažu ponovno.

Podizanje vremenskih ograničenja razuman je posljednji korak za nestabilnu vezu, ali liječi simptom. Klijent koji dulje čeka sesiju koju je poslužitelj zaboravio još uvijek čeka.

Završite čitanjem jedne datoteke kroz montažu, a zatim još jednom prekidom i vraćanjem tunela. Taj prihvatni test pokriva sva tri sloja odjednom i jedini je koji odgovara onome što korisnik doista radi.