ഒരു Mac സ്ക്രീനിന് ലോക്കൽ SSH ഫോർവേഡിംഗോ പൂർണ്ണ VPN-ഓ?

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

മൂന്ന് വ്യവസ്ഥകളാണ് ഇത് തീരുമാനിക്കുന്നത്, അവയിൽ ഏതെങ്കിലും നിങ്ങളെ മാനേജ്ഡ് VPN-ലേക്ക് തള്ളിയേക്കാം.

മൂന്ന് വ്യവസ്ഥകളാണ് ഇത് തീരുമാനിക്കുന്നത്

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

ഉത്തരങ്ങൾ «ഒന്ന്», «അതെ», «ഞാൻ, ഇപ്പോൾ» എന്നിവയാണെങ്കിൽ, ഫോർവേഡിംഗാണ് ശരിയായ ഉപകരണം. ഏതെങ്കിലും ഉത്തരം മാറിയാൽ, പിന്തുണയുള്ള റിമോട്ട് ആക്സസ് ഡിസൈൻ ഒരു വർഷത്തിൽ രേഖപ്പെടുത്താത്ത ടണലിന് ശേഷം വരുന്ന സംഭവ അവലോകനത്തെക്കാൾ വിലകുറഞ്ഞതാണ്.

ഒരു പോർട്ട് ഫോർവേഡ് ചെയ്യുക, നെറ്റ്വർക്കല്ല

ലോക്കൽ ഫോർവേഡിംഗ് നിങ്ങളുടെ യന്ത്രത്തിൽ ഒരു ശ്രോതാവ് തുറക്കുന്നു, ഓരോ കണക്ഷനും SSH സർവറിലൂടെ ആ സർവറിന് എത്താവുന്ന ഒരു ലക്ഷ്യസ്ഥാനത്തേക്ക് അയക്കുന്നു. സ്ക്രീൻ പങ്കിടൽ സേവനം TCP 5900-ൽ കേൾക്കുന്ന Mac-നും mac.corp.example പരിഹരിക്കാവുന്ന ബാസ്റ്റിയനും, കമാൻഡ് ചെറുതും ബോധപൂർവം ഇടുങ്ങിയതുമാണ്. അതിലെ ഓരോ ഓപ്ഷനും ക്രമീകരണം ചെറുതായി നിലനിർത്താൻ ഉള്ളതാണ്: ഷെൽ ഇല്ല, എല്ലാ ഇന്റർഫേസുകളിലും ശ്രോതാവ് ഇല്ല, ഡീമൺ ഇല്ല. അത് പാചകക്കുറിപ്പായല്ല, പരിധിയുടെ പ്രസ്താവനയായി വായിക്കുക.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

ശ്രോതാവിനെ 127.0.0.1-ലേക്ക് ബന്ധിപ്പിക്കുന്നത് അതിനെ മറ്റെല്ലാ ഇന്റർഫേസുകളിൽ നിന്നും അകറ്റി നിർത്തുന്നു. ഇത് ഔപചാരികതയല്ല: എല്ലാ ഇന്റർഫേസുകളിലേക്കും ബന്ധിച്ച ഫോർവേഡിംഗ്, അതേ കഫേ Wi-Fi-യിലുള്ള ആർക്കും വേണ്ടി നിങ്ങളുടെ ലാപ്ടോപ്പിനെ കോർപ്പറേറ്റ് നെറ്റ്വർക്കിലേക്കുള്ള തുറന്ന റിലേയാക്കി മാറ്റുന്നു. പോർട്ട് ഇതിനകം ഉപയോഗത്തിലാണെങ്കിൽ, മറ്റൊരു ഉയർന്ന പോർട്ട് തിരഞ്ഞെടുത്ത് വ്യൂവർ പുതുക്കുക; ഉദാഹരണം യോജിക്കാൻ ബന്ധമില്ലാത്ത ഒരു സേവനവും നിർത്തരുത്.

