HTTP പ്രോക്സി, SSH ടണൽ അല്ലെങ്കിൽ VPN: ശരിയായ പാളി തിരഞ്ഞെടുക്കുക

ഒരു ആന്തരിക സേവനത്തിൽ എങ്ങനെ എത്താം എന്ന് മൂന്ന് എൻജിനീയർമാരോട് ചോദിക്കുക, മൂന്ന് രൂപകൽപ്പനകൾ ലഭിക്കും: ഒരു വെബ് പ്രോക്സി, ഒരു SSH ടണൽ അല്ലെങ്കിൽ പൂർണ്ണമായ VPN। മൂന്നും ദൂര സേവനം എത്തിപ്പിടിക്കാവുന്നതാക്കാം, മൂന്നും ട്രാഫിക് മറ്റൊരിടത്തുനിന്ന് വരുന്നതുപോലെ കാണിക്കാം। വ്യത്യാസങ്ങൾ പിന്നീട് പ്രകടമാകും, ഉപയോഗിക്കുന്ന പ്രോട്ടോക്കോൾ തിരഞ്ഞെടുത്ത ഉപകരണം കരുതുന്നതല്ലാത്തപ്പോൾ। ബ്രൗസറിലെ വേഗത്തിലുള്ള പരിശോധന പാസാകുന്ന രൂപകൽപ്പന അഭ്യർത്ഥനയ്ക്ക് കാരണമായ ആപ്ലിക്കേഷനിൽ പതിവായി പരാജയപ്പെടുന്നു।

രണ്ട് വസ്തുതകളിൽ നിന്ന് തീരുമാനിക്കുക: ഏത് പ്രോട്ടോക്കോളുകൾ കടക്കണം, ബന്ധപ്പെട്ട പേരുകൾ ആർക്ക് വിശകലനം ചെയ്യാം। ബാക്കിയെല്ലാം മുൻഗണനയാണ്।

പ്രോക്സി മനസ്സിലാകുന്നത് മാത്രം നീക്കുന്നു

വെബ് പ്രോക്സി തനിക്കായി നിർമ്മിച്ച പ്രോട്ടോക്കോൾ വിശകലനം ചെയ്യുന്നു। ക്ലയന്റ് അതിന് ഒരു അഭ്യർത്ഥന നൽകുന്നു, അത് ആ അഭ്യർത്ഥന മുന്നോട്ട് നൽകുന്നു, അതിനാൽ പ്രോക്സി ക്രമീകരണമില്ലാത്ത ആപ്ലിക്കേഷൻ ഒട്ടും പങ്കെടുക്കുന്നില്ല। HTTPS-ന് ക്ലയന്റിന് അതാര്യമായ ചാനൽ വേണം, പ്രോക്സി അത് അഭ്യർത്ഥന വായിക്കുന്നതിനുപകരം CONNECT വഴി നൽകുന്നു।

SSH ഡൈനാമിക് ഫോർവേഡിംഗ് SOCKS സംസാരിക്കുന്ന ലോക്കൽ പോർട്ട് തുറക്കുന്നു, ആ പോർട്ട് TCP സ്ട്രീം ക്ലയന്റ് പേരിടുന്ന ഏത് ലക്ഷ്യത്തിലേക്കും കൈമാറുന്നു। TCP-യിൽ നിർമ്മിച്ച പ്രോട്ടോക്കോളുകൾ സാധാരണയായി അതിലൂടെ പ്രവർത്തിക്കുന്നു। UDP അല്ല, ഉപകരണം വ്യക്തമായി പിന്തുണ ചേർക്കുന്നില്ലെങ്കിൽ। ലോക്കൽ ഫോർവേഡിംഗ് കൂടുതൽ ഇടുങ്ങിയതാണ്: ഒരു ലോക്കൽ പോർട്ട് ഒരു നിശ്ചിത ഹോസ്റ്റിലേക്കും പോർട്ടിലേക്കും മാപ്പ് ചെയ്തിരിക്കുന്നു, അത് ഒരു അറിയപ്പെടുന്ന സേവനത്തിന് മാത്രം സേവനം നൽകുന്നു।

