നിങ്ങളുടെ SSH ക്ലയന്റിലൂടെ ദൂരെയുള്ള Pi ക്ക് SOCKS പ്രോക്സി നൽകുക

ദൂരസ്ഥ ഡൈനാമിക് ഫോർവേഡിംഗ് SOCKS ശ്രോതാവിനെ Pi യിൽ സ്ഥാപിക്കുകയും തുടർന്നുള്ള കണക്ഷൻ നിങ്ങളുടെ ലാപ്ടോപ്പിന്റെ അംഗീകൃത VPN പാതയിൽ നിന്ന് നിർവഹിക്കുകയും ചെയ്യുന്നു. രണ്ടാമതൊരു SSH സെർവർ വേണ്ട.

SOCKS പ്രോക്സി നെറ്റ്വർക്ക് ആക്സസ് ഇതിനകം ഉള്ളിടത്ത് തന്നെ പ്രവർത്തിക്കണമെന്ന് നിങ്ങൾ കരുതുന്നു. OpenSSH ശ്രോതാവിനെ തികച്ചും മറ്റൊരിടത്ത് സ്ഥാപിക്കാം. ദൂരസ്ഥ ഡൈനാമിക് ഫോർവേഡിംഗ് ദൂരസ്ഥ ഹോസ്റ്റിൽ SOCKS പോർട്ട് തുറക്കുകയും ഓരോ കണക്ഷനും നിങ്ങളുടെ ലാപ്ടോപ്പിന്റെ അംഗീകൃത VPN പാത കൊണ്ടുപോകുന്ന പ്രാദേശിക SSH ക്ലയന്റിൽ നിന്ന് ആരംഭിക്കുകയും ചെയ്യുന്നു. Pi ക്ക് പരിമിതമായ ഒരു പ്രോക്സി ലഭിക്കുന്നു; അത് നിങ്ങളുടെ ടണലോ അധികാരങ്ങളോ പാരമ്പര്യമായി സ്വീകരിക്കുന്നില്ല.

ശ്രോതാവും കണക്ഷൻ ആരംഭിക്കുന്ന വശവും വ്യത്യസ്തമായിരിക്കാം

സാധാരണ ssh -D 1080 ശ്രോതാവിനെ നിങ്ങളുടെ സ്വന്തം യന്ത്രത്തിൽ പ്രവർത്തിപ്പിച്ച് അവിടെ നിന്ന് കണക്ഷനുകൾ അയയ്ക്കുന്നു. ദൂരസ്ഥ ഡൈനാമിക് ഫോർവേഡിംഗ് അത് മറിച്ചിടുന്നു: ശ്രോതാവ് ദൂരസ്ഥ ഹോസ്റ്റിൽ പ്രത്യക്ഷപ്പെടുന്നു, അത് സ്വീകരിക്കുന്ന ഓരോ കണക്ഷനും പ്രാദേശിക വശത്ത് നിന്ന് തുറക്കുന്നു. OpenSSH ക്ലയന്റ് മാനുവൽ നിശ്ചിത ലക്ഷ്യമില്ലാത്ത -R എന്നത് കൃത്യമായി ഈ SOCKS4/5 ക്രമീകരണമായി രേഖപ്പെടുത്തുന്നു.

ലാപ്ടോപ്പിൽ നിന്നുള്ള പിന്തുണയുള്ള കമാൻഡ് ഇങ്ങനെ കാണപ്പെടുന്നു, ഇവിടെ അക്കൗണ്ട്, ഹോസ്റ്റുകൾ, പോർട്ട് എന്നിവ പ്ലേസ്ഹോൾഡറുകളായി കണക്കാക്കുന്നു:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

അവിടെ മൂന്ന് വിശദാംശങ്ങൾ ഉപയോഗപ്രദമായ ജോലി ചെയ്യുന്നു. -S none സെഷനെ പങ്കിട്ട കൺട്രോൾ മാസ്റ്ററിൽ നിന്ന് അകറ്റി നിർത്തുന്നു, ExitOnForwardFailure പകുതി തുറന്ന സെഷൻ വിട്ടേക്കുന്നതിനുപകരം വേഗം പരാജയപ്പെടുന്നു, PermitRemoteOpen ദൂരസ്ഥ ശ്രോതാവിന് എത്താൻ കഴിയുന്നത് പരിമിതപ്പെടുത്തുന്നു. അനുവദനീയമായ Pi അക്കൗണ്ട് ഉപയോഗിക്കുകയും ഇവയിലൊന്നും ചേർക്കുന്നതിന് മുൻപ് ഹോസ്റ്റ് കീ പരിശോധിക്കുകയും ചെയ്യുക.

ദൂരസ്ഥ ശ്രോതാവ് യഥാർത്ഥത്തിൽ എന്ത് വെളിപ്പെടുത്തുന്നു

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

