OpenVPN-നുള്ള SOCKS5 പ്രോക്സി: TCP ടണൽ അതോ ആപ്പുകൾ പ്രോക്സി ചെയ്യണോ?

പ്രോക്സി വഴി മാത്രം പുറത്തേക്ക് പോകാൻ അനുവദിക്കുന്ന നെറ്റ്‌വർക്കുകളാണ് പ്രവർത്തിക്കുന്ന പ്രൊഫൈൽ പെട്ടെന്ന് മരിക്കുന്ന സ്ഥലം. പ്രോക്സി വിലാസമാണ് ആ പരാജയത്തിലെ ഏറ്റവും താൽപ്പര്യമില്ലാത്ത ചരം. എല്ലാം തീരുമാനിക്കുന്നത് പ്രോക്സി കൈമാറാൻ പോകുന്ന ട്രാഫിക്കിന്റെ രൂപമാണ്, കാരണം ഈ പ്രോക്സികൾ ബൈറ്റ് സ്ട്രീം അയയ്ക്കുന്നു, UDP ടണൽ അങ്ങനെയല്ല. അത് രണ്ട് ആർക്കിടെക്ചറുകൾ ബാക്കിയാക്കുന്നു, അവ വ്യത്യസ്ത സ്ഥലങ്ങളിൽ പൊട്ടുന്നു.

ഒരു നിയന്ത്രണമാണ് രൂപകൽപ്പന തീരുമാനിക്കുന്നത്

SOCKS5 യഥാർത്ഥത്തിൽ UDP അസോസിയേഷൻ മോഡ് വ്യക്തമാക്കുന്നു. എന്നിട്ടും OpenVPN ക്ലെന്റിന്റെ പ്രോക്സി പിന്തുണ സ്ട്രീമുകൾക്ക് ചുറ്റും നിർമ്മിച്ചതാണ്: socks-proxy TCP പ്രൊഫൈലുകൾക്കായി രേഖപ്പെടുത്തിയിരിക്കുന്നു, കൂടാതെ HTTP CONNECT പ്രോക്സിക്ക് ഡാറ്റാഗ്രാമുകൾക്ക് ഒരു വഴിയുമില്ല. ഡോക്യുമെന്റേഷന്റെ ഒരു വരി കോൺഫിഗറേഷൻ ഫയൽ തൊടുന്നതിന് മുമ്പ് ആർക്കിടെക്ചർ തീരുമാനിക്കുന്നു.

അതിനാൽ ചോദ്യം ഏത് പ്രോക്സി തിരഞ്ഞെടുക്കണം എന്നതല്ല. ടണൽ സ്ട്രീം ആകുന്നുണ്ടോ, അതോ ഡാറ്റാഗ്രാം ആയി തുടർന്ന് പ്രോക്സിംഗ് മറ്റെന്തോ ആഗിരണം ചെയ്യാൻ അനുവദിക്കുന്നുണ്ടോ എന്നതാണ്.

ഓപ്ഷൻ A: ടണലിനെ സ്ട്രീം ആക്കുക

ഇതിന് TCP ശ്രോതാവുള്ള സെർവറും പ്രോക്സി പേരിടുന്ന ക്ലെന്റ് പ്രൊഫൈലും വേണം. രണ്ട് ഭാഗങ്ങളും ആവശ്യമാണ്, ആളുകൾ മറക്കുന്നത് സെർവർ ഭാഗമാണ്:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

അവസാന വരി http-proxy proxy.internal 8080 കൊണ്ട് മാറ്റുക, പ്രോക്സി HTTP സംസാരിക്കുമ്പോൾ, ആവശ്യപ്പെട്ടാൽ ഒരു ക്രെഡൻഷ്യൽ ഫയൽ ചേർക്കുക. പ്രോക്സി നിങ്ങളുടെ VPN പോർട്ടിലേക്ക് CONNECT ചെയ്യാൻ തയ്യാറായിരിക്കണം, സെർവർ TCP-യിൽ ഉത്തരം നൽകണം; UDP മാത്രം ശ്രോതാവ് ആ ശ്രമം അവഗണിക്കുന്നു. 443 തിരഞ്ഞെടുക്കുന്നത് പ്രായോഗിക നീക്കമാണ്, കാരണം പല നിയന്ത്രിത നെറ്റ്‌വർക്കുകളും അതും അൽപ്പം മറ്റും മാത്രം അനുവദിക്കുന്നു.

ചെലവ് TCP-യുടെ മേൽ TCP അടുക്കിവയ്ക്കുന്നതാണ്. ഒരു നഷ്ടപ്പെട്ട പുറം സെഗ്മെന്റ് ആ കണക്ഷൻ പങ്കിടുന്ന എല്ലാ ആന്തരിക സ്ട്രീമുകളെയും തടയുന്നു, അതിനാൽ സാധാരണ സ്വതന്ത്രമാകുമായിരുന്ന വീണ്ടെടുക്കൽ പങ്കിടപ്പെടുന്നതാകുന്നു. സെറ്റപ്പും കൂടുതൽ സമയമെടുക്കുന്നു, അസ്ഥിരമായ പുറം പാത വേഗത കുറഞ്ഞതിന് പകരം അസ്ഥിരമായ ടണലാകുന്നു.