ssh -D 1080 user@bastion
ssh -L 8443:fileserver.internal:443 user@bastion

VPN പാക്കറ്റുകൾ നീക്കുന്നു। ക്ലയന്റ് ടണലിലേക്ക് അയക്കുന്നതെല്ലാം അതിലൂടെ കടക്കുന്നു, UDP-യും ICMP-യും ഉൾപ്പെടെ, അതിനാൽ അത് ഒരു ബന്ധത്തിനല്ല, നെറ്റ്വർക്ക് ആവശ്യത്തിന് യോജിക്കുന്നു।

ആരെങ്കിലും പേര് വിശകലനം ചെയ്യണം

ലക്ഷ്യ നാമം ദൂര നെറ്റ്വർക്കിന്റെ DNS-ൽ മാത്രം ഉള്ളപ്പോൾ, അന്വേഷണം നടത്തുന്ന യന്ത്രത്തിന് ആ മേഖല കാണാൻ കഴിയണം। വെബ് പ്രോക്സി അന്വേഷണം സ്വയം നടത്തുന്നു, അതിനാൽ ലാപ്ടോപ്പിന് പേര് വിശകലനം ചെയ്യാനാകാത്തപ്പോഴും ആന്തരിക നാമം അതിലൂടെ പ്രവർത്തിക്കുന്നു। SOCKS-നും അതുപോലെ പെരുമാറാം, പക്ഷേ ക്ലയന്റ് ഇതിനകം വിശകലനം ചെയ്ത വിലാസത്തിലേക്ക് ബന്ധിപ്പിക്കുന്നതിനുപകരം പേര് കൈമാറിയാൽ മാത്രം। ആ തിരഞ്ഞെടുപ്പ് സർവറിലല്ല, ക്ലയന്റിലാണ്।

curl വിഭജനം വ്യക്തമായി കാണിക്കുന്നു: ഒരു ഫ്ലാഗ് ഹോസ്റ്റ്നെയിം പ്രോക്സിയിലേക്ക് നൽകുന്നു, മറ്റൊന്ന് ആദ്യം ലോക്കലായി വിശകലനം ചെയ്യുന്നു। ലോക്കൽ വിശകലനത്തിൽ ആന്തരിക നാമം മാത്രം ഏതെങ്കിലും ടണലിൽ സ്പർശിക്കുന്നതിന് മുമ്പേ പരാജയപ്പെടുന്നു, പിശക് യഥാർത്ഥത്തിൽ DNS തീരുമാനമായിരുന്നതിന് പ്രോക്സിയെ കുറ്റപ്പെടുത്തുന്നു।

VPN മൂന്നാം വഴി സ്വീകരിക്കുന്നു: റൂട്ടുകൾക്കരികിൽ സ്വകാര്യ റിസോൾവറും തിരയൽ ഡൊമെയ്നും ഇൻസ്റ്റാൾ ചെയ്യുന്നു। അത് സൗകര്യപ്രദമാണ്, പരിചിതമായ ഒരു മിഥ്യാബോധം സൃഷ്ടിക്കുന്നു: ഉത്തരം നൽകാത്ത റിസോൾവറോടൊപ്പം നിലനിൽക്കുന്ന റൂട്ട്, പാക്കറ്റുകൾ അപ്പുറം എത്തുന്നുണ്ടെങ്കിലും, മരിച്ച ടണലിനെപ്പോലെ തന്നെ തോന്നുന്നു।

നെറ്റ്വർക്ക് ഒരു പുറത്തുകടക്കൽ മാത്രം അനുവദിക്കുമ്പോൾ

