നിങ്ങളുടെ ടണൽ പ്രവർത്തിക്കുന്നു, ആന്തരിക വിക്കി ലോഡ് ചെയ്യുന്നു, എന്നാൽ റിമോട്ട് ഡെസ്ക്ടോപ്പ് ഇപ്പോഴും കണക്ട് ചെയ്യാൻ വിസമ്മതിക്കുന്നു. ഈ സംയോജനം സാധാരണമാണ്, കാരണം VPN ഹോസ്റ്റിലേക്ക് ഒരു റൂട്ട് നൽകുന്നു, അതേസമയം ഡെസ്ക്ടോപ്പ് സേവനം കേൾക്കണം, സ്വന്തം ഫയർവാൾ അനുവദിക്കണം, അക്കൗണ്ട് പ്രാമാണീകരിക്കാൻ തയ്യാറാകണം. പ്രവർത്തിക്കുന്ന ടണലിനും ഉപയോഗയോഗ്യമായ സെഷനും ഇടയിൽ നാല് പരാജയ ഘട്ടങ്ങളുണ്ട്, ഓരോന്നും വ്യത്യസ്ത സന്ദേശത്തോടെ പരാജയപ്പെടുന്നു. ആദ്യം സന്ദേശം വായിക്കുക, കാരണം അത് ഘട്ടത്തിന്റെ പേര് പറയുന്നു.

ഒന്നുപോലെ തോന്നുന്ന നാല് പരാജയങ്ങൾ

ഘട്ടങ്ങൾ ക്രമത്തിലാണ്: ഡിസൈൻ ഉദ്ദേശിക്കുന്ന സ്വകാര്യ വിലാസത്തിലേക്ക് നാമം പരിഹരിക്കപ്പെടുന്നു, പോർട്ട് TCP ഹാൻഡ്ഷേക്കിന് ഉത്തരം നൽകുന്നു, ഹോസ്റ്റ് സ്വന്തം നയപ്രകാരം കണക്ഷൻ സ്വീകരിക്കുന്നു, സെഷൻ ലോഗിൻ വിജയിക്കുന്നു. ഓരോ ഘട്ടവും അടുത്തതിനെ പരിശോധിക്കാനാകാത്തതാക്കുന്നു, അതിനാൽ നെറ്റ്വർക്ക് ശരിയാകും മുമ്പ് RDP ക്രമീകരണങ്ങൾ മാറ്റുന്നത് ബഹളം മാത്രമാണ് ഉണ്ടാക്കുന്നത്. നാല് കേസുകളിലും ഉപയോക്താവിന്റെ ഭാഗത്തുനിന്ന് ലക്ഷണം ഒരുപോലെ തോന്നുന്നു. ക്ലയന്റിന്റെ സന്ദേശം മാത്രമാണ് അവയെ വേർതിരിക്കുന്നത്.

പ്രവർത്തിക്കുന്ന ആന്തരിക വെബ്സൈറ്റ് നാലിൽ ഒന്നും തെളിയിക്കുന്നില്ല. അതേ നെറ്റ്വർക്കിലെ ഒരു ഹോസ്റ്റ് മറ്റൊരു പോർട്ടിൽ മറ്റൊരു സേവനത്തോടെ ഉത്തരം നൽകി എന്ന് മാത്രം തെളിയിക്കുന്നു. അതിനെ റൂട്ടിംഗിനെക്കുറിച്ചുള്ള തെളിവായി കാണുക, അതിൽ കൂടുതലൊന്നുമല്ല.

ക്രമത്തിൽ പരിശോധിച്ച് ഫലം എഴുതുക. പോർട്ട് ഉത്തരം നൽകിയതിനാൽ ലോഗിൻ സ്ക്രീനിലേക്ക് ചാടുന്നത്, ആദ്യ ഘട്ടം കണ്ടെത്തിയ ഫയർവാൾ പ്രശ്നത്തിൽ ഒരു ഉച്ചയ്ക്കുശേഷം പാഴാക്കാനുള്ള വഴിയാണ്.

3389 ൽ എന്തെങ്കിലും കേൾക്കുന്നുണ്ടോ?

