SOCKS5-ൽ OpenVPN: പതിപ്പ്, ഗതാഗതം, DNS എന്നിവ ചേർക്കുക

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

ഫയർവാളിനു മുൻപ് SOCKS പതിപ്പ് ചേർക്കുക

സമൂഹ OpenVPN socks-proxy-നായി SOCKS5 സംസാരിക്കുന്നു. SOCKS4 മാത്രം നൽകുന്ന പ്രോക്സിയിലേക്ക് അതു തിരിച്ചാൽ TCP കണക്ഷൻ തുറന്നശേഷം നിശ്ചലമാകും, കാരണം മറുവശം ഒരിക്കലും പാഴ്സ് ചെയ്യാത്ത അഭിവാദ്യത്തിന് മറുപടി കാത്തിരിക്കുകയാണ് ക്ലയന്റ്. പുറത്തുനിന്ന് ഈ നിശ്ചലത ഫിൽട്ടർ ചെയ്ത പോർട്ടിനെപ്പോലെ കാണപ്പെടുന്നു, അതുകൊണ്ടാണ് പതിപ്പിന്റെ ചോദ്യം ഏതു ഫയർവാൾ നിയമത്തിനും മുൻപ് വരുന്നത്. SOCKS അറിയുന്ന ഒരു ഫെച്ച് അത് ഒരു കമാൻഡിൽ തീർക്കുന്നു.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

പൂർത്തിയായ അഭ്യർത്ഥന ഒരേസമയം രണ്ടു കാര്യം തെളിയിക്കുന്നു: പ്രോക്സി SOCKS അഭ്യർത്ഥന സ്വീകരിച്ചു, അത് പേര് വിശകലനം ചെയ്തു. URL സ്കീം ആവശ്യമില്ല, കാരണം curl നഗ്നമായ ഹോസ്റ്റിനെ HTTP ആയി കണക്കാക്കുന്നു, ഇത് ഈ പരീക്ഷണത്തിന് മതി.

ആ ഫെച്ച് ക്ലയന്റ് ലോഗ് മറയ്ക്കുന്ന പരാജയവും ഒഴിവാക്കുന്നു. പ്രോക്സിക്ക് ബ്രൗസറിന് അനുമതി നൽകിക്കൊണ്ടും VPN ലക്ഷ്യം നിരസിക്കാം, അപ്പോൾ നിരസിക്കൽ CONNECT-ൽ സംഭവിക്കുന്നു, ഏതു VPN പ്രാമാണീകരണത്തിനും മുൻപ്. OpenVPN സമയപരിധി മാത്രം അറിയിക്കുന്നു, അതിനാൽ പ്രോക്സിയുടെ സ്വന്തം മറുപടിയാണ് നിങ്ങൾക്കാവശ്യമായ തെളിവ്.

ഗതാഗതം ഇരുവശവും TCP ആയിരിക്കണം

SOCKS5 ഇവിടെ TCP സ്ട്രീം കൊണ്ടുപോകുന്നു, അതിനാൽ തുരങ്കത്തിനു തന്നെ proto tcp-client വേണം. ഇപ്പോഴും UDP-യിൽ ക്രമീകരിച്ച പ്രൊഫൈൽ ഈ വഴിയിൽ പ്രവർത്തിക്കില്ല, കാരണം ക്ലയന്റ് പ്രോട്ടോക്കോളിന്റെ UDP അസോസിയേഷൻ മോഡ് ഉപയോഗിക്കുന്നില്ല. പ്രൊഫൈൽ മറിച്ചിടുന്നത് യഥാർത്ഥ മാറ്റമാണ്, ഔപചാരികതയല്ല: വിദൂര വശം അതേ പോർട്ടിൽ TCP-യിൽ കേൾക്കണം. പിന്നീട് പേലോഡ് TCP-ക്കുള്ളിൽ TCP ആകുന്നു, അവിടെ നഷ്ടപ്പെട്ട സെഗ്മെന്റ് രണ്ടുതവണ വീണ്ടും അയയ്ക്കപ്പെടുന്നു, വേഗത കുറയുന്നു, ഇത് ഇന്ററാക്ടീവ് സെഷനുകൾ വലിയ കൈമാറ്റങ്ങളെക്കാൾ ഏറെ അനുഭവിക്കുന്നു.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