പല കോർപ്പറേറ്റ് നെറ്റ്വർക്കുകളും പുറത്തേക്കുള്ള ബന്ധങ്ങൾ പ്രാമാണീകരിച്ച വെബ് പ്രോക്സി വഴി മാത്രം അനുവദിക്കുന്നു। OpenVPN ഉം SSH ഉം അവിടെ പ്രവർത്തിപ്പിക്കാം, ആദ്യത്തേത് സ്വന്തം ഗതാഗതം പ്രോക്സിയിലൂടെ ടണൽ ചെയ്ത്, രണ്ടാമത്തേത് ചെറിയ CONNECT സഹായി പ്രവർത്തിപ്പിക്കുന്ന പ്രോക്സി കമാൻഡിലൂടെ।

TCP-യിൽ നിർമ്മിച്ച ടണലുകൾ ആ നിയന്ത്രണത്തെ അതിജീവിക്കുന്നു, UDP അടിസ്ഥാനമാക്കിയ VPN അതിജീവിക്കുന്നില്ല, വീട്ടിൽ പ്രവർത്തിച്ച് ഓഫീസിൽ പരാജയപ്പെടുന്ന ധാരാളം കോൺഫിഗറേഷനുകളെ അത് വിശദീകരിക്കുന്നു। രണ്ടാം ചെലവ് വളരെ എളുപ്പത്തിൽ വിട്ടുപോകുന്നു: പ്രോക്സിയിലൂടെയുള്ള TCP ബന്ധത്തിനുള്ളിൽ കൊണ്ടുപോകുന്ന TCP ടണലിന് ഇപ്പോൾ വീണ്ടും അയക്കുന്ന രണ്ട് പാളികളുണ്ട്, നഷ്ടത്തിനിടയിൽ ആ ജോടി ഏതെങ്കിലും ഒരു പാളി ഒറ്റയ്ക്ക് സൃഷ്ടിക്കാത്ത രീതിയിൽ കിടന്നുപോകുന്നു।

ഇടനിലക്കാരെ ശൃംഖലയാക്കുന്നത് പാളി തിരഞ്ഞെടുക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ ചോദ്യമാണ്। രണ്ടാമത് ഒരു പ്രോക്സിയോ Tor ഓ ചേർക്കുന്നത് ആര് എന്ത് നിരീക്ഷിക്കുന്നു എന്നത് മാറ്റുന്നു, ശൃംഖലയിലെ സ്ഥാനം ഏത് ചാട്ടം സൈഫർടെക്സ്റ്റ് കാണുന്നു എന്ന് തീരുമാനിക്കുന്നു।

ചാട്ടങ്ങളുടെ എണ്ണത്തേക്കാൾ ക്രമം പ്രധാനമാണ്। പുറം ചാട്ടം എൻക്രിപ്റ്റ് ചെയ്ത പ്രവാഹം നിരീക്ഷിക്കുമ്പോൾ അകം ചാട്ടം അത് കൊണ്ടുപോകുന്ന വ്യക്തമായ ടെക്സ്റ്റ് കാണുന്നു, അതിനാൽ ശൃംഖല അതിന്റെ ഏറ്റവും അശ്രദ്ധമായ കണ്ണിയോളം മാത്രം സ്വകാര്യമാണ്। ചാട്ടങ്ങൾക്കിടയിൽ പ്രോട്ടോക്കോളുകൾ കലർത്തുന്നത് അത് സ്വയം മെച്ചപ്പെടുത്തുന്നില്ല। അത് പ്രധാനമായും പരാജയ മാതൃകകളെക്കുറിച്ച് ചിന്തിക്കുന്നത് ബുദ്ധിമുട്ടാക്കുന്നു।

വ്യാജ വിലാസം ഓപ്ഷനുകളിൽ ഒന്നല്ല

