SSH ഫോർവേഡ് വഴി VPN മാത്രം ലഭ്യമായ HTTPS സൈറ്റിൽ എത്തുന്നു

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

ഘട്ടം ഒന്ന്: മൂന്ന് മുൻവ്യവസ്ഥകൾ സ്ഥിരീകരിക്കുക

ഏതെങ്കിലും കമാൻഡിന് അർത്ഥം വരുന്നതിന് മുൻപ് മൂന്ന് കാര്യങ്ങൾ ഇതിനകം ശരിയായിരിക്കണം. ആദ്യ യന്ത്രം ഫോർവേഡിംഗ് ഹോസ്റ്റായി ഉപയോഗിക്കാൻ അനുമതി, അതിലേക്ക് പ്രവർത്തിക്കുന്ന SSH ആക്സസ്, ഉദ്ദേശിച്ച ലക്ഷ്യസ്ഥാനം അനുവദിക്കുന്ന സെർവർ നയം എന്നിവ വേണം. ഫയൽ കൈമാറ്റത്തിനായി സൃഷ്ടിച്ച SSH അക്കൗണ്ടിൽ ഫോർവേഡിംഗ് പ്രവർത്തനരഹിതമായിരിക്കാം, ഫോർവേഡിംഗ് അനുവദിക്കുന്ന സെർവർപോലും അതിലൂടെ ഏത് ലക്ഷ്യസ്ഥാനങ്ങൾ ലഭ്യമാണെന്ന് പരിമിതപ്പെടുത്തിയേക്കാം. പരിശോധിക്കുന്നതിന് മുൻപ് ചോദിക്കുക, കാരണം കൂട്ടുകാരന്റെ വർക്ക്സ്റ്റേഷൻ കരാറില്ലാതെ ചാട്ടക്കേന്ദ്രമായി ഉപയോഗിക്കുന്നത് കമാൻഡ് കുറ്റമറ്റതായി പ്രവർത്തിച്ചാലും നയപരമായ പ്രശ്നമാണ്.

ആ പട്ടികയുടെ സാങ്കേതിക പകുതി രണ്ട് കമാൻഡുകൾ തീർക്കുന്നു. ആദ്യത്തേത് അക്കൗണ്ടും കീയും സംവേദനാത്മക പ്രോംപ്റ്റ് ഇല്ലാതെ പ്രവർത്തിക്കുന്നുവെന്ന് തെളിയിക്കുന്നു, രണ്ടാമത്തേത് കോൺഫിഗറേഷൻ ഫയലിലെ കമന്റ് ചെയ്ത ഉദാഹരണത്തിന് പകരം യഥാർത്ഥ സെർവർ നയം പ്രിന്റ് ചെയ്യുന്നു.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

ഘട്ടം രണ്ട്: loopback പോർട്ട് ബൈൻഡ് ചെയ്ത് സെഷൻ ജീവനോടെ നിലനിർത്തുക

ക്ലയന്റ് അപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്ന യന്ത്രത്തിൽ സ്വകാര്യ സേവനത്തിലേക്ക് ഒരു ലോക്കൽ ഫോർവേഡ് തുറക്കുക. ലോക്കൽ നെറ്റ്വർക്കിൽ പ്രസിദ്ധീകരിക്കപ്പെടാതിരിക്കാൻ അത് വ്യക്തമായി loopback-ലേക്ക് ബൈൻഡ് ചെയ്യുക, ഒരു ലോക്കൽ സേവനവും ഇതിനകം പിടിച്ചിട്ടില്ലാത്ത ഉയർന്ന പോർട്ട് തിരഞ്ഞെടുക്കുക. ജോലി ചെയ്യുമ്പോൾ സെഷൻ പ്രവർത്തിപ്പിക്കുക, കാരണം അത് അടയ്ക്കുന്നത് ശ്രോതാവിനെയും അടയ്ക്കുന്നു. ExitOnForwardFailure നിരസിച്ച ബൈൻഡിനെയോ കൈവശപ്പെടുത്തിയ പോർട്ടിനെയോ ഫോർവേഡില്ലാതെ നിൽക്കുന്ന സെഷന് പകരം ഉടനടി പുറത്തുകടക്കലാക്കി മാറ്റുന്നു, ഈ പരാജയരീതിയാണ് ഏറ്റവും കൂടുതൽ സമയം പാഴാക്കുന്നത്.