ഓപ്ഷൻ B: ടണലിനെ വിട്ടേക്കുക

ടണൽ UDP-യിൽ തുടരേണ്ടിവരുമ്പോൾ, എന്തെങ്കിലും കോൺഫിഗർ ചെയ്യുന്ന സ്ഥലം ടണലല്ല. പകരം ആപ്പുകളിൽ നിന്നുള്ള പുറം TCP ഒരു പ്രാദേശിക SOCKS ശ്രോതാവിലേക്ക് റീഡയറക്ട് ചെയ്യുന്നു, ആപ്പുകൾ പ്രോക്സി ഉണ്ടെന്ന് ഒരിക്കലും അറിയുന്നില്ല. Linux-ൽ ഇത് സാധാരണയായി redsocks കൂടാതെ nat പട്ടികയിൽ ഒരു NAT REDIRECT നിയമം.

വീണ്ടും TCP മാത്രം. privoxy പോലുള്ള HTTP മാത്രം പ്രോക്സിക്ക് ഏകപക്ഷീയ പ്രോട്ടോക്കോളുകൾ കൈമാറാൻ കഴിയില്ല, ഈ രൂപകൽപ്പന ആപ്പുകൾക്ക് ഡാറ്റാഗ്രാം പിന്തുണയും ചേർക്കുന്നില്ല.

സോഫ്റ്റ്‌വെയർ പിന്തുണയ്ക്കുന്നിടത്ത് ഓരോ ആപ്പിനോടും നേരിട്ട് പ്രോക്സിയെക്കുറിച്ച് പറയുന്നത് സാധാരണയായി നല്ലതാണ്. ഓഡിറ്റ് ചെയ്യാൻ എളുപ്പമാണ്, നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ കാണാൻ കഴിയുന്ന ഒരിടത്ത് അത് പരാജയപ്പെടുന്നു.

ഓരോ ഓപ്ഷനും എവിടെ പരാജയപ്പെടുന്നു

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

ഡാറ്റാഗ്രാമുകൾ ആവശ്യമുള്ള എല്ലാറ്റിനും, പ്രോക്സിക്ക് മനസ്സിലാകാത്ത പ്രോട്ടോക്കോളുകൾക്കും, റീഡയറക്ട് നിയമമുണ്ടെങ്കിലും റൂട്ടിംഗ് ട്രാഫിക്കിനെ അതിന്റെ വശത്തുകൂടി അയയ്ക്കുന്ന ഹോസ്റ്റുകളിൽ നിശ്ശബ്ദമായി ഓപ്ഷൻ B പരാജയപ്പെടുന്നു.

ഏത് ഓപ്ഷനും ഉപകരണ ആവശ്യകത മാറ്റുന്നില്ല. കേർണൽ റൂട്ട് ചെയ്യുന്നതിന് മുമ്പ് പാക്കറ്റുകൾക്ക് ഇപ്പോഴും TUN അല്ലെങ്കിൽ TAP നോഡ് വേണം, അതിനാൽ പ്രക്രിയയ്ക്ക് ഇപ്പോഴും /dev/net/tun ൽ അനുമതി വേണം. ഒരു റാപ്പർ ആ നോഡ് തുറന്നതിന് ശേഷം എന്ത് സംഭവിക്കുന്നു എന്നത് മാറ്റുന്നു, നിങ്ങൾക്ക് അത് വേണോ എന്നതല്ല.

ഏത് പാതയാണ് നിർമ്മിച്ചതെന്ന് തെളിയിക്കുക

ട്രേ ഐക്കണിന് പകരം സോക്കറ്റുകൾ നോക്കുക. VPN പ്രക്രിയ പ്രോക്സി വിലാസത്തിലേക്ക് സ്ഥാപിതമായ കണക്ഷൻ നിലനിർത്തണം, പ്രോക്സി എത്തിച്ചേരാൻ ആവശ്യപ്പെട്ട ലക്ഷ്യം ലോഗ് ചെയ്തിരിക്കണം:

ss -tnp | grep openvpn

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

ഗതാഗതവും സ്വീകരിക്കുന്ന പ്രോക്സിയും ഈടുനിൽക്കുന്ന ഒരിടത്ത് കുറിച്ചുവയ്ക്കുക. അതേ പ്രൊഫൈൽ മറ്റൊരു നെറ്റ്‌വർക്കിൽ പരാജയപ്പെടുമ്പോൾ, ആ കുറിപ്പ് സെക്കൻഡുകൾക്കുള്ളിൽ പ്രോക്സിയെ ഒഴിവാക്കുകയോ സ്ഥിരീകരിക്കുകയോ ചെയ്യുന്നു.