ഈ നിർദ്ദേശം പ്രോക്സി ഹോസ്റ്റ്, ഓപ്ഷണൽ പോർട്ട്, ഓപ്ഷണൽ ക്രെഡൻഷ്യൽ ഫയൽ എന്നിവ എടുക്കുന്നു. അവ പ്രൊഫൈലിൽ തന്നെ വയ്ക്കുക, മറ്റെവിടെയെങ്കിലും വച്ച പകർപ്പ് അതേപോലെ പ്രവർത്തിക്കും.

മുഴുവൻ ശൃംഖലയും ഒരു കണ്ടെയ്നറിൽ ഒതുക്കുക

ശൃംഖല ഹോസ്റ്റിൽ ചെയ്യുന്നത് അതിന്റെ സ്വതേയുള്ള പാത കൈക്കലാക്കി resolver-നെ പിന്നീട് ആർക്കും വിശദീകരിക്കാനാകാത്ത അവസ്ഥയിൽ വിടുന്നതാണ്. നാമസ്ഥലമോ കണ്ടെയ്നറോ അതിനെ ഒതുക്കുന്നു, അതിനാൽ ഹോസ്റ്റ് സ്വന്തം പാത സൂക്ഷിക്കുമ്പോൾ SOCKS ചുവടും തുരങ്കവും ഒരുമിച്ച് നിൽക്കുന്നു. അതിനുള്ളിൽ തുരങ്ക ഉപകരണം, ആ ഉപകരണം ക്രമീകരിക്കാനുള്ള അവകാശങ്ങൾ, എത്തിച്ചേരാവുന്ന പ്രോക്സി എന്നിവയില്ലാതെ ഒന്നും ഉയരുന്നില്ല. Compose സേവനം ഇത് cap_add: NET_ADMIN ഉം bind-മൗണ്ട് ചെയ്ത /dev/net/tun ഉം കൊണ്ട് നേടുന്നു.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

ഈ ജോടി കണ്ടെയ്നർ privileged ആയി ഓടിക്കുന്നതിനേക്കാൾ ഇടുങ്ങിയതാണ്, ഉപകരണ പ്രവേശനത്തിന്റെ ആവശ്യമായ മുഴുവൻ ഭാഗവും ഇത്രമാത്രം. Tor ക്ലയന്റോ വേറിട്ട പ്രോക്സി കണ്ടെയ്നറോ കേൾക്കുന്നയാളെ നൽകാം. രണ്ടു സാഹചര്യങ്ങളിലും അത് loopback-ൽ ബന്ധിക്കുക, പ്രോക്സി ശൃംഖലയിൽ തുറന്നുവയ്ക്കുന്നതിനു പകരം നാമസ്ഥലത്തുനിന്ന് ഹോസ്റ്റിലൂടെ അതിൽ എത്തുക.

പേര് വിശകലനമാണ് ഒറ്റപ്പെടുത്തൽ പരാജയപ്പെടുന്ന ഇടം

പാക്കറ്റുകൾ കൊണ്ടുപോകുകയും എന്നാൽ ഹോസ്റ്റിന്റെ resolver-നോട് ചോദിക്കുകയും ചെയ്യുന്ന തുരങ്കം ഒന്നും ഒറ്റപ്പെടുത്തിയിട്ടില്ല. രണ്ടു കാര്യങ്ങൾ ഒറ്റപ്പെടുത്തലിനെ യഥാർത്ഥമാക്കുന്നു: നാമസ്ഥലത്തിന് സ്വന്തം resolver ഉണ്ടായിരിക്കുക, അതിന്റെ ചോദ്യങ്ങൾ പ്രോക്സിയിലൂടെയോ തുരങ്കത്തിലൂടെയോ പോകുക, ഒരിക്കലും ഭൗതിക ഇന്റർഫേസിലൂടെ പോകാതിരിക്കുക. പരീക്ഷണത്തിന് രണ്ടു പേരുകൾ ഉപയോഗിക്കുക: ഒന്ന് തുരങ്കത്തിനു പിന്നിൽ മാത്രം നിലനിൽക്കുന്നത്, മറ്റൊന്ന് അതേ പാത പിന്തുടരേണ്ട പൊതു നാമം.

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