പേരിൽ തുടങ്ങുക, കാരണം തെറ്റായ വിലാസത്തിലേക്ക് പരിഹരിക്കുന്ന പേര് പിന്നീടുള്ള എല്ലാ പരിശോധനയും അസാധുവാക്കുന്നു. ടണലിന്റെ പരിഹാരകനോട് പേരിന്റെ അർത്ഥം ചോദിക്കുക, തുടർന്ന് ഉത്തരം വിജയകരമായ പ്രതികരണവുമായി അല്ല, ഡിസൈൻ ഉദ്ദേശിക്കുന്ന സ്വകാര്യ വിലാസവുമായി താരതമ്യം ചെയ്യുക. പൊതു വിലാസത്തിലേക്ക് പരിഹരിക്കുന്ന പേരാണ് മുഴുവൻ പ്രശ്നം, ഒരു RDP മാറ്റവും അത് ശരിയാക്കില്ല:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

തുടർന്ന് ഹോസ്റ്റിനെയല്ല, പോർട്ടിനെ പരിശോധിക്കുക. 3389 ൽ പൂർത്തിയായ TCP ഹാൻഡ്ഷേക്ക് എത്തിച്ചേരലിനെ അതിന് മുകളിലുള്ള എല്ലാറ്റിൽനിന്നും വേർതിരിക്കുന്നു:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

ഈ പരിശോധന LAN-ൽനിന്നും ടണലിൽനിന്നും നടത്തുക, കാരണം രണ്ട് ഫലങ്ങൾ തമ്മിലുള്ള വ്യത്യാസം തകരാർ VPN പാതയിലേക്ക് പരിമിതപ്പെടുത്തുന്നു. പാതയിൽ രണ്ട് ഫയർവാളുകളുണ്ട്, അവ കൂട്ടിക്കലർത്താൻ എളുപ്പമാണ്: ക്ലയന്റിന്റെ ടണൽ വിലാസത്തിന് ഹോസ്റ്റിലേക്ക് എത്താൻ നെറ്റ്വർക്ക് അനുവദിക്കണം, ഹോസ്റ്റിന്റെ സ്വന്തം ഫയർവാൾ അതേ ഉറവിടത്തെ കേൾക്കുന്ന പോർട്ടിൽ അനുവദിക്കണം. LAN സബ്നെറ്റിൽ പരിമിതപ്പെടുത്തിയ നിയമം VPN ക്ലയന്റ് പൂൾ ഉൾക്കൊള്ളുന്നില്ല, ഇതാണ് ദൂരസ്ഥ ഉപയോക്താക്കൾ മാത്രം റിപ്പോർട്ട് ചെയ്യുന്ന സമയപരിധിയുടെ ഏറ്റവും സാധാരണ കാരണം. നിയമത്തിന്റെ നിലനിൽപ്പല്ല, അതിന്റെ പരിധി പരിശോധിക്കുക.

തിരിച്ചുള്ള പാതയ്ക്കും അതേ പരിശോധന അർഹതയുണ്ട്. ഉത്തരങ്ങൾക്ക് ക്ലയന്റ് പൂളിലേക്ക് തിരികെയുള്ള റൂട്ട് വേണം, LAN-ലേക്കല്ല, ഹോസ്റ്റിന് മുന്നിലുള്ള വിവർത്തനം നിങ്ങളുടെ ലോഗ് കാണിക്കുന്ന ഉറവിടത്തെ മാറ്റുന്നു. പോർട്ട് ഒരു ദിശയിൽ ഉത്തരം നൽകി മറ്റേ ദിശയിൽ നൽകിയില്ലെങ്കിൽ, കാണാത്ത പകുതി സാധാരണയായി തിരിച്ചുള്ള പാതയാണ്.

കോൺഫിഗറേഷൻ വായിക്കുന്നതിന് മുമ്പ് സന്ദേശം വായിക്കുക

