VPN വഴി RDP മരവിക്കൽ: ഇൻപുട്ട് ഇപ്പോഴും പ്രവർത്തിക്കുന്നു, അതിനാൽ ട്രാൻസ്പോർട്ട് പരിശോധിക്കുക

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

മരവിക്കൽ നിങ്ങളോട് പറയാത്തത്

റിമോട്ട് ഡെസ്ക്ടോപ്പ് ഇൻപുട്ടും സ്ക്രീൻ അപ്ഡേറ്റുകളും TCP 3389 വഴി കൊണ്ടുപോകുന്നു, കൂടാതെ നിലവിലെ Windows ക്ലയന്റുകൾക്ക് സ്ട്രീമിന്റെ ഗ്രാഫിക്സ്-കനത്ത ഭാഗത്തിന് UDP ട്രാൻസ്പോർട്ട് ചേർക്കാം. വലിയ ഡാറ്റാഗ്രാമുകൾ ശകലീകരിക്കുന്ന അല്ലെങ്കിൽ ഉപേക്ഷിക്കുന്ന ടണലിൽ, വിശ്വസനീയമായ ചാനൽ കീസ്ട്രോക്കുകൾ കൊണ്ടുപോകുന്നത് തുടരുന്നു, ഗ്രാഫിക്സ് ചാനൽ നിലയ്ക്കുന്നു. ഫലം മരവിച്ച ചിത്രവും പ്രതികരിക്കുന്ന കീബോർഡും ചേർന്ന വിചിത്രമായ സംയോജനമാണ്. വീണ്ടും കണക്റ്റ് ചെയ്യുന്നത് ചിലപ്പോൾ ലക്ഷണം ഒരു മിനിറ്റേക്ക് ഭേദമാക്കി പിന്നീട് തിരികെ കൊണ്ടുവരുന്നതിന്റെ കാരണവും ഇത് വിശദീകരിക്കുന്നു.

വിച്ഛേദിക്കപ്പെട്ട് വീണ്ടും ചേരുന്ന സെഷൻ മറ്റൊരു തകരാറാണ്, ഒട്ടും തുറക്കാത്ത സെഷൻ മൂന്നാമത്തേതാണ്. ആദ്യം രൂപത്തിന് പേര് നൽകുന്നത് തെറ്റായ പാളി പരിശോധിക്കുന്നതിൽ നിന്ന് നിങ്ങളെ തടയുന്നു.

രണ്ട് കമാൻഡുകൾ ഉപയോഗിച്ച് മൂന്ന് പരാജയങ്ങളെ വേർതിരിക്കുക

എത്തിച്ചേരാനുള്ള കഴിവ് ഒഴിവാക്കുന്നത് വിലകുറഞ്ഞതാണ്. ക്ലയന്റിൽ നിന്ന് RDP പോർട്ട് പരിശോധിക്കുക, തുടർന്ന് ഹോസ്റ്റിൽ സെഷൻ അവസ്ഥ വായിക്കുക.

Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-host

പരാജയപ്പെട്ട TCP പരിശോധന എന്നാൽ സെഷൻ ഒരിക്കലും തുറന്നിട്ടില്ല എന്നാണ്, അതിനാൽ മരവിക്കലല്ല, ഫയർവാൾ, പരിധി അല്ലെങ്കിൽ സേവന പ്രശ്നമായി അതിനെ കാണുക. സജീവ സെഷനോടെ വിജയകരമായ പരിശോധന നിയന്ത്രണ ചാനൽ നിലവിലുണ്ടെന്ന് സ്ഥിരീകരിക്കുന്നു, അതാണ് കൃത്യമായി മരവിച്ച ചിത്രത്തിന്റെ കേസ്. സെഷനുകൾ കാണാൻ അനുമതിയുള്ള അക്കൗണ്ടിൽ നിന്ന് ഹോസ്റ്റ് ചോദ്യം പ്രവർത്തിപ്പിക്കുക, കാരണം അനുമതി പിശക് ശൂന്യമായ പട്ടിക പോലെ തോന്നുന്നു. സെഷൻ ID-യും അവസ്ഥയും രേഖപ്പെടുത്തുക, കാരണം സ്വന്തം ID നിലനിർത്തുന്ന വിച്ഛേദിത സെഷൻ സജീവ സെഷന് തുല്യമല്ല.