മറ്റൊരാളുടെ സ്രോതസ്സ് വിലാസത്തോടെ പാക്കറ്റുകൾ നിർമ്മിക്കുന്നത് ഉപയോഗപ്രദമായ ഒന്നും നേടുന്നില്ല: മറുപടികൾ യഥാർത്ഥ ഉടമയിലേക്ക് പോകുന്നു, മിക്ക നെറ്റ്വർക്കുകളും ട്രാഫിക് നേരിട്ട് ഉപേക്ഷിക്കുന്നു। ഇടനിലക്കാരൻ ആവശ്യമായത് സ്രോതസ്സ് കെട്ടിച്ചമയ്ക്കാൻ കഴിയാത്തതുകൊണ്ടാണ്, അതാണ് മൂന്ന് രൂപകൽപ്പനകളുടെയും സത്യസന്ധമായ ന്യായീകരണം।

അത് അവയിൽ ഓരോന്നിനും അവകാശപ്പെടാനാകുന്നതിനെ പരിമിതപ്പെടുത്തുന്നു। ഒരു നിർദ്ദിഷ്ട വിലാസത്തിൽ നിന്ന് ഉത്ഭവിക്കുന്നതുപോലെ തോന്നുന്നത് ആ വിലാസം നിയമപരമായി എവിടെ അനുവദിച്ചിരിക്കുന്നു, ആർക്ക് അത് റൂട്ട് ചെയ്യാം എന്നതിന്റെ ചോദ്യമാണ്, ഏത് ഉപകരണത്തിന് ഹെഡർ വ്യാജമാക്കാം എന്നതല്ല। രൂപകൽപ്പന വിപരീതം അനുമാനിക്കുന്നുവെങ്കിൽ, അനുമാനം അത് ഫിൽട്ടർ ചെയ്യുന്ന ആദ്യ ദാതാവിൽ പരാജയപ്പെടുന്നു। അനുമാനം എഴുതിവയ്ക്കുക, പരാജയം വരുമ്പോൾ തിരിച്ചറിയാൻ കഴിയും।

പ്രോട്ടോക്കോളുകളും പേരുകളും കൊണ്ട് തീരുമാനിക്കുക

ഒരു വെബ് ക്ലയന്റിന് ഒരു വെബ് സേവനം വേണ്ടിവരികയും പ്രോക്സി ക്രമീകരണങ്ങൾ ഉണ്ടാകുകയും ചെയ്യുമ്പോൾ പ്രോക്സി തിരഞ്ഞെടുക്കുക। കുറച്ച് അറിയപ്പെടുന്ന TCP സേവനങ്ങൾ മതിയാകുകയും SSH പ്രവേശനം ഇതിനകം ഉണ്ടാകുകയും ചെയ്യുമ്പോൾ SSH ടണൽ തിരഞ്ഞെടുക്കുക। നിരവധി ആപ്ലിക്കേഷനുകൾ, TCP അല്ലാത്ത ട്രാഫിക്, സ്വകാര്യ DNS അല്ലെങ്കിൽ വീണ്ടും ഉപയോഗിക്കാവുന്ന പാത എന്നിവ ആവശ്യത്തിന്റെ ഭാഗമാകുമ്പോൾ VPN തിരഞ്ഞെടുക്കുക।

തുടർന്ന് യഥാർത്ഥ ക്ലയന്റും യഥാർത്ഥ നാമവും ഉപയോഗിച്ച് പരിശോധിക്കുക। പ്രോക്സി വഴി പേജ് ലോഡ് ചെയ്യുന്നത് UDP-യെക്കുറിച്ച് ഒന്നും പഠിപ്പിക്കുന്നില്ല, ഒരു ഉപകരണം SOCKS-ൽ പ്രവർത്തിപ്പിക്കുന്നത് സിസ്റ്റം റിസോൾവറിനെക്കുറിച്ച് ഒന്നും പഠിപ്പിക്കുന്നില്ല। പ്രക്രിയ ഏത് ലോക്കൽ വിലാസത്തിൽ ബന്ധിച്ചു, ഏത് റിസോൾവർ ഉത്തരം നൽകി എന്ന് വായിക്കുക। പ്രവർത്തിക്കുന്ന പാതയും ഒരിക്കൽ യാദൃശ്ചികമായി പ്രവർത്തിച്ച പാതയും തമ്മിലുള്ള വ്യത്യാസം അതാണ്।