SMB-share werkt alleen via VPN niet: ondertekening of subnetconflict?

Een toegewezen schijf die op kantoor werkt en thuis een time-out geeft, levert op zichzelf bijna geen bruikbare informatie. De tunnel vervoert duidelijk pakketten, anders zou er niets de server bereiken. Wat faalde, zit in een van drie lagen: de naam is naar het verkeerde adres opgelost, de client weigerde de sessie te ondertekenen, of een oude sessie overleefde de verbinding die haar droeg. Elk heeft een andere reparatie, en twee van de drie zitten aan de clientkant.

Drie storingen dragen dezelfde fout

De schijfletter vertelt niet welke laag stuk is, en de fouttekst is meestal algemeen genoeg voor alle drie. Scheid ze met twee snelle vragen: antwoordt de server op zijn IP-adres, en accepteert poort 445 een verbinding?

Die antwoorden leveren een beslistabel op in plaats van een gok. IP werkt en de naam niet, wijst op de resolutie. Beide werken en de aanmelding wordt geweigerd, wijst op de ondertekening. Beide werken en een bestandslezing blijft hangen na een tunnelstoring, wijst op een verouderde sessie.

Werk ze in die volgorde af, want een naam die naar de verkeerde host wijst, maakt elke latere test zinloos.

Los de naam op voordat u de share aanraakt

Als de server op zijn adres antwoordt en de sharenaam een time-out geeft, doet de tunnel zijn werk en zoekt de client op de verkeerde plek. Bij externe toegang verklaren twee oorzaken het grootste deel hiervan.

De eerste is adresoverlap. Wanneer kantoor 192.168.70.0/24 gebruikt en de thuisrouter dezelfde reeks uitdeelt, kan een hostnaam die naar 192.168.70.20 oplost, naar een lokaal apparaat wijzen in plaats van naar de server achter de tunnel. Windows kan het verzoek dan lokaal versturen, de route weigeren, of naar een printer oplossen die toevallig dat adres heeft. De reparatie is één kant hernummeren, niet een extra route toevoegen.

De tweede is DNS-bereik. Een VPN-adapter zonder interne DNS-server, of met een die via de tunnel onbereikbaar is, laat korte namen naar een publieke resolver gaan. Lees de DNS-vermeldingen van de adapter en vraag de interne naam rechtstreeks op voordat u de share aanraakt:

> 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

Als die opzoeking het verwachte adres teruggeeft, is de resolutie opgelost en zit het probleem hoger in de stack.

Lees de ondertekeningsvereiste aan beide kanten

Een bereikbare server die elke aanmelding weigert, is het teken van een beleidsverschil en niet van een netwerkfout. Windows kan SMB-ondertekening aan de clientkant eisen, en een server of NAS die niet ondertekent, kan de sessie niet voltooien, hoe gezond de tunnel ook is.

U kunt de clientinstelling lezen zonder het beleidseditor te doorzoeken:

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

De bijbehorende waarde aan de serverkant staat in de SMB-configuratie van de server, en beide moeten overeenkomen. In een gemeld geval had de client de vereiste aan staan via lokaal beleid terwijl de server helemaal niet ondertekende, en het uitschakelen plus gpupdate /force herstelde de share onmiddellijk. Dat is een diagnostische stap om de oorzaak te bevestigen, geen blijvende oplossing.

Zet de ondertekening bij voorkeur aan beide kanten aan waar de server dat ondersteunt. Het wijzigen van een beveiligingsinstelling om een share te laten werken, moet met de vorige waarde en de reden worden vastgelegd, zodat niemand het bij de volgende audit opnieuw hoeft te ontdekken.

Ruim de verouderde sessie op voordat u timers afstelt

Een share die pas hangt nadat de VPN wegvalt en opnieuw verbindt, houdt meestal een sessie vast die de server al heeft weggegooid. De server sluit inactieve SMB-sessies met de Autodisconnect-timer onder LanmanServer\Parameters, die standaard 15 minuten is, terwijl de client zijn eigen SessTimeout onder LanmanWorkstation\Parameters heeft. Een storing langer dan die waarden laat elke kant met een ander idee over de sessie achter.

Reproduceer het in een vaste volgorde zodat het resultaat iets betekent: verbind de tunnel, open de share, verbreek de tunnel twee minuten, herstel hem en probeer dan een bestand te lezen. Als de mount vanzelf terugkomt, laat de timers dan met rust. Als hij hangt tot u opnieuw mount, verbind de share dan opnieuw nadat de tunnel staat in plaats van hem te mounten voordat hij bestaat, en controleer of de mounthelper het opnieuw probeert.

Time-outs verhogen is een redelijke laatste stap voor een instabiele verbinding, maar het behandelt het symptoom. Een client die langer wacht op een sessie die de server is vergeten, wacht nog steeds.

Sluit af met het lezen van een bestand via de mount en het nog één keer verbreken en herstellen van de tunnel. Die acceptatietest dekt alle drie de lagen tegelijk, en het is de enige test die overeenkomt met wat de gebruiker werkelijk doet.