മൂന്നാം ഘട്ടം ഹോസ്റ്റ് സ്വന്തം നയപ്രകാരം കണക്ഷൻ നിരസിക്കുന്നതാണ്, ഇത് പലപ്പോഴും ഉടൻ തുറന്ന് അടയുന്ന പോർട്ടുപോലെ തോന്നുന്നു. എന്തോ ഉത്തരം നൽകി, അത് മൗനത്തേക്കാൾ ഉപയോഗപ്രദമായ വിവരമാണ്. ഹാൻഡ്ഷേക്ക് പൂർത്തിയായി സെഷൻ ഉടൻ മരിച്ചെങ്കിൽ, നെറ്റ്വർക്ക് കുഴപ്പമില്ല, തീരുമാനം ഹോസ്റ്റ് എടുക്കുന്നു. വീണ്ടും നെറ്റ്വർക്കിൽ തൊടുന്നതിന് മുമ്പ് റിമോട്ട് ഡെസ്ക്ടോപ്പ് അനുമതികൾ നോക്കുക.

സവിശേഷത മെഷീനിൽ പ്രവർത്തനക്ഷമമായിരിക്കാം, എന്നാൽ പ്രവേശനം നിർദ്ദിഷ്ട ഗ്രൂപ്പുകളിൽ പരിമിതപ്പെടുത്തിയിരിക്കുന്നു, കൂടാതെ നിങ്ങൾ വന്ന വിലാസം ഒഴിവാക്കുന്ന രീതിയിൽ ശ്രോതാവ് ബന്ധിപ്പിക്കപ്പെട്ടിരിക്കാം. നെറ്റ്വർക്ക് ലെവൽ പ്രാമാണീകരണം ഡെസ്ക്ടോപ്പ് ലോഡ് ചെയ്യുന്നതിന് മുമ്പ് പരാജയപ്പെടുന്ന ഒരു ഗേറ്റ് ചേർക്കുന്നു, അതിന്റെ പിശക് ടെക്സ്റ്റ് തെറ്റായ പാസ്വേഡിൽനിന്ന് വ്യത്യസ്തമാണ്. ക്ലയന്റിന്റെ സന്ദേശം ഹോസ്റ്റിന്റെ ഇവന്റ് ലോഗുമായി താരതമ്യം ചെയ്യുക, കാരണം സന്ദേശം ഗേറ്റിനെയും ലോഗ് അക്കൗണ്ടിനെയും പേര് പറയുന്നു.

സെഷൻ ലോഗിൻ അതിന്റേതായ അതിർത്തിയാണ്

പ്രാമാണീകരണം ഡെസ്ക്ടോപ്പ് സേവനത്തിന്റേതാണ്, VPN-ന്റേതല്ല. ടണലിന്റെ ഐഡന്റിറ്റിയും ഡെസ്ക്ടോപ്പ് അക്കൗണ്ടും വെവ്വേറെ ലോക്കൗട്ട് നയങ്ങളുള്ള വെവ്വേറെ ക്രെഡൻഷ്യലുകളാണ്, അതിനാൽ പ്രവർത്തിക്കുന്ന ടണൽ ടണൽ നിങ്ങളെ സ്വീകരിച്ചു എന്ന് മാത്രം തെളിയിക്കുന്നു. ഡെസ്ക്ടോപ്പ് അക്കൗണ്ട് ലോക്ക് ചെയ്യുന്നത് ടണലിനെ ബാധിക്കുന്നില്ല, തിരിച്ചും ശരിയാണ്.

രണ്ടും അക്ഷതമായി സൂക്ഷിക്കുക. സ്വകാര്യ റൂട്ട് ഇല്ലെങ്കിൽ റൂട്ട് ശരിയാക്കുക, കാരണം ശ്രോതാവിനെ ഇന്റർനെറ്റിൽ പ്രസിദ്ധീകരിക്കുന്നത് എത്തിച്ചേരൽ തകരാറിനെ തുറന്ന ഡെസ്ക്ടോപ്പുമായി കൈമാറുന്നു. അതേ സമയം പ്രത്യക്ഷപ്പെട്ട സർട്ടിഫിക്കറ്റ് മുന്നറിയിപ്പ് കടക്കാൻ സെഷന്റെ ഐഡന്റിറ്റി പരിശോധനകൾ ദുർബലമാക്കരുത്. RDP ശ്രോതാവിൽ സ്വയം ഒപ്പിട്ട സർട്ടിഫിക്കറ്റ് ഡിസൈൻ പ്രകാരം മുന്നറിയിപ്പ് നൽകുന്നു, അതിനാൽ അത് സ്വീകരിക്കുന്നത് ഘട്ടമല്ല, തീരുമാനമാണ്.

