SMB പങ്കിടൽ VPN വഴി മാത്രം പരാജയപ്പെടുന്നു: ഒപ്പോ അതോ സബ്‌നെറ്റ് കൂട്ടിയിടിയോ?
LAN-ൽ പ്രവർത്തിക്കുന്ന പങ്കിടൽ ടണലിലൂടെ മാത്രം പരാജയപ്പെടാം. ഒപ്പ് നിരസിക്കൽ, ഓവർലാപ്പ് ചെയ്യുന്ന സബ്‌നെറ്റ്, പഴയ SMB സെഷൻ എന്നിവ വേർതിരിക്കുക.
ഓഫീസിൽ പ്രവർത്തിച്ച് വീട്ടിൽ സമയം കഴിയുന്ന മാപ്പ് ചെയ്ത ഡ്രൈവ് അതുതന്നെ കാര്യമായ ഉപയോഗപ്രദമായ വിവരങ്ങൾ നൽകുന്നില്ല. ടണൽ വ്യക്തമായി പാക്കറ്റുകൾ കൊണ്ടുപോകുന്നു, അല്ലെങ്കിൽ സെർവറിൽ എന്തും എത്തില്ലായിരുന്നു. പരാജയപ്പെട്ടത് മൂന്ന് പാളികളിൽ ഒന്നാണ്: പേര് തെറ്റായ വിലാസത്തിലേക്ക് പരിഹരിക്കപ്പെട്ടു, ക്ലയന്റ് സെഷനിൽ ഒപ്പിടാൻ വിസമ്മതിച്ചു, അല്ലെങ്കിൽ പഴയ സെഷൻ അതിനെ വഹിച്ച കണക്ഷനെക്കാൾ കൂടുതൽ കാലം നിലനിന്നു. ഓരോന്നിനും വ്യത്യസ്ത അറ്റകുറ്റപ്പണിയുണ്ട്, മൂന്നിൽ രണ്ടെണ്ണം ക്ലയന്റ് ഭാഗത്താണ്.
മൂന്ന് പരാജയങ്ങൾ ഒരേ പിശക് ധരിക്കുന്നു
ഡ്രൈവ് അക്ഷരം ഏത് പാളി പൊട്ടി എന്ന് പറയുന്നില്ല, പിശക് വാചകം സാധാരണയായി മൂന്നിനും യോജിക്കുന്നത്ര പൊതുവായതാണ്. രണ്ട് വേഗത്തിലുള്ള ചോദ്യങ്ങളിലൂടെ അവയെ വേർതിരിക്കുക: സെർവർ അതിന്റെ IP വിലാസത്തിൽ ഉത്തരം നൽകുന്നുണ്ടോ, പോർട്ട് 445 കണക്ഷൻ സ്വീകരിക്കുന്നുണ്ടോ?
ആ ഉത്തരങ്ങൾ ഊഹത്തിന് പകരം തീരുമാന പട്ടിക ഉണ്ടാക്കുന്നു. IP പ്രവർത്തിച്ച് പേര് പ്രവർത്തിക്കാത്തത് പേര് പരിഹാരത്തിലേക്ക് സൂചിപ്പിക്കുന്നു. രണ്ടും പ്രവർത്തിച്ച് ലോഗിൻ നിരസിക്കപ്പെട്ടാൽ അത് ഒപ്പിലേക്ക് സൂചിപ്പിക്കുന്നു. രണ്ടും പ്രവർത്തിച്ച് ടണൽ തടസ്സത്തിന് ശേഷം ഫയൽ വായന നിൽക്കുന്നുവെങ്കിൽ അത് പഴയ സെഷനിലേക്ക് സൂചിപ്പിക്കുന്നു.
| 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 |
അതേ ക്രമത്തിൽ അവ പൂർത്തിയാക്കുക, കാരണം തെറ്റായ ഹോസ്റ്റിലേക്ക് പരിഹരിക്കപ്പെടുന്ന പേര് തുടർന്നുള്ള ഓരോ പരീക്ഷണത്തെയും അർത്ഥശൂന്യമാക്കുന്നു.
പങ്കിടലിൽ തൊടുന്നതിന് മുമ്പ് പേര് പരിഹരിക്കുക
സെർവർ അതിന്റെ വിലാസത്തിൽ ഉത്തരം നൽകി പങ്കിടലിന്റെ പേര് സമയം കഴിഞ്ഞാൽ, ടണൽ അതിന്റെ ജോലി ചെയ്യുന്നു, ക്ലയന്റ് തെറ്റായ സ്ഥലത്താണ് നോക്കുന്നത്. വിദൂര ആക്സസിൽ ഇതിൽ ഭൂരിഭാഗവും രണ്ട് കാരണങ്ങൾ വിശദീകരിക്കുന്നു.
ആദ്യത്തേത് വിലാസങ്ങളുടെ ഓവർലാപ്പാണ്. ഓഫീസ് 192.168.70.0/24 ഉപയോഗിക്കുമ്പോൾ വീട്ടിലെ റൗട്ടർ അതേ ശ്രേണി നൽകിയാൽ, 192.168.70.20 ആയി പരിഹരിക്കപ്പെടുന്ന ഹോസ്റ്റ് നാമം ടണലിന് പിന്നിലെ സെർവറിന് പകരം പ്രാദേശിക ഉപകരണത്തെ സൂചിപ്പിക്കാം. തുടർന്ന് Windows അഭ്യർത്ഥന പ്രാദേശികമായി അയക്കാം, റൂട്ട് നിരസിക്കാം, അല്ലെങ്കിൽ ആ വിലാസമുള്ള പ്രിന്ററിലേക്ക് പരിഹരിക്കാം. അറ്റകുറ്റപ്പണി ഒരു ഭാഗം വീണ്ടും അക്കമിടലാണ്, മറ്റൊരു റൂട്ട് ചേർക്കലല്ല.
രണ്ടാമത്തേത് DNS പരിധിയാണ്. ആന്തരിക DNS സെർവർ ഇല്ലാത്ത, അല്ലെങ്കിൽ ടണലിലൂടെ എത്തിച്ചേരാനാകാത്ത സെർവറുള്ള VPN അഡാപ്റ്റർ ചെറിയ പേരുകളെ പൊതു റിസോൾവറിലേക്ക് വിടുന്നു. അഡാപ്റ്ററിന്റെ DNS എൻട്രികൾ വായിച്ച്, പങ്കിടലിൽ തൊടുന്നതിന് മുമ്പ് ആന്തരിക നാമം നേരിട്ട് ചോദിക്കുക:
> 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ആ ചോദ്യം പ്രതീക്ഷിച്ച വിലാസം തിരികെ നൽകിയാൽ, പേര് പരിഹാരം വ്യക്തമായി, പ്രശ്നം സ്റ്റാക്കിൽ മുകളിലാണ്.
രണ്ട് അറ്റങ്ങളിലും ഒപ്പ് ആവശ്യകത വായിക്കുക
ഓരോ ലോഗിനും നിരസിക്കുന്ന എത്തിച്ചേരാവുന്ന സെർവർ നെറ്റ്‌വർക്ക് തകരാറല്ല, നയ പൊരുത്തക്കേടിന്റെ സൂചനയാണ്. Windows ക്ലയന്റിൽ SMB ഒപ്പ് നിർബന്ധമാക്കാം, ഒപ്പിടാത്ത സെർവറോ NAS-ഓ ടണൽ എത്ര ആരോഗ്യകരമായിരുന്നാലും സെഷൻ പൂർത്തിയാക്കാനാവില്ല.
നയ എഡിറ്ററിൽ തിരയാതെ ക്ലയന്റ് ക്രമീകരണം വായിക്കാം:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionസെർവർ ഭാഗത്തെ ബന്ധപ്പെട്ട മൂല്യം സെർവറിന്റെ SMB കോൺഫിഗറേഷനിലാണ്, രണ്ടും ഒത്തുപോകണം. റിപ്പോർട്ട് ചെയ്ത ഒരു സംഭവത്തിൽ ക്ലയന്റിൽ ആവശ്യകത പ്രാദേശിക നയത്താൽ സജീവമായിരുന്നു, സെർവർ ഒട്ടും ഒപ്പിട്ടിരുന്നില്ല; അത് പ്രവർത്തനരഹിതമാക്കി gpupdate /force പ്രവർത്തിപ്പിച്ചതോടെ പങ്കിടൽ ഉടൻ പുനഃസ്ഥാപിക്കപ്പെട്ടു. ഇത് കാരണം സ്ഥിരീകരിക്കാനുള്ള രോഗനിർണയ ഘട്ടമാണ്, സ്ഥിരമായ പരിഹാരമല്ല.
സെർവർ പിന്തുണയ്ക്കുന്നിടത്ത് രണ്ട് അറ്റങ്ങളിലും ഒപ്പ് ഓണാക്കുന്നതിന് മുൻഗണന നൽകുക. പങ്കിടൽ പ്രവർത്തിക്കാൻ സുരക്ഷാ ക്രമീകരണം മാറ്റുന്നത് അതിന്റെ മുൻ മൂല്യവും കാരണവും സഹിതം രേഖപ്പെടുത്തണം, അടുത്ത ഓഡിറ്റിൽ ആരും അത് വീണ്ടും കണ്ടെത്തേണ്ടിവരാതിരിക്കാൻ.
ടൈമറുകൾ ക്രമീകരിക്കുന്നതിന് മുമ്പ് പഴയ സെഷൻ മായ്ക്കുക
VPN വീണ് വീണ്ടും ബന്ധിപ്പിച്ചതിന് ശേഷം മാത്രം നിൽക്കുന്ന പങ്കിടൽ സാധാരണയായി സെർവർ ഇതിനകം ഉപേക്ഷിച്ച സെഷൻ പിടിച്ചിരിക്കും. സെർവർ നിഷ്ക്രിയ SMB സെഷനുകൾ LanmanServer\Parameters-ലെ Autodisconnect ടൈമർ പ്രകാരം അടയ്ക്കുന്നു, ഇത് സ്വതേ 15 മിനിറ്റാണ്, ക്ലയന്റിന് LanmanWorkstation\Parameters-ൽ സ്വന്തം SessTimeout ഉണ്ട്. ഈ മൂല്യങ്ങളെക്കാൾ നീണ്ട തടസ്സം ഓരോ അറ്റത്തെയും സെഷനെക്കുറിച്ച് വ്യത്യസ്ത ധാരണയോടെ വിടുന്നു.
ഫലത്തിന് അർത്ഥമുണ്ടാകാൻ ഒരു നിശ്ചിത ക്രമത്തിൽ അത് വീണ്ടും സൃഷ്ടിക്കുക: ടണൽ ബന്ധിപ്പിക്കുക, പങ്കിടൽ തുറക്കുക, ടണൽ രണ്ട് മിനിറ്റ് വിച്ഛേദിക്കുക, പുനഃസ്ഥാപിക്കുക, എന്നിട്ട് ഒരു ഫയൽ വായിക്കാൻ ശ്രമിക്കുക. മൗണ്ട് സ്വയം സുഖം പ്രാപിച്ചാൽ ടൈമറുകൾ വിടുക. വീണ്ടും മൗണ്ട് ചെയ്യുന്നതുവരെ നിന്നാൽ, ടണൽ ഉയർന്നതിന് ശേഷം പങ്കിടൽ വീണ്ടും ബന്ധിപ്പിക്കുക, അത് നിലവിൽ വരുന്നതിന് മുമ്പേ മൗണ്ട് ചെയ്യുന്നതിന് പകരം, മൗണ്ട് സഹായി വീണ്ടും ശ്രമിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക.
ടൈം ഔട്ടുകൾ ഉയർത്തുന്നത് അസ്ഥിരമായ ലിങ്കിന് ന്യായമായ അവസാന ഘട്ടമാണ്, പക്ഷേ അത് ലക്ഷണത്തിന് ചികിത്സ നൽകുന്നു. സെർവർ മറന്ന സെഷനായി കൂടുതൽ കാലം കാത്തിരിക്കുന്ന ക്ലയന്റ് ഇപ്പോഴും കാത്തിരിക്കുന്നു.
മൗണ്ടിലൂടെ ഒരു ഫയൽ വായിച്ച്, എന്നിട്ട് ഒരിക്കൽ കൂടി ടണൽ വിച്ഛേദിച്ച് പുനഃസ്ഥാപിച്ച് അവസാനിപ്പിക്കുക. ആ സ്വീകാര്യതാ പരീക്ഷ മൂന്ന് പാളികളെയും ഒരുമിച്ച് ഉൾക്കൊള്ളുന്നു, ഉപയോക്താവ് യഥാർത്ഥത്തിൽ ചെയ്യുന്നതുമായി യോജിക്കുന്ന ഏക പരീക്ഷ അതാണ്.