Bumabagsak ang SMB share kapag VPN lang: isyu sa lagda o sagupaan ng subnet?

Ang naka-map na drive na gumagana sa opisina ngunit nag-time out sa bahay ay halos walang kapaki-pakinabang na impormasyong ibinibigay nang mag-isa. Malinaw na nagdadala ng packet ang tunnel, kung hindi ay walang makakarating sa server. Ang nabigo ay isa sa tatlong layer: naresolba ang pangalan sa maling address, tumanggi ang kliyente na lagdaan ang session, o may lumang session na tumagal nang higit sa koneksyong nagdala nito. Bawat isa ay may ibang pag-aayos, at dalawa sa tatlo ay sa panig ng kliyente.

Tatlong pagkabigo ang may parehong error

Hindi sinasabi ng titik ng drive kung aling layer ang nasira, at ang teksto ng error ay karaniwang sapat na pangkalahatan para sa tatlo. Ihiwalay ang mga ito sa dalawang mabilis na tanong: sumasagot ba ang server sa IP address nito, at tumatanggap ba ang port 445 ng koneksyon?

Ang mga sagot na iyon ay gumagawa ng talahanayan ng desisyon sa halip na haka-haka. Kung gumagana ang IP pero hindi ang pangalan, ito ay tumutukoy sa resolusyon. Kung gumagana ang dalawa pero tinatanggihan ang pag-login, ito ay tumutukoy sa lagda. Kung gumagana ang dalawa pero nag-hang ang pagbasa ng file pagkatapos ng pagkaantala ng tunnel, ito ay tumutukoy sa lumang session.

Sundin ang mga ito sa ganoong pagkakasunod-sunod, dahil ang pangalang naresolba sa maling host ay ginagawang walang saysay ang bawat susunod na pagsubok.

I-resolba ang pangalan bago hawakan ang share

Kung sumasagot ang server sa address nito at nag-time out ang pangalan ng share, ginagawa ng tunnel ang trabaho nito at naghahanap ang kliyente sa maling lugar. Sa remote access, dalawang dahilan ang nagpapaliwanag sa halos lahat nito.

Ang una ay pagpapatong ng address. Kapag gumagamit ang opisina ng 192.168.70.0/24 at ang router sa bahay ay nagbibigay ng parehong saklaw, ang hostname na naresolba sa 192.168.70.20 ay maaaring tumuro sa lokal na device sa halip na sa server sa likod ng tunnel. Maaaring ipadala ng Windows ang kahilingan nang lokal, tanggihan ang ruta, o i-resolba ito sa printer na nagkataong may address na iyon. Ang pag-aayos ay muling pagbilang ng isang panig, hindi pagdaragdag ng ibang ruta.

Ang pangalawa ay saklaw ng DNS. Ang VPN adapter na walang internal na DNS server, o may server na hindi maabot sa pamamagitan ng tunnel, ay nag-iiwan ng maiikling pangalan sa pampublikong resolver. Basahin ang mga entry ng DNS ng adapter at tanungin nang direkta ang internal na pangalan bago hawakan ang share:

> 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

Kung ibinabalik ng query na iyon ang inaasahang address, malinaw na ang resolusyon at ang problema ay mas mataas sa stack.

Basahin ang pangangailangan sa lagda sa dalawang dulo

Ang server na maabot ngunit tumatanggi sa bawat pag-login ay tanda ng hindi pagtutugma ng patakaran at hindi ng sira ng network. Maaaring kailanganin ng Windows ang SMB signing sa kliyente, at ang server o NAS na hindi nag-sign ay hindi makakumpleto ng session, gaano man kalusog ang tunnel.

Mababasa mo ang setting ng kliyente nang hindi naghahanap sa editor ng patakaran:

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

Ang katumbas na halaga sa panig ng server ay nasa SMB configuration ng server, at dapat magtugma ang dalawa. Sa isang naiulat na kaso, naka-enable ang pangangailangan sa kliyente sa pamamagitan ng lokal na patakaran habang hindi talaga nag-sign ang server; ang pag-disable nito at pagpapatakbo ng gpupdate /force ay agad na nagpanumbalik ng share. Ito ay diagnostic na hakbang upang kumpirmahin ang dahilan, hindi permanenteng pag-aayos.

Mas mainam na i-enable ang lagda sa dalawang dulo kung saan sinusuportahan ito ng server. Ang pagbabago ng setting ng seguridad para gumana ang isang share ay dapat itala kasama ang dating halaga at dahilan, upang wala nang kailangang tumuklas muli nito sa susunod na audit.

Linisin ang lumang session bago i-tune ang mga timer

Ang share na nag-hang lamang pagkatapos bumagsak at muling kumonekta ang VPN ay karaniwang may hawak na session na itinapon na ng server. Isinasara ng server ang mga idle SMB session ayon sa Autodisconnect timer sa ilalim ng LanmanServer\Parameters, na default na 15 minuto, habang ang kliyente ay may sariling SessTimeout sa ilalim ng LanmanWorkstation\Parameters. Ang pagkaantala na mas mahaba kaysa sa mga halagang iyon ay nag-iiwan sa bawat dulo ng ibang pag-unawa sa session.

Kopyahin ito sa takdang pagkakasunod-sunod para may kahulugan ang resulta: ikonekta ang tunnel, buksan ang share, putulin ang tunnel nang dalawang minuto, ibalik ito, pagkatapos ay subukang magbasa ng file. Kung kusang bumalik ang mount, huwag galawin ang mga timer. Kung nag-hang ito hanggang mag-mount ka muli, ikonekta muli ang share pagkatapos na umangat ang tunnel sa halip na i-mount ito bago pa ito umiral, at tingnan kung nag-uulit ang mount helper.

Ang pagtataas ng timeout ay makatwirang huling hakbang para sa hindi matatag na link, ngunit ginagamot nito ang sintomas. Ang kliyenteng mas matagal na naghihintay sa session na nakalimutan ng server ay naghihintay pa rin.

Tapusin sa pagbasa ng isang file sa pamamagitan ng mount, pagkatapos ay putulin at ibalik ang tunnel nang isa pang beses. Sinasaklaw ng acceptance test na iyon ang tatlong layer nang sabay, at iyon lang ang pagsubok na tumutugma sa aktuwal na ginagawa ng gumagamit.