Sdílení SMB selhává jen přes VPN: podepisování, nebo kolize podsítí?

Sdílení, které funguje v LAN, může selhat pouze přes tunel. Oddělte odmítnutí podpisu, překrývající se podsíť a zastaralou relaci SMB.

Namapovaná jednotka, která v kanceláři funguje a doma vyprší, sama o sobě neřekne téměř nic užitečného. Tunel zjevně přenáší pakety, jinak by se na server nedostalo nic. Selhala jedna ze tří vrstev: jméno se přeložilo na špatnou adresu, klient odmítl relaci podepsat, nebo stará relace přežila spojení, které ji neslo. Každá má jinou opravu a dvě ze tří jsou na straně klienta.

Tři poruchy nesou stejnou chybu

Písmeno jednotky neříká, která vrstva se rozbila, a text chyby je obvykle dost obecný, aby seděl na všechny tři. Oddělte je dvěma rychlými otázkami: odpovídá server na své IP adrese a přijímá port 445 spojení?

Ty odpovědi dají rozhodovací tabulku místo dohadu. IP funguje a jméno ne, ukazuje na překlad jmen. Obě fungují a přihlášení je odmítnuto, ukazuje na podepisování. Obě fungují a čtení souboru se po výpadku tunelu zasekne, ukazuje na zastaralou relaci.

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

Procházejte je v tomto pořadí, protože jméno přeložené na špatný host dělá každý další test bezvýznamným.

Vyřešte jméno, než se dotknete sdílení

Pokud server odpovídá na své adrese a jméno sdílení vyprší, tunel dělá svou práci a klient hledá na špatném místě. Při vzdáleném přístupu to většinou vysvětlují dvě příčiny.

První je překryv adres. Když kancelář používá 192.168.70.0/24 a domácí router přiděluje stejný rozsah, jméno hostitele přeložené na 192.168.70.20 může ukazovat na místní zařízení místo serveru za tunelem. Windows pak může požadavek odeslat lokálně, odmítnout trasu, nebo jej přeložit na tiskárnu, která tu adresu náhodou má. Opravou je přečíslovat jednu stranu, ne přidat další trasu.

Druhou je rozsah DNS. Adaptér VPN bez interního DNS serveru, nebo s takovým, který je přes tunel nedostupný, nechává krátká jména chodit na veřejný resolver. Přečtěte záznamy DNS adaptéru a před dotykem sdílení se zeptejte přímo na interní jméno:

> 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

Pokud tento dotaz vrátí očekávanou adresu, je překlad jmen vyřešen a problém je výš v zásobníku.

Přečtěte požadavek na podepisování na obou stranách

Dostupný server, který odmítá každé přihlášení, je známkou nesouladu zásad, nikoli poruchy sítě. Windows může vyžadovat podepisování SMB na klientovi a server nebo NAS, který nepodepisuje, nemůže relaci dokončit, ať je tunel jakkoli zdravý.

Nastavení klienta můžete přečíst bez hledání v editoru zásad:

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

Odpovídající hodnota na straně serveru je v konfiguraci SMB serveru a obě se musí shodovat. V jednom hlášeném případě měl klient požadavek zapnutý místními zásadami, zatímco server vůbec nepodepisoval; vypnutí a spuštění gpupdate /force sdílení okamžitě obnovilo. To je diagnostický krok k potvrzení příčiny, ne trvalá oprava.

Upřednostněte zapnutí podepisování na obou stranách, kde to server podporuje. Změna bezpečnostního nastavení, aby sdílení fungovalo, by měla být zaznamenána s předchozí hodnotou a důvodem, aby ji nikdo nemusel znovu objevovat při dalším auditu.

Vymažte zastaralou relaci, než začnete ladit časovače

Sdílení, které se zasekne až po pádu a opětovném připojení VPN, obvykle drží relaci, kterou server už zahodil. Server zavírá nečinné relace SMB podle časovače Autodisconnect v LanmanServer\Parameters, standardně 15 minut, zatímco klient má svůj vlastní SessTimeout v LanmanWorkstation\Parameters. Výpadek delší než tyto hodnoty nechá každou stranu s jinou představou o relaci.

Zopakujte to v pevném pořadí, aby výsledek něco znamenal: připojte tunel, otevřete sdílení, na dvě minuty tunel přerušte, obnovte jej a pak zkuste přečíst soubor. Pokud se připojení vzpamatuje samo, časovačů si nevšímejte. Pokud visí, dokud znovu nepřipojíte, připojte sdílení znovu poté, co tunel běží, místo abyste jej připojovali předtím, a zkontrolujte, zda pomocník připojení zkouší znovu.

Zvyšování časových limitů je rozumný poslední krok u nestabilního spoje, ale léčí příznak. Klient, který čeká déle na relaci, na kterou server zapomněl, stále čeká.

Skončete přečtením jednoho souboru přes připojení a pak ještě jednou přerušením a obnovením tunelu. Tento akceptační test pokrývá všechny tři vrstvy najednou a je jediný, který odpovídá tomu, co uživatel skutečně dělá.

Související články