നയ അടിസ്ഥാനമാക്കിയ റൂട്ടിംഗും SOCKS-ഉം: ഏത് പാളിയാണ് യഥാർത്ഥത്തിൽ ട്രാഫിക് പ്രോക്സി ചെയ്യുന്നത്

1080 പോർട്ടിൽ SOCKS ശ്രോതാവ് പ്രവർത്തിക്കുന്ന ഒരു ഹോസ്റ്റിലേക്ക് VPN ക്ലയന്റിന്റെ ട്രാഫിക് അയയ്ക്കുന്ന ഒരു നയ റൂട്ട് നിങ്ങൾ ചേർത്തു. പാക്കറ്റുകൾ എത്തുന്നു, ശ്രോതാവ് ഒന്നും രേഖപ്പെടുത്തുന്നില്ല, കണക്ഷൻ തൂങ്ങിക്കിടക്കുന്നു. റൂട്ടിൽ ഒന്നും തെറ്റില്ല: അടുത്ത ഹോപ്പ് പാക്കറ്റ് എവിടെ പോകുന്നു എന്ന് തിരഞ്ഞെടുക്കുന്നു, SOCKS ക്ലയന്റ് ആരംഭിക്കേണ്ട ഒരു സംഭാഷണമാണ്. പ്രോക്സി വഴി ട്രാഫിക് അയയ്ക്കുമ്പോൾ ആളുകൾ സാധാരണ അർത്ഥമാക്കുന്ന മൂന്ന് ആർക്കിടെക്ചറുകൾ താരതമ്യം ചെയ്യുക, നിങ്ങളുടെ സെറ്റപ്പിൽ ഏത് ഭാഗം കാണാനില്ലെന്ന് വ്യക്തമാകും.

റൂട്ടിംഗ്, DNAT, SOCKS എന്നിവ വ്യത്യസ്ത കാര്യങ്ങൾ മാറ്റുന്നു

ഒരു നയ റൂട്ട് ലെയർ 3 ന്റെ തീരുമാനം വീണ്ടും എഴുതുന്നു. ഒരു ക്ലയന്റിന്റെ ട്രാഫിക് തിരഞ്ഞെടുത്ത അടുത്ത ഹോപ്പിലേക്ക് അയയ്ക്കാൻ രണ്ട് വരികൾ മതി:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

അതിനുശേഷം കെർണൽ പാക്കറ്റ് 10.50.0.2-ലേക്ക് കൈമാറുന്നു, യഥാർത്ഥ ലക്ഷ്യസ്ഥാനം ഇപ്പോഴും IP ഹെഡറിൽ തന്നെയുണ്ട്. 10.50.0.2 ഒരു റൂട്ടർ ആണെങ്കിൽ അത് പാക്കറ്റ് കൈമാറുന്നു. 1080-ൽ SOCKS ഡീമൺ ഉള്ള ഒരു ഹോസ്റ്റ് ആണെങ്കിൽ, പാക്കറ്റ് അത് സ്വീകരിക്കാൻ കഴിയുന്ന ഒന്നിനും അഭിസംബോധന ചെയ്തിട്ടില്ല, കൂടാതെ 1080 പോർട്ടിലേക്കുള്ള DNAT-ഉം സഹായിക്കില്ല, കാരണം പരിവർത്തനം ചെയ്ത പാക്കറ്റ് ഇപ്പോഴും SOCKS അഭിവാദ്യത്തിന് പകരം യഥാർത്ഥ ആപ്ലിക്കേഷൻ പേലോഡ് വഹിക്കുന്നു.

SOCKS5 ഒരു പതിപ്പ് ബൈറ്റ്, രീതികളുടെ പട്ടിക, പ്രാമാണീകരണ കൈമാറ്റം, ലക്ഷ്യസ്ഥാനം പേരിടുന്ന ഒരു അഭ്യർത്ഥന എന്നിവയോടെ ആരംഭിക്കുന്നു. അത് ആപ്ലിക്കേഷൻ ഡാറ്റയാണ്. ഒരു റൂട്ടിംഗ് എൻട്രിയോ netfilter ലക്ഷ്യമോ അത് സൃഷ്ടിക്കുന്നില്ല, ഒരു വരിയിലെ താരതമ്യം ഇതാണ്: റൂട്ടിംഗ് ഒരു പാത തിരഞ്ഞെടുക്കുന്നു, SOCKS സെർവറിനോട് രണ്ടാമതൊരു കണക്ഷൻ ഉണ്ടാക്കാൻ ആവശ്യപ്പെടുന്നു.

ആദ്യ കേസ്: ആപ്ലിക്കേഷന് തന്നെ SOCKS സംസാരിക്കാം

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

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