വീണ്ടും ശ്രമിക്കുന്നതിന് മുമ്പ് ശ്രമങ്ങൾ എണ്ണുക. ഡെസ്ക്ടോപ്പ് ലോക്കൗട്ട് പരിധികൾ പരാജയപ്പെട്ട ലോഗിനുകൾ VPN പരാജയങ്ങളിൽനിന്ന് വെവ്വേറെ എണ്ണുന്നു, ടൈമറിൽ വീണ്ടും ശ്രമിക്കുന്ന ക്ലയന്റ് നിങ്ങൾ ഇപ്പോഴും നിയമം തിരുത്തുമ്പോൾ പരിധി കവിയാം. പാസ്വേഡ് മാറ്റിയതിന് ശേഷം അക്കൗണ്ടുകൾ ലോക്ക് ചെയ്യുന്ന അതേ സമാന്തര പുനഃശ്രമ സംവിധാനമാണിത്.

സെഷന് എന്ത് കൊണ്ടുപോകാം, എവിടെ നിൽക്കുന്നു

ആവശ്യമാകുന്നതിന് മുമ്പ് അംഗീകൃത സൈൻ-ഔട്ട് പ്രവാഹം പഠിക്കുക. ജാലകം അടയ്ക്കുന്നത് കാഴ്ച മാത്രം വിച്ഛേദിച്ചേക്കാം, സെഷൻ അതിന്റെ കോൺഫിഗർ ചെയ്ത നയപ്രകാരം തുടർന്നും പ്രവർത്തിക്കും, ഇത് പങ്കിട്ടതോ ഓഡിറ്റ് ചെയ്തതോ ആയ ഹോസ്റ്റിൽ പ്രധാനമാണ്. നയം പ്രതീക്ഷിക്കുമ്പോൾ സെഷനുള്ളിൽനിന്ന് സൈൻ ഔട്ട് ചെയ്യുക.

തുടർന്ന് സെഷന് എന്ത് വഹിക്കാമെന്ന് തീരുമാനിക്കുക, കാരണം ക്ലിപ്ബോർഡ്, വീണ്ടും വിന്യസിച്ച ഡ്രൈവുകൾ, പ്രിന്റർ വീണ്ടും വിന്യാസം, ഫയൽ കൈമാറ്റം എന്നിവ നയം അനുവദിക്കുന്നിടത്ത് പ്രാദേശിക, ദൂരസ്ഥ സിസ്റ്റങ്ങൾക്കിടയിൽ ഡാറ്റ നീക്കുന്നു. മറുവശത്ത് പ്രവർത്തിക്കുന്ന പ്രസിദ്ധീകരിച്ച ആപ്ലിക്കേഷൻ സ്വയമേവ ഡൗൺലോഡ്-രഹിത അതിർത്തിയല്ല, വായനയ്ക്ക് മാത്രമെന്ന് തോന്നുന്ന സെഷനും ക്ലിപ്ബോർഡ് വഹിക്കാം. കണക്ഷനല്ല, യഥാർത്ഥ ജോലി പരിശോധിക്കുക: ഫയൽ തുറക്കുക, ആപ്ലിക്കേഷൻ ഉപയോഗിക്കുക, നിങ്ങൾക്ക് ആവശ്യമായ വീണ്ടും വിന്യാസം സ്ഥിരീകരിക്കുക. പുറത്തുനിന്ന് റിമോട്ട് ഡെസ്ക്ടോപ്പിൽ എത്തുന്നതിനെക്കുറിച്ചുള്ള Microsoft മാർഗ്ഗനിർദ്ദേശം പിന്തുണയ്ക്കുന്ന എക്സ്പോഷർ ഓപ്ഷനുകൾ വിവരിക്കുന്നു, സമ്മർദ്ദത്തിൽ ചേർത്ത പൊതു ശ്രോതാവിനെക്കാൾ ഇത് മികച്ച റഫറൻസാണ്.

അനുബന്ധ ലേഖനങ്ങൾ