സ്വകാര്യ കണക്ഷൻ ചാട്ട ഹോസ്റ്റിൽ നിന്നാണ് ഉണ്ടാകുന്നത്, അതിനാൽ ആ ഹോസ്റ്റിന്റെ DNS, റൂട്ടുകൾ, VPN നയം, സേവന ആക്സസ് എന്നിവയെല്ലാം പ്രവർത്തിക്കണം. SSH സെഷൻ ചാട്ട ഹോസ്റ്റിന് ഇല്ലാത്ത എത്തിച്ചേരൽ സൃഷ്ടിക്കുന്നില്ല, VPN ഒരിക്കലും അയച്ചിട്ടില്ലാത്ത ഒരു റൂട്ട് അതിന് നന്നാക്കാനുമാവില്ല. കമാൻഡിന്റെ നിശ്ശബ്ദതയിൽ വിശ്വസിക്കുന്നതിന് പകരം ശ്രോതാവ് യഥാർത്ഥത്തിൽ ഉള്ളിടത്ത് സ്ഥിരീകരിക്കുക.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

ഘട്ടം മൂന്ന്: സോക്കറ്റ് ലോക്കൽ ആകുമ്പോൾ HTTPS പേര് നിലനിർത്തുക

https://127.0.0.1:9443/ ബ്രൗസ് ചെയ്യുന്നത് TLS സെർവർ പേരും അപ്ലിക്കേഷൻ അധികാരവും മാറ്റുന്നു. portal.lab.example ന് നൽകിയ സർട്ടിഫിക്കറ്റ് loopback വിലാസത്തിനെതിരെ സാധുതയുള്ളതായിരിക്കില്ല, ഫലമായുണ്ടാകുന്ന പിശക് ഫോർവേഡിംഗ് ഷോർട്ട്കട്ടിന് പകരം തകർന്ന സർട്ടിഫിക്കറ്റ് പോലെ തോന്നുന്നു. കമാൻഡ് ലൈൻ പരിശോധനയ്ക്ക് യഥാർത്ഥ URL നിലനിർത്തി സോക്കറ്റ് ലക്ഷ്യസ്ഥാനം മാത്രം മാറ്റുക. --connect-to അതാണ് ചെയ്യുന്നത്, താഴെ ഉപയോഗിക്കുന്ന നാല് ഫീൽഡ് രൂപം curl മാന്വൽ രേഖപ്പെടുത്തുന്നു.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

പേര് URL-ൽ, TLS ഹാൻഡ്ഷേക്കിൽ, Host ഹെഡറിൽ നിലനിൽക്കുന്നു, TCP കണക്ഷൻ മാത്രം ലോക്കൽ ശ്രോതാവിലേക്ക് പോകുന്നു. പ്രോക്സി ഇല്ലാത്ത ഓപ്ഷൻ പരിശോധനയെ ഈ ഫോർവേഡിൽ നിലനിർത്തുന്നു, ക്രമീകരിച്ച HTTP പ്രോക്സി അത് തടയാൻ അനുവദിക്കുന്നതിന് പകരം, സർട്ടിഫിക്കറ്റ് പരിശോധന ഓണായി നിലനിർത്തുന്നതാണ് ഫലത്തെ അർത്ഥവത്താക്കുന്നത്.

ഘട്ടം നാല്: ഒരു ഫോർവേഡിന് എന്ത് പൊതിയാനാവില്ലെന്ന് അറിയുക

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

UDP, SMB കണ്ടെത്തൽ, ഡൊമെയിൻ സൈൻ-ഇൻ എന്നിവ TCP ഫോർവേഡിലൂടെ ഒട്ടും കടന്നുപോകുന്നില്ല. യഥാർത്ഥ ആവശ്യം പൊതുവായ നെറ്റ്വർക്ക് ആക്സസ് ആണെങ്കിൽ, ഈ രൂപകൽപ്പന തെറ്റായ ഉപകരണമാണ്, പിന്തുണയുള്ള റിമോട്ട് ആക്സസ് ഗേറ്റ്വേയാണ് ശരിയായത്.

ഘട്ടം അഞ്ച്: വൃത്തിയാക്കി രേഖപ്പെടുത്തുക

പരിശോധന കഴിഞ്ഞാൽ സെഷൻ നിർത്തി ശ്രോതാവ് പോയെന്ന് സ്ഥിരീകരിക്കുക. തിരഞ്ഞെടുത്ത പോർട്ട് ഇതിനകം കൈവശപ്പെടുത്തിയിരുന്നെങ്കിൽ, നമ്പർ ഒഴിവാക്കാൻ ബന്ധമില്ലാത്ത ലോക്കൽ സേവനം നിർത്തുന്നതിന് പകരം മറ്റൊരു ഉപയോഗിക്കാത്ത loopback പോർട്ട് തിരഞ്ഞെടുത്ത് URL, പരിശോധന കമാൻഡ്, കുറിപ്പ് എന്നിവ ഒരുമിച്ച് പുതുക്കുക. ലാപ്ടോപ്പിൽ ഫോർവേഡ് തുറന്നിടുന്നത് രോഗനിർണ്ണയത്തെ കൈകാര്യം ചെയ്യാത്ത സേവനമാക്കി മാറ്റുന്നു.

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