പ്രോക്സി പരിസ്ഥിതി വേരിയബിളുകൾ അവഗണിക്കുന്ന അല്ലെങ്കിൽ അസംസ്കൃത സോക്കറ്റുകൾ തുറക്കുന്ന ആപ്ലിക്കേഷനുകളെ ഈ രീതിയിൽ സഹായിക്കാനാവില്ല. ബ്രൗസറുകളും മിക്ക HTTP ഉപകരണങ്ങളും കുഴപ്പമില്ല; ഗെയിം ക്ലയന്റ്, മെയിൽ ഡീമൺ അല്ലെങ്കിൽ വിതരണക്കാരന്റെ ഏതെങ്കിലും ബൈനറി സാധാരണയായി അല്ല. അതിർത്തി ഓരോ ആപ്ലിക്കേഷനും ഓരോ പ്രോട്ടോക്കോളിനും ആണ്, അതിനാലാണ് ഈ ഓപ്ഷൻ പരിശോധനയ്ക്ക് മികച്ചതും മുഴുവൻ VPN-നും ഉത്തരമായി ദുർബലവുമാകുന്നത്.

രണ്ടാം കേസ്: IP പ്രവാഹങ്ങളെ പ്രോക്സി സെഷനുകളാക്കി മാറ്റുന്ന അഡാപ്റ്റർ

SOCKS സംസാരിക്കാൻ കഴിയാത്ത പ്രോഗ്രാമുകൾക്ക്, പരിവർത്തനം IP ട്രാഫിക് അവസാനിപ്പിക്കുകയും അവരുടെ പേരിൽ പ്രോക്സി സെഷനുകൾ തുറക്കുകയും ചെയ്യുന്ന ഒന്നിൽ നടക്കണം. ആ ഘടകത്തിന് ഒരു ടണൽ ഇന്റർഫേസ് ഉണ്ട്, നയ റൂട്ടിംഗ് തിരഞ്ഞെടുത്ത പ്രവാഹങ്ങൾ സ്വീകരിക്കുന്നു, ഓരോന്നിനും SOCKS ഹാൻഡ്ഷേക്ക് ചെയ്യുന്നു, മറുപടികൾ വീണ്ടും നിർമ്മിക്കുന്നു. റൂട്ട് ട്രാഫിക്കിനെ അതിലേക്ക് നയിക്കുന്നു; സെഷൻ സൃഷ്ടിക്കുന്നത് അഡാപ്റ്ററാണ്.

ഒരു മുഴുവൻ സബ്നെറ്റും അതിനെ ഏൽപ്പിക്കുന്നതിന് മുമ്പ് അതിന്റെ ഡോക്യുമെന്റേഷൻ വായിക്കുക. പല അഡാപ്റ്ററുകളും TCP നന്നായി വഹിക്കുന്നു, UDP-യെ SOCKS5 UDP അസോസിയേഷൻ വഴി മാത്രം കൈകാര്യം ചെയ്യുന്നു, അവയൊന്നും ICMP-യെ പ്രോക്സി ട്രാഫിക്കാക്കി മാറ്റുന്നില്ല, അതിനാൽ വിജയകരമായ ഒരു ping പ്രോക്സി പാതയെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. DNS മറ്റൊരു കെണിയാണ്: അഡാപ്റ്റർ പേരുകൾ പ്രാദേശികമായി പരിഹരിക്കുകയാണെങ്കിൽ, ആന്തരിക രേഖകൾ മാത്രം തെറ്റായ ഉത്തരത്തിലേക്കോ ഒന്നുമില്ലാത്തതിലേക്കോ പരിഹരിക്കപ്പെടുന്നു.

ലൂപ്പ് തടയൽ എന്നത് കടിക്കുന്ന പ്രവർത്തന വിശദാംശമാണ്. SOCKS സെർവറിലേക്കുള്ള അഡാപ്റ്ററിന്റെ സ്വന്തം കണക്ഷനുകൾ വീണ്ടും അഡാപ്റ്ററിലേക്ക് റൂട്ട് ചെയ്യരുത്, അതിനാൽ അതിന്റെ ട്രാഫിക്കിന് നിയമത്തിൽ ഒരു ഒഴിവ് അല്ലെങ്കിൽ സമർപ്പിത സ്രോതസ്സ് വിലാസം വേണം. ഇത് തെറ്റായാൽ പ്രോക്സി സെഷൻ സ്വയം പ്രോക്സി ചെയ്യാൻ ശ്രമിക്കും.

മൂന്നാം കേസ്: ഹോസ്റ്റ് യഥാർത്ഥത്തിൽ റൂട്ട് ചെയ്ത ഗേറ്റ്വേ ആണ്

