SMB-deel misluk net oor VPN: ondertekening of subnet-botsing?

’n Gekarteerde skyf wat by die kantoor werk en by die huis tyd uitloop, gee op sigself byna geen bruikbare inligting nie. Die tonnel dra duidelik pakkette, anders sou niks die bediener bereik nie. Wat gefaal het, lê in een van drie lae: die naam is na die verkeerde adres opgelos, die kliënt het geweier om die sessie te onderteken, of ’n ou sessie het die verbinding wat dit gedra het, oorleef. Elkeen het ’n ander herstel, en twee van die drie is aan die kliëntkant.

Drie foute dra dieselfde foutboodskap

Die skyfletter sê nie watter laag gebreek het nie, en die foutteks is gewoonlik algemeen genoeg om by al drie te pas. Skei hulle met twee vinnige vrae: antwoord die bediener op sy IP-adres, en aanvaar poort 445 ’n verbinding?

Daardie antwoorde lewer ’n beslissingstabel eerder as ’n raaiskoot. As IP werk en die naam nie, wys dit na naamoplossing. As albei werk en die aanmelding word geweier, wys dit na ondertekening. As albei werk en ’n lêerlees hang ná ’n tonnelonderbreking, wys dit na ’n verouderde sessie.

Werk hulle in daardie volgorde deur, want ’n naam wat na die verkeerde gasheer opgelos word, maak elke latere toets betekenisloos.

Los die naam op voordat jy die deel aanraak

As die bediener op sy adres antwoord en die deelnaam loop tyd uit, doen die tonnel sy werk en soek die kliënt op die verkeerde plek. By afstandtoegang verduidelik twee oorsake die meeste hiervan.

Die eerste is adresoorvleueling. Wanneer die kantoor 192.168.70.0/24 gebruik en die tuisroeteerder dieselfde reeks uitdeel, kan ’n gasheernaam wat na 192.168.70.20 oplos, na ’n plaaslike toestel wys eerder as na die bediener agter die tonnel. Windows kan dan die versoek plaaslik stuur, die roete weier, of na ’n drukker oplos wat toevallig daardie adres het. Die herstel is om een kant te hernommer, nie om nog ’n roete by te voeg nie.

Die tweede is DNS-omvang. ’n VPN-adapter sonder ’n interne DNS-bediener, of met een wat nie deur die tonnel bereikbaar is nie, laat kort name na ’n openbare resolver gaan. Lees die adapter se DNS-inskrywings en vra die interne naam direk voordat jy die deel aanraak:

> 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

As daardie navraag die verwagte adres teruggee, is naamoplossing besleg en is die probleem hoër in die stapel.

Lees die ondertekeningsvereiste aan beide kante

’n Bereikbare bediener wat elke aanmelding weier, is die teken van ’n beleidsverskil eerder as ’n netwerkfout. Windows kan SMB-ondertekening op die kliënt vereis, en ’n bediener of NAS wat nie onderteken nie, kan die sessie nie voltooi nie, hoe gesond die tonnel ook al is.

Jy kan die kliëntinstelling lees sonder om die beleidsredigeerder te deursoek:

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

Die ooreenstemmende waarde aan die bedienerkant staan in die bediener se SMB-konfigurasie, en die twee moet ooreenstem. In een gerapporteerde geval het die kliënt die vereiste per plaaslike beleid aangeskakel terwyl die bediener glad nie onderteken het nie; om dit te deaktiveer en gpupdate /force te laat loop, het die deel onmiddellik herstel. Dit is ’n diagnostiese stap om die oorsaak te bevestig, nie ’n permanente oplossing nie.

Verkies om ondertekening aan beide kante aan te skakel waar die bediener dit ondersteun. Die wysiging van ’n sekuriteitsinstelling om ’n deel te laat werk, moet met die vorige waarde en die rede aangeteken word, sodat niemand dit by die volgende oudit weer hoef te ontdek nie.

Vee die verouderde sessie uit voordat jy die tydhouers instel

’n Deel wat eers hang nadat die VPN val en weer koppel, hou gewoonlik ’n sessie wat die bediener al weggegooi het. Die bediener sluit onaktiewe SMB-sessies op die Autodisconnect-tydhouer onder LanmanServer\Parameters, wat by verstek 15 minute is, terwyl die kliënt sy eie SessTimeout onder LanmanWorkstation\Parameters het. ’n Onderbreking langer as daardie waardes laat elke kant met ’n ander idee van die sessie.

Reproduseer dit in ’n vaste volgorde sodat die resultaat iets beteken: koppel die tonnel, maak die deel oop, onderbreek die tonnel twee minute, herstel dit en probeer dan ’n lêer lees. As die koppeling vanself herstel, laat die tydhouers staan. As dit hang tot jy weer koppel, koppel die deel weer nadat die tonnel op is in plaas daarvan om dit te koppel voordat dit bestaan, en kyk of die koppelingshulp weer probeer.

Om tydlimiete te verhoog is ’n redelike laaste stap vir ’n onstabiele skakel, maar dit behandel die simptoom. ’n Kliënt wat langer wag vir ’n sessie wat die bediener vergeet het, wag steeds.

Sluit af deur een lêer deur die koppeling te lees en dan die tonnel nog eens te onderbreek en te herstel. Daardie aanvaardingstoets dek al drie lae tegelyk, en dit is die enigste toets wat ooreenstem met wat die gebruiker werklik doen.