ബാസ്റ്റിയനിലെ അക്കൗണ്ടിനും ആ ലക്ഷ്യസ്ഥാനത്തേക്ക് ഫോർവേഡ് ചെയ്യാൻ അനുമതി വേണം. ചില കർക്കശമായ SSH കോൺഫിഗറേഷനുകൾ പോർട്ട് ഫോർവേഡിംഗ് പൂർണ്ണമായി അപ്രാപ്തമാക്കുന്നു, ചിലത് permit-listen അല്ലെങ്കിൽ permit-open നിർദ്ദേശം ഉപയോഗിച്ച് അത് പരിമിതപ്പെടുത്തുന്നു. നിരസിക്കപ്പെട്ട ചാനൽ പാസ്വേഡ് തെറ്റായിരുന്നു എന്ന് അനുമാനിക്കുന്നതിന് മുമ്പ് സർവർ നയം വായിക്കുക.

SSH എന്താണ് എൻക്രിപ്റ്റ് ചെയ്യുന്നത്, എവിടെ നിൽക്കുന്നു

SSH സെഷൻ നിങ്ങളുടെ Mac-ൽ നിന്ന് ബാസ്റ്റിയനിലേക്കുള്ള ട്രാഫിക്ക് സംരക്ഷിക്കുന്നു, ഫോർവേഡിംഗ് VNC പ്രോട്ടോക്കോൾ മനസ്സിലാക്കാതെ ആ സെഷനുള്ളിൽ കൊണ്ടുപോകുന്നു. കണക്ഷൻ ബാസ്റ്റിയൻ വിട്ട് ലക്ഷ്യത്തിലേക്ക് പോകുമ്പോൾ, അത് ഇനി നിങ്ങളുടെ SSH സെഷനുള്ളിൽ ഇല്ല. ആ അവസാന ചാട്ടത്തിൽ എന്ത് സംരക്ഷണമുണ്ടായാലും, അത് ലക്ഷ്യ പ്രോട്ടോക്കോളിന്റേതും സ്വകാര്യ നെറ്റ്വർക്കിന്റെ സ്വന്തം നിയന്ത്രണങ്ങളുടേതുമാണ്.

അതുകൊണ്ടാണ്, ആദ്യ ചാട്ടം SSH ഉപയോഗിച്ചു എന്ന കാരണത്താൽ മാത്രം ലളിതമായ അവസാന VNC ചാട്ടത്തെ അറ്റം മുതൽ അറ്റം വരെ എൻക്രിപ്റ്റ് ചെയ്തതെന്ന് വിശേഷിപ്പിക്കാൻ പാടില്ലാത്തത്. ഭാഗങ്ങൾ സത്യസന്ധമായി വിവരിക്കുക: ക്ലയന്റിൽ നിന്ന് ബാസ്റ്റിയൻ വരെ ശക്തം, അതിനുശേഷം ലക്ഷ്യം പിന്തുണയ്ക്കുന്നത്. മുഴുവൻ പാതയും ഒരു സംവിധാനം കൊണ്ട് എൻക്രിപ്റ്റ് ചെയ്യണമെന്നതാണ് ആവശ്യമെങ്കിൽ, ഫോർവേഡിംഗ് അത് നിറവേറ്റുന്നില്ല.

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

പൂർണ്ണ VPN ശരിയായ തീരുമാനമാകുമ്പോൾ

ടാസ്കിന് ഒന്നിലധികം പോർട്ടുകൾ ആവശ്യമെങ്കിൽ VPN തിരഞ്ഞെടുക്കുക: Apple Remote Desktop-ന്റെ മാനേജ്മെന്റും റിപ്പോർട്ടിംഗും ഒരു TCP ഫോർവേഡിംഗിന് കൊണ്ടുപോകാനാവാത്ത അധിക TCP, UDP ട്രാഫിക്ക് ഉപയോഗിക്കുന്നു. ഫോർവേഡിംഗ് ഉൽപ്പന്നത്തിന്റെ ഭാഗിക നടപ്പാക്കലല്ല; അത് വ്യത്യസ്തവും ചെറുതുമായ ഒരു ഉപകരണമാണ്.