ചിലപ്പോൾ പ്രവർത്തിക്കുന്ന സെറ്റപ്പിൽ SOCKS ഒട്ടും ഉണ്ടാകില്ല. ദൂരെയുള്ള ഹോസ്റ്റ് പാക്കറ്റുകൾ കൈമാറുന്നു അല്ലെങ്കിൽ അവയ്ക്ക് NAT ചെയ്യുന്നു, സ്രോതസ്സ് അടിസ്ഥാനമാക്കിയ നിയമം അതിനെ പുറത്തുകടക്കാനുള്ള വഴിയായി തിരഞ്ഞെടുക്കുന്നു. ആ രൂപകൽപ്പന നിയമാനുസൃതമാണ്, പകർത്തിയ കോൺഫിഗറേഷൻ ഒരു നെറ്റ്വർക്കിൽ പ്രവർത്തിക്കുകയും മറ്റൊന്നിൽ പരാജയപ്പെടുകയും ചെയ്യുന്നതെന്തുകൊണ്ടെന്ന് അത് വിശദീകരിക്കുന്നു: നിയമം ഒന്നുതന്നെ, കാണാത്ത ഭാഗം അപ്പുറത്തുള്ള കൈമാറ്റ സേവനമാണ്.

മൂന്ന് കേസുകളും വേഗത്തിൽ വേർപെടുന്നു. യഥാർത്ഥത്തിൽ എന്താണ് കേൾക്കുന്നതെന്ന് പരിശോധിക്കുക, തുടർന്ന് ഹോസ്റ്റിലെത്തുന്ന ആദ്യ ബൈറ്റുകൾ നോക്കുക:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

യഥാർത്ഥ SOCKS ക്ലയന്റിന്റെ ആദ്യ പേലോഡ് ബൈറ്റ് 0x05 ആണ്, അഭിവാദ്യത്തിലെ പതിപ്പ്. ക്യാപ്ചർ പകരം യഥാർത്ഥ ആപ്ലിക്കേഷൻ ഡാറ്റ കാണിക്കുന്നുവെങ്കിൽ, ഒരു SOCKS ഡീമണും മറുപടി നൽകില്ല, കാരണം ചർച്ചകൾ ഒരിക്കലും ആരംഭിച്ചിട്ടില്ല. 1080-ൽ ഒന്നും കേൾക്കുന്നില്ലെങ്കിൽ, ഹോസ്റ്റ് ഒരു ഗേറ്റ്വേയാണ്, ചോദ്യം അത് കൈമാറുന്നുണ്ടോയെന്നും മടങ്ങിവരാനുള്ള വഴിയുണ്ടോയെന്നുമാകുന്നു.

നാല് ചോദ്യങ്ങളിലൂടെ പാളി തിരഞ്ഞെടുക്കുക

പ്രോഗ്രാമിന് ഒരു പ്രോക്സി ക്രമീകരണം ഉണ്ടോ? അത് ഉപയോഗിച്ച് അവിടെ നിർത്തുക. ട്രാഫിക്കിൽ അതിജീവിക്കേണ്ട UDP അല്ലെങ്കിൽ ICMP ഉണ്ടോ? ICMP വഹിക്കുന്നത് റൂട്ട് ചെയ്ത അല്ലെങ്കിൽ NAT ഗേറ്റ്വേ മാത്രമാണ്, UDP-യ്ക്ക് ഇരു വശങ്ങളും പിന്തുണയ്ക്കുന്ന ഒരു SOCKS5 അസോസിയേഷൻ വേണം. നിങ്ങൾക്ക് ക്രമീകരിക്കാൻ കഴിയാത്തവ ഉൾപ്പെടെ മെഷീനിലെ എല്ലാ പ്രോസസ്സുകളും ഉൾപ്പെടുത്തണോ? അപ്പോൾ ഇന്റർഫേസ് കൈവശം വയ്ക്കുകയും പ്രവാഹങ്ങൾ അവസാനിപ്പിക്കുകയും ചെയ്യുന്ന ഒരു അഡാപ്റ്റർ വേണം. അതിന്റെ റൂട്ടിംഗ്, DNS, ലൂപ്പ് തടയൽ ഒഴിവുകൾ എന്നിവയും നിങ്ങൾക്ക് ഏറ്റെടുക്കാമോ? ഇല്ലെങ്കിൽ, സാധാരണ ഗേറ്റ്വേ പ്രവർത്തിപ്പിക്കാൻ കുറച്ച് ചെലവാകും.

ഒരു വ്യത്യാസം നേരെയായി സൂക്ഷിക്കേണ്ടതുണ്ട്. VPN ക്ലയന്റിന്റെ സ്വന്തം socks-proxy ഓപ്ഷൻ പുറം ടണൽ കണക്ഷൻ അതിന്റെ സെർവറിലെത്തുന്നത് എങ്ങനെയെന്ന് വിവരിക്കുന്നു, ആന്തരിക ക്ലയന്റ് പ്രവാഹങ്ങളുടെ പരിവർത്തനത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. ഇവ രണ്ടും ഒരേ ടിക്കറ്റിൽ പലപ്പോഴും കൂട്ടിക്കുഴയ്ക്കുന്നു. ഒരു റൂട്ട് തൊടുന്നതിന് മുമ്പ് നിങ്ങൾക്ക് ഏത് ബന്ധം വേണമെന്ന് തീരുമാനിക്കുക.