SMB-dieling mislearret allinnich fia VPN: ûndertekening of subnetkonflikt?
In dieling dy’t op it LAN wurket, kin allinnich fia de tunnel mislearje. Skied in ûndertekeningswegering, in oerlaapjend subnet en in ferâldere SMB-sesje.
In keppele skiif dy’t op kantoar wurket en thús tiidút rint, jout op himsels hast gjin brûkbere ynformaasje. De tunnel ferfiert blykber pakketten, oars soe neat de tsjinner berikke. Wat mislearre is, leit yn ien fan trije lagen: de namme is nei it ferkearde adres oplost, de klient wegere de sesje te ûndertekenjen, of in âlde sesje oerlibbe de ferbining dy’t it droech. Elk hat in oare reparaasje, en twa fan de trije binne oan de kliïntkant.
Trije flaters drage deselde flatermelding
De skiifletter fertelt net hokker laach brutsen is, en de flatertekst is meastentiids algemien genôch om by alle trije te passen. Skied se mei twa flugge fragen: antwurdet de tsjinner op syn IP-adres, en akseptearret poarte 445 in ferbining?
Dy antwurden jouwe in beslissingstabel ynstee fan in gissing. As IP wurket en de namme net, wiist dat op namme-oplossing. As beide wurkje en de oanmelding wurdt wegere, wiist dat op ûndertekening. As beide wurkje en it lêzen fan in bestân hinget nei in tunnelûnderbrekking, wiist dat op in ferâldere sesje.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
Wurkskje se yn dy folchoarder ôf, want in namme dy’t nei de ferkearde host oplost makket elke lettere test betsjuttingsleas.
Los de namme op foardat jo de dieling oanreitsje
As de tsjinner op syn adres antwurdet en de dielingsnamme rint tiidút, docht de tunnel syn wurk en siket de klient op it ferkearde plak. By tagong op ôfstân ferklearje twa oarsaken it measte hjirfan.
De earste is adresoerlaap. Wannear’t it kantoar 192.168.70.0/24 brûkt en de thúsrouter deselde rige jout, kin in hostnamme dy’t nei 192.168.70.20 oplost, nei in pleatslik apparaat wize ynstee fan nei de tsjinner efter de tunnel. Windows kin it fersyk dan pleatslik stjoere, de rûte wegerje, of nei in printer oplosse dy’t tafallich dat adres hat. De reparaasje is ien kant opnij nûmerje, net noch in rûte tafoegje.
De twadde is DNS-omfang. In VPN-adapter sûnder interne DNS-tsjinner, of mei ien dy’t net fia de tunnel berikber is, lit koarte nammen nei in iepenbiere resolver gean. Lês de DNS-ynskriuwingen fan de adapter en freegje de interne namme direkt foardat jo de dieling oanreitsje:
> 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.15As dy fraach it ferwachte adres weromjout, is namme-oplossing besljochte en leit it probleem heger yn de stapel.
Lês de ûndertekeningsferplichting oan beide kanten
In berikbere tsjinner dy’t elke oanmelding wegeret, is it teken fan in beliedsôfwiking en net fan in netwurkflater. Windows kin SMB-ûndertekening op de klient easkje, en in tsjinner of NAS dy’t net ûndertekenet, kin de sesje net foltôgje, hoe sûn de tunnel ek is.
Jo kinne de klientynstelling lêze sûnder it beliedsredaksje te trochsykjen:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionDe oerienkommende wearde oan de tsjinnerkant stiet yn de SMB-konfiguraasje fan de tsjinner, en de beide moatte oerienkomme. Yn ien rapportearre gefal hie de klient de ferplichting fia pleatslik belied oan, wylst de tsjinner hielendal net ûndertekene; it útskeakeljen dêrfan en it draaien fan gpupdate /force stelde de dieling daliks werom. Dat is in diagnostyske stap om de oarsaak te befêstigjen, net in bliuwende oplossing.
Jou foarkar oan it oansette fan ûndertekening oan beide kanten dêr’t de tsjinner it stipet. It feroarjen fan in feiligensynstelling om in dieling wurkje te litten, moat mei de foarige wearde en de reden fêstlein wurde, sadat nimmen it by de folgjende audit opnij ûntdekke moat.
Romje de ferâldere sesje op foardat jo de timers ôfstelle
In dieling dy’t pas hinget nei’t de VPN falt en wer ferbynt, hâldt meastentiids in sesje fêst dy’t de tsjinner al fuortsmyt. De tsjinner slút inactive SMB-sesjes op de Autodisconnect-timer ûnder LanmanServer\Parameters, dy’t standert 15 minuten is, wylst de klient syn eigen SessTimeout ûnder LanmanWorkstation\Parameters hat. In ûnderbrekking langer as dy wearden lit elke kant mei in oar byld fan de sesje efter.
Reprodusearje it yn in fêste folchoarder sadat it resultaat wat betsjut: ferbyn de tunnel, iepenje de dieling, ûnderbrek de tunnel twa minuten, stel him werom, en besykje dan in bestân te lêzen. As de montaazje himsels werstelt, lit de timers gewurde. As it hinget oant jo opnij montearje, ferbyn de dieling opnij neidat de tunnel stiet ynstee fan him te montearjen foardat er bestiet, en kontrolearje oft de montaazjehelper it opnij besiket.
It ferheegjen fan tiidlimiteten is in ridlike lêste stap foar in unstable keppeling, mar it behannelet it symptoom. In klient dy’t langer wachtet op in sesje dy’t de tsjinner fergetten is, wachtet noch altyd.
Einigje mei it lêzen fan ien bestân fia de montaazje en dan de tunnel noch ien kear te ûnderbrekken en werom te setten. Dy akseptaasjetest dekt alle trije lagen tagelyk, en it is de iennichste test dy’t oerienkomt mei wat de brûker eins docht.