പല അഡ്മിനിസ്ട്രേറ്റർമാർ മാറുന്ന സ്ഥലങ്ങളിൽ നിന്ന് കണക്ട് ചെയ്യുമ്പോൾ അത് തിരഞ്ഞെടുക്കുക, കാരണം മാനേജ്ഡ് പ്രൊഫൈൽ ഓരോരുത്തരും കമാൻഡ് ലൈൻ കണ്ടുപിടിക്കാതെ റൂട്ടുകളും ക്രെഡൻഷ്യലുകളും നയവും വിതരണം ചെയ്യുന്നു. ഓഡിറ്റ് ട്രെയിൽ ആരാണ് എന്തിനോട് കണക്ട് ചെയ്തതെന്ന് കാണിക്കേണ്ടിവരുമ്പോൾ അത് തിരഞ്ഞെടുക്കുക, കാരണം ഉപയോക്താവിന് ഒരു SSH സെഷനും പങ്കിട്ട ലോക്കൽ ഫോർവേഡിംഗും വളരെ വ്യത്യസ്ത രേഖകൾ അവശേഷിപ്പിക്കുന്നു.

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

ഫോർവേഡിംഗ് ഉച്ചത്തിൽ പരാജയപ്പെടട്ടെ

പരാജയപ്പെട്ട ബൈൻഡിംഗ് സെഷൻ നിർത്താൻ, കണക്ട് ചെയ്തതുപോലെ തോന്നുകയും ഒന്നും ഫോർവേഡ് ചെയ്യാതിരിക്കുകയും ചെയ്യുന്ന ഒരു ഷെൽ വിടാതിരിക്കാൻ ExitOnForwardFailure=yes ഉപയോഗിക്കുക. ഹോസ്റ്റ് കീ സ്ഥിരീകരണം ഓണാക്കി വെക്കുക, പാസ്വേഡിനെക്കാൾ കീ അല്ലെങ്കിൽ ഏജന്റിന് മുൻഗണന നൽകുക. തുടർന്ന് വ്യൂവർ ഉപയോഗിക്കുന്ന കൃത്യമായ URL പരിശോധിക്കുക, കാരണം പ്രവർത്തിക്കുന്ന SSH സെഷനും പ്രവർത്തിക്കുന്ന സ്ക്രീൻ കണക്ഷനും രണ്ട് വ്യത്യസ്ത ഫലങ്ങളാണ്.

macOS-ലെ നേറ്റീവ് ക്ലയന്റിന്, ലോക്കൽ URL വഴിയാണ് വ്യൂവറിൽ എത്തുന്നത്: open "vnc://127.0.0.1:15900". വിൻഡോ തുറക്കുകയും റിമോട്ട് ഹോസ്റ്റ് പ്രാമാണീകരണം നിരസിക്കുകയും ചെയ്താൽ, ടണൽ കുഴപ്പമില്ല, പ്രശ്നം ലക്ഷ്യത്തിലാണ്. വിൻഡോ ഒരിക്കലും തുറക്കുന്നില്ലെങ്കിൽ, പ്രശ്നം ശ്രോതാവിലോ പോർട്ടിലോ ആണ്.

തീർന്നാൽ സെഷൻ നിർത്തുക, പോർട്ട്, ബാസ്റ്റിയൻ, ലക്ഷ്യം, അക്കൗണ്ട് നയം എന്നിവ എഴുതിവെക്കുക. ആരും രേഖപ്പെടുത്താത്ത ഫോർവേഡിംഗ് ആറ് മാസത്തിന് ശേഷം ഒരു പിൻവാതിലിൽ നിന്ന് വേർതിരിച്ചറിയാനാവില്ല, അത് ചെറുതായും പേരുള്ളതായും താൽക്കാലികമായും നിലനിർത്താനുള്ള ഏറ്റവും ശക്തമായ വാദമാണ്.