loopback ഉപയോക്താവുതോറുമുള്ള അതിർവരമ്പുമല്ല. Pi യിലെ മറ്റൊരു പ്രോസസിന് പോർട്ട് അറിയാമെങ്കിൽ 127.0.0.1:1080 ലേക്ക് കണക്ട് ചെയ്യാം, അതിനാൽ Pi യുടെ പ്രാദേശിക അക്കൗണ്ടുകളും അതിൽ പ്രവർത്തിക്കുന്നതെല്ലാം നിങ്ങളുടെ ആക്സസ് ഡിസൈനിന്റെ ഭാഗമാണ്. ഇത് ലക്ഷ്യങ്ങളുടെ പട്ടിക ഇടുങ്ങിയതായി സൂക്ഷിക്കാനുള്ള കാരണമാണ്, നയ പരിശോധന ഒഴിവാക്കാനുള്ള കാരണമല്ല.

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

ഒരു അപ്ലിക്കേഷൻ പ്രോക്സിയിലൂടെ അയയ്ക്കുക

Pi യിലെ പ്രോക്സി മനസ്സിലാക്കുന്ന ക്ലയന്റിന് അപ്പോൾ അഭ്യർത്ഥന നടത്താം. socks5h എന്ന പൂർവ്വപദം ലക്ഷ്യത്തിന്റെ പേര് പ്രോക്സിക്ക് നൽകുന്നു, അതിനാൽ തിരയലും കണക്ഷനും രണ്ടും ലാപ്ടോപ്പിന്റെ വശത്ത് നടക്കുന്നു, കൂടാതെ PermitRemoteOpen എന്നതിൽ പേരിട്ട ലക്ഷ്യവുമായി അത് ഒത്തുപോകുന്നു:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

സാധാരണ സർട്ടിഫിക്കറ്റ് സാധൂകരണവും അപ്ലിക്കേഷന്റെ സ്വന്തം പ്രാമാണീകരണവും നിലനിർത്തുക. പ്രോക്സി TCP കണക്ഷൻ എവിടെ ഉണ്ടാക്കുന്നു എന്നത് മാറ്റുന്നു; അത് പ്രാമാണീകരണമില്ലാത്ത ഒരു സേവനത്തെ സുരക്ഷിതമാക്കുന്നില്ല, സ്വയം ഒപ്പിട്ട എൻഡ്പോയിന്റിനെ വിശ്വസനീയമാക്കുന്നുമില്ല.

ലാപ്ടോപ്പിന് ഇപ്പോഴും സ്വന്തം റൂട്ടും SSH സെർവറിലേക്കും അപ്ലിക്കേഷനിലേക്കും റിസോൾവർ ആക്സസും ആവശ്യമാണ്. അതിന്റെ SSH ക്ലയന്റിന്റെ ട്രാഫിക് അംഗീകൃത VPN നയം തിരഞ്ഞെടുക്കണം, split-tunnel ഒഴിവാക്കൽ ആ ട്രാഫിക് നിങ്ങൾ പരിശോധിച്ച പാതയിൽ നിന്ന് വ്യത്യസ്തമായ പാതയിലേക്ക് അയച്ചേക്കാം.

പാത തെളിയിച്ച് അത് അടയ്ക്കുക

ശ്രോതാവ് നിങ്ങൾ പ്രതീക്ഷിക്കുന്നിടത്ത് തന്നെയുണ്ടെന്നും ഉദ്ദേശിച്ച ലക്ഷ്യം മാത്രം ഉത്തരം നൽകുന്നുവെന്നും ഉറപ്പാക്കുക:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure ഫോർവേഡിംഗ് സ്ഥാപിച്ചുവെന്ന് തെളിയിക്കാം, എന്നിട്ടും അപ്ലിക്കേഷൻ ലോഗിൻ താഴെ ഭാഗത്ത് വിജയിക്കുന്നുവെന്ന് സാക്ഷ്യപ്പെടുത്താൻ കഴിയില്ല. പോർട്ട് മാത്രമല്ല, അപ്ലിക്കേഷൻ പരിശോധിക്കുക. സ്വീകരിച്ചതിന് ശേഷം ഓരോ അഭ്യർത്ഥനയും പരാജയപ്പെടുത്തുന്ന ശ്രോതാവ് സാധാരണയായി അർത്ഥമാക്കുന്നത് ടണൽ പരാജയപ്പെട്ടു എന്നല്ല, ലക്ഷ്യത്തിന്റെ പേരോ ലാപ്ടോപ്പിന്റെ പാതയോ തെറ്റാണ് എന്നാണ്.

ഈ ക്രമീകരണം TCP മാത്രം കൊണ്ടുപോകുന്നു. UDP, ICMP, പ്രോക്സി ക്രമീകരണങ്ങൾ അവഗണിക്കുന്ന പ്രോഗ്രാമുകൾ എന്നിവ അതിന് പുറത്ത് നിൽക്കുന്നു, SSH സെഷൻ അവസാനിക്കുന്ന നിമിഷം ഫോർവേഡിംഗ് അവസാനിക്കുന്നു. ജോലി കഴിഞ്ഞാൽ ആ സെഷൻ നിർത്തുകയും അപ്ലിക്കേഷനിൽ ചേർത്ത പ്രോക്സി ക്രമീകരണം നീക്കുകയും ചെയ്യുക.

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

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