sshuttle vs പൂർണ്ണ VPN: അതിന്റെ രീതി യഥാർത്ഥത്തിൽ എന്താണ് ഉൾക്കൊള്ളുന്നത്
sshuttle അതിന്റെ ഫോർവേഡിംഗ് രീതി പിന്തുണയ്ക്കുന്നത് മാത്രമേ കൊണ്ടുപോകൂ: ആദ്യം TCP, DNS, UDP പരിധി, ആവശ്യമായ പ്രാദേശിക അനുമതി, ദൂരസഹായി എന്നിവ പരിശോധിക്കുക.
SSH ഇതിനകം പ്രവർത്തിക്കുന്നു, ക്രിപ്റ്റോഗ്രഫി പരിചിതമായി തോന്നുന്നു എന്ന കാരണത്താൽ sshuttle തിരഞ്ഞെടുക്കപ്പെടുന്നു, എന്നാൽ ആ യുക്തി അനുയോജ്യത തീരുമാനിക്കുന്ന ഏക ചോദ്യം ഒഴിവാക്കുന്നു. ഏത് പാക്കറ്റുകളാണ് യന്ത്രം വിടുന്നത്, മറുവശത്ത് ഏത് അക്കൗണ്ടാണ് അവ കൊണ്ടുപോകുന്നത്, ഉപകരണം എത്ര പ്രാദേശിക അനുമതി ആവശ്യപ്പെടുന്നു. ഈ മൂന്ന് ഉത്തരങ്ങൾ ഫോർവേഡിംഗ് രീതിക്കനുസരിച്ച് വ്യത്യാസപ്പെടുന്നു, അതിനാൽ ഒരു ആപ്ലിക്കേഷനിൽ പ്രവർത്തിക്കുന്ന ക്രമീകരണം അടുത്തതിന് നിശബ്ദമായി പരാജയപ്പെടാം. താഴെയുള്ള വിശദീകരണം ആപ്ലിക്കേഷന് യഥാർത്ഥത്തിൽ ആവശ്യമായ പ്രോട്ടോക്കോളിൽ നിന്നാണ് ആരംഭിക്കുന്നത്.
ആപ്ലിക്കേഷന് ആവശ്യമായ പ്രോട്ടോക്കോളിൽ നിന്ന് തുടങ്ങുക
sshuttle 2.0-ലെ പ്രോട്ടോക്കോൾ പിന്തുണ നിങ്ങൾ തിരഞ്ഞെടുക്കുന്ന രീതിയെ ആശ്രയിച്ചിരിക്കുന്നു. Linux-ലെ NAT, nft രീതികൾ TCP, DNS കൈകാര്യം ചെയ്യുന്നു, TPROXY പൊതുവായ UDP കൂട്ടിച്ചേർക്കുന്നു. ഓരോ പ്ലാറ്റ്ഫോമിനും രീതിക്കും സ്വന്തം പരിധികളുണ്ട്, macOS തികച്ചും വ്യത്യസ്തമായ സംവിധാനത്തിലൂടെ തടയുന്നു. എന്തെങ്കിലും തിരഞ്ഞെടുക്കുന്നതിന് മുൻപ് ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പ്, തിരഞ്ഞെടുത്ത രീതി, ആപ്ലിക്കേഷന് ആവശ്യമായ പ്രോട്ടോക്കോളുകൾ എന്നിവ രേഖപ്പെടുത്തുക.
അതിനാൽ പ്രവർത്തിക്കുന്ന TCP അഭ്യർത്ഥന UDP ആപ്ലിക്കേഷനെക്കുറിച്ചോ ഓരോ DNS അന്വേഷണത്തെക്കുറിച്ചോ വളരെ കുറച്ചേ തെളിയിക്കുന്നുള്ളൂ. sshuttle TCP-യെ പൂർണ്ണ IP പാക്കറ്റുകൾ ടണൽ ചെയ്യുന്നതിനു പകരം സ്ട്രീമുകളായി കണക്കാക്കുന്നു, അതിനാൽ സാധാരണ VPN-ൽ നിന്ന് കടമെടുത്ത ത്രൂപുട്ട് നിഗമനം ഇവിടെ ബാധകമല്ല. നിങ്ങൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിപ്പിക്കുന്ന സംവിധാനത്തെ യഥാർത്ഥത്തിൽ ഉള്ള ഭാരവുമായി താരതമ്യം ചെയ്യുക.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
ക്ലയന്റിന് പ്രാദേശികമായി എന്ത് വേണം
രേഖപ്പെടുത്തിയ ക്ലയന്റ് ക്രമീകരണത്തിന് root അല്ലെങ്കിൽ sudo ആവശ്യമാണ്, കാരണം അത് ടണൽ ഇന്റർഫേസ് സൃഷ്ടിക്കുന്നതിനു പകരം പ്രാദേശിക തടയൽ നിയമങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ആ ഒരു വസ്തുത സുരക്ഷാ കഥ മാറ്റുന്നു: ആ അനുമതിയുള്ള പ്രോസസ്സിന് ഒരു ആപ്ലിക്കേഷന്റേത് മാത്രമല്ല, മുഴുവൻ യന്ത്രത്തിന്റെയും ട്രാഫിക് തിരിച്ചുവിടാനാകും. അനുമതിയെ ഇൻസ്റ്റലേഷൻ വിശദാംശമല്ല, രൂപകൽപ്പനയുടെ ഭാഗമായി കാണുക.
ഉപകരണം ഏത് നിയമങ്ങളാണ് ഇൻസ്റ്റാൾ ചെയ്തതെന്നും അത് പുറത്തുപോകുമ്പോൾ അവ അപ്രത്യക്ഷമാകുന്നുവെന്നും ഉറപ്പാക്കുക. തടയൽ നിയമങ്ങൾ വിട്ട് തകർന്ന സെഷൻ, ഓപ്പറേറ്റർ കണക്ഷൻ പോയി എന്ന് വിശ്വസിച്ചതിന് വളരെ കഴിഞ്ഞും ട്രാഫിക് ഒരു കറുത്ത കുഴിയിലേക്ക് അയച്ചേക്കാം, ലക്ഷണം ബാക്കിയുള്ള നിയമമല്ല, നെറ്റ്വർക്ക് തകരാറുപോലെ തോന്നും.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeആദ്യ കമാൻഡ് സാധാരണ വിളിയുടെ രൂപമാണ്, യഥാർത്ഥത്തിൽ വേണ്ട പ്രിഫിക്സിനൊപ്പം. രണ്ടാമത്തേത് ഉപകരണം എന്താണ് ഇൻസ്റ്റാൾ ചെയ്തതെന്ന് കാണിക്കുന്നു, മൂന്നാമത്തേത് ടണൽ ഇന്റർഫേസ് പ്രത്യക്ഷപ്പെട്ടിട്ടില്ലെന്ന് സ്ഥിരീകരിക്കുന്നു, ഇതാണ് ഈ രൂപകൽപ്പനയ്ക്ക് പ്രതീക്ഷിത ഫലം.
ദൂരവശം എന്താണ് പ്രവർത്തിപ്പിക്കുന്നത്
ദൂരവശം അധികാരമുള്ള SSH അക്കൗണ്ടും അനുയോജ്യമായ Python സഹായി പരിസ്ഥിതിയുമാണ്. പരിമിതമായ ഷെല്ലിൽ വിജയിക്കുന്ന ലോഗിൻ ആ സഹായി പ്രവർത്തിപ്പിക്കാനുള്ള അനുമതി സ്വയമേവ നൽകുന്നില്ല, സഹായി പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന അക്കൗണ്ട് ഓരോ ലക്ഷ്യ സേവനത്തിലും സ്വയമേവ എത്തുന്നുമില്ല. രണ്ട് വസ്തുതകളും പ്രശ്നപരിഹാര കുറിപ്പുകളിലല്ല, പ്രവേശന അഭ്യർത്ഥനയിലാണ് വരേണ്ടത്.
ഹോസ്റ്റ് ഐഡന്റിറ്റി പരിശോധനയും അക്കൗണ്ട് പ്രാമാണീകരണവും സംരക്ഷിക്കുക. ആദ്യ കണക്ഷൻ പ്രവർത്തിക്കാൻ അപരിചിതമായ ഹോസ്റ്റ് കീ സ്വീകരിക്കുന്നത് ദൂരവശം നിങ്ങൾ ഉദ്ദേശിച്ച യന്ത്രമാണെന്ന പരിശോധന നീക്കം ചെയ്യുന്നു, ഇത് ഒരു ലക്ഷ്യത്തിനുള്ള ഫോർവേഡിംഗിനേക്കാൾ ഇവിടെ പ്രധാനമാണ്.
ദൂര അക്കൗണ്ടിനെ ജോലിപ്രവാഹത്തിന് ആവശ്യമായ സേവനങ്ങളിൽ പരിമിതപ്പെടുത്തുക, ആ പരിധി ഹോസ്റ്റ് നടത്തുന്നവരുമായി ചർച്ച ചെയ്യുക. അവർ വിശ്വാസബന്ധത്തിന്റെ ഭാഗമാണ്, ക്ലയന്റ് വശത്തെ ഏത് ക്രമീകരണവും അത് മാറ്റുന്നില്ല.
വിശ്വാസ അതിർത്തി എവിടെയാണ്
SSH വഴി സ്വകാര്യ API കണക്ഷൻ ഫോർവേഡ് ചെയ്യുന്നത് ഓരോ API പ്രവർത്തനത്തിനും അനുമതി നൽകുന്നില്ല. ആപ്ലിക്കേഷന്റെ TLS-ഉം ആപ്ലിക്കേഷനിലേക്കുള്ള ലോഗിനും ഇപ്പോഴും ബാധകമാണ്, പ്രാമാണീകരണമില്ലാത്ത സേവനത്തെ ഉപകരണത്തിന് സുരക്ഷിതമാക്കാനാവില്ല. ദൂര ഹോസ്റ്റിൽ നിന്നുള്ള അടുത്ത ചാട്ടവും സ്വയമേവ SSH ചാനലിന്റെ അതേ സംരക്ഷിത ഭാഗമാകുന്നില്ല, കാരണം ആ രണ്ടാം കണക്ഷൻ ദൂര ഹോസ്റ്റിനുള്ള നയം പിന്തുടരുന്നു.
അതിർത്തി ഒരു വാക്യത്തിൽ എഴുതുക: ഈ പ്രിഫിക്സുകളിലേക്കുള്ള ട്രാഫിക് ആ ഹോസ്റ്റിലെ ഈ അക്കൗണ്ടിലൂടെ പുറത്തുപോകുന്നു. വാക്യത്തിന് ഒരു ഖണ്ഡിക ഒഴിവുകൾ വേണമെങ്കിൽ, രൂപകൽപ്പന അതിന്റെ രേഖകൾ അവകാശപ്പെടുന്നതിലധികം ചെയ്യുന്നു, ഉത്പാദനത്തിൽ എത്തുന്നതിന് മുൻപ് ഒരു രണ്ടാം നോട്ടം അർഹിക്കുന്നു.
ഓരോ പ്രോട്ടോക്കോളിലും തെളിയിക്കുക, എന്നിട്ട് ഉപകരണം തിരഞ്ഞെടുക്കുക
ആവശ്യമായ ഓരോ പ്രോട്ടോക്കോളും ഹാനികരമല്ലാത്ത അഭ്യർത്ഥന ഉപയോഗിച്ച് പരിശോധിക്കുക, റിസോൾവർ പാതയും ആപ്ലിക്കേഷൻ ഉപയോഗിക്കുന്ന വിലാസ കുടുംബങ്ങളും ഉൾപ്പെടെ. പരിശോധനയിൽ വിച്ഛേദവും ഉൾപ്പെടുത്തുക, അപ്പോൾ ആപ്ലിക്കേഷന്റെ അനുവദനീയമായ പരാജയ സ്വഭാവം സംഭവവേളയിലെ അത്ഭുതമല്ല, അറിയപ്പെടുന്ന ഫലമാകും. പ്രവർത്തിക്കുമ്പോൾ ശരിയായി ഫോർവേഡ് ചെയ്ത സെഷൻ വീണതിന് ശേഷം എന്ത് സംഭവിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
വ്യക്തമായി പേരിട്ട കുറച്ച് സേവനങ്ങൾക്ക് സാധാരണ പ്രാദേശിക ഫോർവേഡിംഗ് ഉടമസ്ഥതയ്ക്കും ഓഡിറ്റിനും എളുപ്പമാണ്. തന്റെ രീതിക്ക് യോജിക്കുന്ന ആപ്ലിക്കേഷൻ ട്രാഫിക്കിന് sshuttle നിയമാനുസൃതമായ ഇടനില നൽകുന്നു. ആവശ്യം വിശാലമായ IP കണക്റ്റിവിറ്റിയാണെങ്കിൽ, VPN രൂപകൽപ്പനയാണ് സത്യസന്ധമായ ഉത്തരം, തിരഞ്ഞെടുപ്പ് എൻക്രിപ്ഷൻ അൽഗോരിതങ്ങളുടെ റാങ്കിംഗിനെയല്ല, പരിധിയെയും പ്രവർത്തന ഉത്തരവാദിത്തത്തെയും പിന്തുടരുന്നു.