UDP ട്രാൻസ്പോർട്ട് ഓഫ് ചെയ്ത് താരതമ്യം ചെയ്യുക

പ്രദർശനം മാത്രം നിലയ്ക്കുന്നുവെങ്കിൽ, ഒരു സമയം ഒരു മാറ്റം വീതം ക്ലയന്റ് ട്രാൻസ്പോർട്ടുകൾ താരതമ്യം ചെയ്യുക. ഇൻബോക്സ് ക്ലയന്റും Store ക്ലയന്റും ഒരേ സ്റ്റാക്ക് പങ്കിടുന്നില്ല, താഴെയുള്ള നയം ഇൻബോക്സ് ക്ലയന്റിൽ നിന്ന് UDP നീക്കം ചെയ്യുന്നു.

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP

മൂല്യം 1 എന്നാൽ ആ ക്ലയന്റിന് UDP ഇതിനകം ഓഫ് ആണ്, അതിനാൽ ഈ ക്രമീകരണത്തെ അതിജീവിക്കുന്ന മരവിക്കൽ UDP പാതയുടെ പ്രശ്നമല്ല. മൂല്യം ഇല്ലാത്തപ്പോൾ നയം പ്രവർത്തനക്ഷമമാക്കി വീണ്ടും കണക്റ്റ് ചെയ്ത് മുമ്പ് മരവിച്ച അതേ പ്രവർത്തനം കൃത്യമായി ആവർത്തിക്കുക. രണ്ട് മാറ്റങ്ങളും ചേർക്കാതെ Store ക്ലയന്റ് പ്രത്യേക ഘട്ടമായി പരിശോധിക്കുക, അല്ലാത്തപക്ഷം ഏതാണ് പ്രധാനമെന്ന് നിങ്ങൾക്ക് അറിയില്ല. Windows പതിപ്പുകൾക്കിടയിൽ ട്രാൻസ്പോർട്ട് സ്വഭാവം മാറിയതിനാൽ ക്ലയന്റ് പതിപ്പ് നിങ്ങളുടെ കുറിപ്പുകളിൽ സൂക്ഷിക്കുക.

ഒരു ഹോസ്റ്റ് മരവിക്കുമ്പോൾ മറ്റുള്ളവ മികച്ചതായിരിക്കുമ്പോൾ

മറ്റുവിധത്തിൽ ആരോഗ്യകരമായ സബ്നെറ്റിൽ ഒരു ഹോസ്റ്റ് മാത്രം പരാജയപ്പെടുന്നത് ടണലിൽ നിന്ന് അകലെ ചൂണ്ടുന്നു. VPN ക്രമീകരണങ്ങൾ തൊടുന്നതിന് മുമ്പ് പാതയുടെ MTU-വും റിമോട്ട് പ്രദർശന സ്റ്റാക്കും പരിശോധിക്കുക.

ping -f -l 1472 rdp-host.example.com

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

സെഷൻ ഒട്ടും തുറക്കുന്നില്ലെങ്കിൽ, അത് മരവിക്കലല്ല, എത്തിച്ചേരാനുള്ള കഴിവാണ്, അതിനാൽ ഇവിടെ നിർത്തുക. അല്ലെങ്കിൽ ലക്ഷണം മാറ്റിയ ട്രാൻസ്പോർട്ട് ക്രമീകരണം നിലനിർത്തി ക്ലയന്റ് പതിപ്പിനൊപ്പം രേഖപ്പെടുത്തുക.