സുതാര്യ TCP-മുതൽ-SOCKS കൈമാറ്റത്തിലെ യഥാർത്ഥ ലക്ഷ്യസ്ഥാനങ്ങൾ

ഫയർവാൾ ഒരു TCP ബന്ധം എവിടെ എത്തുന്നു എന്നത് മാറ്റാം. എന്നാൽ ആ മാറ്റം കൊണ്ട് മാത്രം ഉത്ഭവ ആപ്ലിക്കേഷനെ SOCKS സംസാരിക്കാൻ പഠിപ്പിക്കാൻ അതിനാകില്ല.

സാധാരണ SOCKS സെർവർ ആവശ്യപ്പെട്ട ലക്ഷ്യസ്ഥാനം വിവരിക്കുന്ന ചർച്ച പ്രതീക്ഷിക്കുന്നു. പ്രോക്സി അറിയാത്ത ആപ്ലിക്കേഷൻ പകരം സ്വന്തം പ്രോട്ടോക്കോൾ ബൈറ്റുകൾ ഉടൻ അയയ്ക്കുന്നു. ആ ബൈറ്റുകൾ നേരിട്ട് ഒരു SOCKS ശ്രോതാവിലേക്ക് തിരിച്ചുവിട്ടാൽ ഇരുപക്ഷവും ആദ്യ സന്ദേശത്തിൽ യോജിക്കില്ല.

കാണാത്ത ഘടകം ഒരു വിവർത്തകനാണ്

സുതാര്യ TCP-മുതൽ-പ്രോക്സി ഘടകം ആ ഇന്റർഫേസുകൾക്കിടയിൽ ഇരിക്കുന്നു. ആപ്ലിക്കേഷൻ ആദ്യം ആവശ്യപ്പെട്ട ലക്ഷ്യസ്ഥാനം അത് കണ്ടെത്തുന്നു, ഉചിതമായ SOCKS അല്ലെങ്കിൽ HTTP CONNECT സെഷൻ സ്ഥാപിക്കുന്നു, തുടർന്ന് ആപ്ലിക്കേഷൻ ഡാറ്റ ഫലമായ സ്ട്രീമിലൂടെ കൈമാറുന്നു.

അതിന്റെ Linux iptables പാതയിൽ, redsocks സ്രോതസ്സ് സംരക്ഷിച്ച ലക്ഷ്യസ്ഥാനം SO_ORIGINAL_DST ഉപയോഗിച്ച് വീണ്ടെടുക്കുന്നു. മറ്റ് ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങളും റീഡയറക്ഷൻ രീതികളും വ്യത്യസ്ത സംവിധാനങ്ങൾ ഉപയോഗിക്കുന്നു. ഇത് റീഡയറക്ടറുടെയും നെറ്റ്വർക്ക് ക്രമീകരണത്തിന്റെയും സ്വഭാവമാണ്, സാധാരണ SOCKS ക്ലയന്റിന്റെ സവിശേഷതയല്ല.

യഥാർത്ഥ ലക്ഷ്യസ്ഥാനത്തെക്കുറിച്ചുള്ള വിവരം, റീഡയറക്ഷൻ നിയമം പ്രോക്സി ഹോസ്റ്റിൽ നിന്ന് അസംബന്ധമായ ഗേറ്റ്‌വേയിലേക്ക് മാറ്റുന്നത് എന്തുകൊണ്ട് എപ്പോഴും തുല്യമല്ല എന്നും വിശദീകരിക്കുന്നു. സ്വീകരിക്കുന്ന പ്രക്രിയയ്ക്ക് അതിന്റെ തടഞ്ഞുവയ്ക്കൽ രീതി ആവശ്യപ്പെടുന്ന മെറ്റാഡാറ്റ വേണം. മറ്റെവിടെയോ മാറ്റിയെഴുതിയ വിലാസം ആ വിവരം പ്രതീക്ഷിച്ച രൂപത്തിൽ ഇനി നൽകാനിടയില്ല.

വിവർത്തകന്റെ പരിധി വ്യക്തമായി സൂക്ഷിക്കുക. പ്രവർത്തിക്കുന്ന റീഡയറക്ട് ചെയ്ത TCP ബന്ധം ഏതെങ്കിലും UDP, ICMP അല്ലെങ്കിൽ ഓരോ റിസോൾവർ പാതയ്ക്കുമുള്ള പിന്തുണ തെളിയിക്കുന്നില്ല. അപ്‌സ്ട്രീം പ്രോക്സി പ്രോട്ടോക്കോളും വിവർത്തകന്റെ നടപ്പാക്കലും പിന്തുണയ്ക്കുന്ന പ്രവർത്തനങ്ങൾ ഇപ്പോഴും നിർവചിക്കുന്നു.

ബന്ധത്തിന് ഉടൻ ശേഷം ഒരു ക്രമീകരണം പരാജയപ്പെട്ടാൽ, ആക്‌സസ് നിയമങ്ങൾ വിശാലമാക്കുന്നതിന് മുമ്പ് പ്രോട്ടോക്കോൾ അതിർത്തി പരിശോധിക്കുക. പൂർണ്ണമായി എത്തിച്ചേരാവുന്ന SOCKS ശ്രോതാവിനും ഒരിക്കലും SOCKS അഭ്യർത്ഥനയല്ലാതിരുന്ന ബൈറ്റുകൾ നിരസിക്കാം.