വിദൂര പേര് വിശകലനം ചെയ്യപ്പെടുകയും പൊതു പേര് അല്ലാതിരിക്കുകയും ചെയ്താൽ, ശൃംഖല തിരഞ്ഞെടുക്കപ്പെട്ടതാണ്, തകർന്നതല്ല, വ്യത്യാസം ഓരോ ചോദ്യവും ഏതു പാത എടുത്തു എന്നു പറയുന്നു. രണ്ടും ഹോസ്റ്റിൽനിന്ന് വിശകലനം ചെയ്യപ്പെടുകയും കണ്ടെയ്നറിനുള്ളിൽ ഒന്നും അല്ലാതിരിക്കുകയും ചെയ്താൽ, കണ്ടെയ്നർ ഇപ്പോഴും ഹോസ്റ്റിന്റെ resolver കടം വാങ്ങുന്നു. കണ്ടെത്തിയ resolver ഫയൽ രേഖപ്പെടുത്തുക, കാരണം അതാണ് മാറ്റേണ്ട ക്രമീകരണം.

ഓരോ ചുവടും ക്രമത്തിൽ തെളിയിക്കുക

പട്ടിക ചെറുതാണ്. SOCKS5 അഭ്യർത്ഥനയ്ക്ക് മറുപടി ലഭിക്കുന്നു, തുരങ്കം പ്രോക്സിയിലൂടെ തന്റെ കേൾക്കുന്നയാളെ എത്തുന്നു, നാമസ്ഥലത്തുനിന്ന് പുറത്തുപോകുന്ന പാക്കറ്റുകൾ വിദൂര വശം പ്രതീക്ഷിക്കുന്ന വിലാസം കൊണ്ടുപോകുന്നു. കൂടുതൽ ക്രമീകരണങ്ങൾ അടുക്കിവയ്ക്കുന്നതിനു പകരം ഓരോന്നും വെവ്വേറെ സ്ഥിരീകരിക്കുക. ക്ലയന്റ് കണക്ട് ചെയ്തു, ഒന്നും നീങ്ങുന്നില്ല എന്നു പറയുമ്പോൾ, തകരാർ മിക്കവാറും രണ്ടാമത്തെയോ മൂന്നാമത്തെയോ വസ്തുതയിലാണ്.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

പ്രവർത്തിച്ച സംയോജനം എഴുതിവയ്ക്കുക: SOCKS പതിപ്പ്, ഗതാഗതം, resolver, നാമസ്ഥല ക്രമീകരണങ്ങൾ. ഈ ശൃംഖല രണ്ടാം തവണ ഓർമയിൽനിന്ന് പരിഹരിക്കുന്നത് കുറിപ്പിനെക്കാൾ ചെലവേറിയതാണ്. ആ നാലു വസ്തുതകൾ ടിക്കറ്റിൽ സൂക്ഷിക്കുക, ചാറ്റ് ത്രെഡിൽ അല്ല.

കണക്ട് ചെയ്തു എന്നു പറയുകയും ഒന്നും കടത്തിവിടാതിരിക്കുകയും ചെയ്യുന്ന ശൃംഖല, നിങ്ങൾ ഇനിയും തെളിയിക്കാത്ത ചുവട്ടിലാണ് സാധാരണയായി പരാജയപ്പെട്ടിട്ടുണ്ടാകുക. മറ്റൊരു പാളി ചേർക്കുന്നതിന് മുൻപ് ആ ചുവട് പരീക്ഷിക്കുക.