Tor റിലേയും VPN സെർവറും: എന്തുകൊണ്ട് ഇവ പരസ്പരം പകരമല്ല

നിങ്ങൾക്ക് ഒരു വിലാസമുണ്ട്, പോർട്ട് പ്രതികരിക്കുന്നു, ഒരു ക്ലയന്റ് ഒരു പരാതിയുമില്ലാതെ അത് സ്വീകരിക്കുന്നു. ഇവയൊന്നും Tor റിലേയെ VPN എൻഡ്‌പോയിന്റാക്കുന്നില്ല, ഈ തെറ്റ് ചെലവേറിയതാണ്, കാരണം പ്രൊഫൈൽ വൃത്തിയായി ഇംപോർട്ട് ചെയ്യപ്പെടുന്നു, പിന്നീട് ഹാൻഡ്‌ഷേക്കിൽ പരാജയപ്പെടുന്നു. ഞാൻ താഴെയുള്ള നാല് പരിശോധനകൾ ക്രമത്തിൽ ഉപയോഗിക്കുന്നു; ഓരോന്നിനും നിർത്താനുള്ള വ്യവസ്ഥയുണ്ട്, നേരത്തെ നിർത്തുന്നതാണ് കാര്യം. ആദ്യ പരിശോധന പരാജയപ്പെട്ടാൽ, ബാക്കിയുള്ളവ നിങ്ങളെ സഹായിക്കില്ല.

പോർട്ട് യഥാർത്ഥത്തിൽ എന്ത് സേവനം നൽകുന്നു എന്ന് പരിശോധിക്കുക

തുറന്ന പോർട്ട് ഒരു ശ്രോതാവിന്റെ സാന്നിധ്യം തെളിയിക്കുന്നു, അത്രമാത്രം. ഒരു റിലേയുടെ ORPort TLS ഹാൻഡ്‌ഷേക്കിന് ശേഷം Tor ന്റെ സ്വന്തം സെല്ലുകളുമായി സംസാരിക്കുന്നു, അതിനാൽ വിജയകരമായ TLS പരിശോധന അവിടെ VPN പ്രോട്ടോക്കോൾ സ്വീകരിക്കപ്പെടുന്നുണ്ടോ എന്നതിനെക്കുറിച്ച് ഏതാണ്ട് ഒന്നും പറയുന്നില്ല:

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

സർട്ടിഫിക്കറ്റ് ഉണ്ടോ എന്നതല്ല, സർട്ടിഫിക്കറ്റ് തന്നെ വായിക്കുക. റിലേകൾ ബോധപൂർവം ശ്രദ്ധിക്കപ്പെടാത്ത പേരുള്ള സ്വയം-ഒപ്പിട്ട സർട്ടിഫിക്കറ്റ് അവതരിപ്പിക്കുന്നു, കാരണം റിലേ ട്രാഫിക് സാധാരണ HTTPS പോലെ തോന്നണം; എന്നാൽ VPN സെർവറിന്റെ സർട്ടിഫിക്കറ്റ് നിങ്ങളുടെ പ്രൊഫൈൽ പ്രതീക്ഷിക്കുന്ന പേര് വഹിക്കുന്നു. എതിർവശം VPN പ്രോട്ടോക്കോളിന്റെ ആദ്യ പാക്കറ്റിന് ഒരിക്കലും പ്രതികരിക്കുന്നില്ലെങ്കിൽ, പ്രൊഫൈൽ എത്ര എഡിറ്റ് ചെയ്താലും ഫലം മാറില്ല.

നിങ്ങളുടെ ക്ലയന്റ് അയയ്ക്കുന്ന ഹാൻഡ്‌ഷേക്ക് വിലാസം പൂർത്തിയാക്കുന്നില്ലെങ്കിൽ ഇവിടെ നിർത്തുക. അത് പ്രോട്ടോക്കോളിന്റെ ഉത്തരമാണ്, കോൺഫിഗറേഷൻ പ്രശ്നമല്ല, ഇംപോർട്ട് ചെയ്ത പ്രൊഫൈൽ എന്നെന്നും 'connecting' എന്ന നിലയിൽ തുടരാനുള്ള ഏറ്റവും സാധാരണ കാരണം അതാണ്.

നെറ്റ്‌വർക്കിന്റെ വലിപ്പമല്ല, റിലേയുടെ പങ്ക് പരിശോധിക്കുക

റിലേ പങ്കുകൾ വ്യത്യസ്ത ജോലികൾ ചെയ്യുന്നു. Guard ക്ലയന്റുകൾക്കുള്ള ആദ്യ ചുവടാണ്, മധ്യ റിലേ മറ്റ് റിലേകൾക്കിടയിൽ സർക്യൂട്ടുകൾ കൈമാറുന്നു, exit ലക്ഷ്യസ്ഥാനങ്ങളെ സ്പർശിക്കുന്ന പങ്കാണ്, പാലം BridgeDB വഴി വിതരണം ചെയ്യുന്ന സ്വകാര്യമല്ലാത്ത പ്രവേശന കേന്ദ്രമാണ്. Tor ന്റെ പദാവലി ഈ നിർവചനങ്ങൾ വേർതിരിച്ച് സൂക്ഷിക്കുന്നു, ലഭ്യത ഓരോ പങ്കിന്റെയും ഭാഗമാണ്, എന്നാൽ ഏകപക്ഷീയ ക്ലയന്റുകൾക്ക് സേവനം നൽകാനുള്ള അനുമതി അവയൊന്നിന്റെയും ഭാഗമല്ല.

exit നയം വായിക്കേണ്ടതാണ്, കാരണം കൈമാറ്റ നിയമത്തോട് സാമ്യമുള്ള ഏക ഭാഗം അതാണ്, ഒപ്പം exit പുറത്തേക്ക് പോകാൻ അനുവദിക്കുന്ന ലക്ഷ്യസ്ഥാനങ്ങളെ അത് നിയന്ത്രിക്കുന്നു, അകത്തേക്ക് പ്രവേശിക്കാൻ അനുവദിക്കുന്ന ക്ലയന്റുകളെയല്ല. പോർട്ട് 25 തടയുന്ന കർശനമായ exit നയം പുറത്തേക്കുള്ള ദുരുപയോഗ നിയന്ത്രണത്തെക്കുറിച്ച് എന്തോ പറയുന്നു, OpenVPN ക്ലയന്റിനെ യന്ത്രത്തിലേക്ക് അയക്കാമോ എന്നതിനെക്കുറിച്ചല്ല.

പ്രശസ്തിയിൽ നിന്ന് അനുമാനിക്കുകയാണെങ്കിൽ നിർത്തുക: റിലേകൾ ട്രാഫിക് കൈമാറ്റം ചെയ്യുന്നതിനാൽ, വിലാസം നിങ്ങളുടേത് സ്വീകരിക്കണം. Tor സമവായത്തിലൂടെയും സ്വന്തം പ്രോട്ടോക്കോളിലൂടെയും പാതകൾ തിരഞ്ഞെടുക്കുന്നു; VPN ക്ലയന്റ് പങ്കാളിയല്ല, ചേരാനുള്ള സർക്യൂട്ടും അതിനില്ല.

SOCKS ശ്രോതാവ് പ്രാദേശികമാണോ പൊതുവാണോ എന്ന് പരിശോധിക്കുക

Tor ക്ലയന്റ് അതേ യന്ത്രത്തിലെ അപ്ലിക്കേഷനുകൾക്കായി SOCKS ഇന്റർഫേസ് വെളിപ്പെടുത്തുന്നു, സ്വതവേ loopback ൽ. ആ ശ്രോതാവ് പ്രാദേശിക സൗകര്യമാണ്, റിലേ ഇന്റർനെറ്റിന് നൽകുന്ന സേവനമല്ല, അതിനെ പൊതു പ്രോക്സിയായി കാണുന്നതാണ് ആളുകൾ ഉദ്ദേശിക്കാതെ തുറന്ന റിലേ പ്രവർത്തിപ്പിക്കുന്നതിൽ എത്തുന്ന വഴി:

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

ബൈൻഡ് വിലാസമാണ് സൂചന. 127.0.0.1:9050 ലുള്ള SocksPort അതിന്റെ ജോലി ചെയ്യുന്നു; 0.0.0.0 ൽ കേട്ട് പുറത്തുനിന്ന് എത്തിപ്പെടാവുന്നത് തുറന്ന പ്രോക്സിയാണ്, Tor ന്റെ സ്വന്തം ആക്സസ് നയ നിയന്ത്രണങ്ങൾ ഉള്ളത് ആ വെളിപ്പെടുത്തൽ സവിശേഷതയല്ല, പ്രശ്നമായതുകൊണ്ടാണ്.

Tor ആവശ്യമുള്ള അപ്ലിക്കേഷനെ loopback പോർട്ടിലേക്ക് തിരിച്ചുവിട്ട് പേരുകൾ Tor പരിഹരിക്കാൻ അനുവദിക്കുക, മുകളിലുള്ള socks5h രൂപം അതാണ് ചെയ്യുന്നത്. ആ പോർട്ടിന് റിലേയുടെ വിലാസം പകരം വയ്ക്കരുത്; നിങ്ങളുടെ അപ്ലിക്കേഷൻ ആവശ്യപ്പെടുന്ന ഇന്റർഫേസ് റിലേ നൽകുന്നില്ല.

VPN പ്രൊഫൈൽ യഥാർത്ഥ എൻഡ്‌പോയിന്റുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക

VPN പ്രൊഫൈൽ പ്രതീക്ഷകളുടെ കെട്ടാണ്: OpenVPN-ന് സെർവർ സർട്ടിഫിക്കറ്റ് അല്ലെങ്കിൽ CA, ക്ലയന്റ് സർട്ടിഫിക്കറ്റും കീയും, സാധാരണയായി TLS കീയും ആവശ്യമാണ്, അതേസമയം WireGuard-ന് എതിർവശത്തിന്റെ പൊതു കീ, എൻഡ്‌പോയിന്റ്, അനുവദിച്ച IP എന്നിവ ആവശ്യമാണ്. ഇവയൊന്നും വിലാസത്തിൽ നിന്നും തുറന്ന പോർട്ടിൽ നിന്നും കണ്ടെത്താനാവില്ല, അതുകൊണ്ടാണ് ഇങ്ങനെ നിർമ്മിച്ച പ്രൊഫൈൽ ബന്ധിപ്പിക്കുമ്പോഴല്ല, ആദ്യ കൈമാറ്റത്തിൽ പരാജയപ്പെടുന്നത്.

നിങ്ങൾക്ക് ഒരു പ്രൊഫൈൽ നൽകുമ്പോൾ, നിങ്ങൾ നിയന്ത്രിക്കുന്ന എൻഡ്‌പോയിന്റിനോ തിരിച്ചറിയാവുന്ന ദാതാവിനോ എതിരായി അത് പരിശോധിക്കുക:

wg show
openvpn --config client.ovpn --verb 4

OpenVPN ലോഗിൽ TLS ചർച്ചയുടെ പിശക് പൊരുത്തക്കേട് നേരിട്ട് പേരിടുന്നു; wg show ൽ ഹാൻഡ്‌ഷേക്ക് വരിയില്ലാത്ത എതിർവശം ഒരിക്കലും ഒന്നും പൂർത്തിയാക്കിയിട്ടില്ല. രണ്ടും ക്ലയന്റിന്റെ കറങ്ങുന്ന സൂചകത്തേക്കാൾ വിവരം നൽകുന്നു, രണ്ടും Tor ലേക്കല്ല, കീ സാമഗ്രികളിലേക്കോ പ്രോട്ടോക്കോളിലേക്കോ സൂചിപ്പിക്കുന്നു.

യഥാർത്ഥത്തിൽ ഏത് സംരക്ഷണമാണ് നിങ്ങൾക്ക് വേണ്ടതെന്ന് പരിശോധിക്കുക

ഇതാണ് ആർക്കിടെക്ചർ നിർണ്ണയിക്കുന്ന പരിശോധന. Tor ബ്രൗസർ VPN നൽകാത്ത സർക്യൂട്ട് ഐസൊലേഷനും വിരലടയാള പ്രതിരോധവും നൽകുന്നു; VPN ലക്ഷ്യസ്ഥാനം കാണുന്ന വിലാസം മാറ്റുകയും ദാതാവിനോട് നിങ്ങളെ അംഗീകരിക്കുകയും ചെയ്യുന്നു. ഇവ തമ്മിൽ തിരഞ്ഞെടുക്കുന്നത് ഭീഷണി മാതൃകയുടെ ചോദ്യമാണ്, അനുയോജ്യതയുടെ ചോദ്യമല്ല, ഇവ കൂട്ടിക്കലർത്തുന്നത് സ്വകാര്യമായി തോന്നുന്നതും അല്ലാത്തതുമായ ക്രമീകരണം സൃഷ്ടിക്കുന്നു.

ചെയിനിംഗിന് ഒരു ക്രമമുണ്ട്. Tor ട്രാഫിക് വഹിക്കുന്ന VPN പിന്തുണയ്ക്കുന്ന ക്രമീകരണമാണ്, കാരണം Tor ക്ലയന്റിന് പുറത്തേക്കുള്ള TCP മാത്രം ആവശ്യമാണ്. Tor നുള്ളിൽ ടണൽ ചെയ്ത VPN ക്ലയന്റ് അതേ കാര്യമല്ല, Tor ക്ലയന്റ് നടപ്പിലാക്കുന്നതും അതല്ല, അതിനാൽ അതിന്റെ അടിസ്ഥാനത്തിൽ ആസൂത്രണം ചെയ്യരുത്.

എന്തെങ്കിലും ഇംപോർട്ട് ചെയ്യുന്നതിന് മുമ്പ്, നാലും സ്ഥിരീകരിക്കുക:

• പോർട്ട് നിങ്ങളുടെ പ്രോട്ടോക്കോളിന്റെ ഹാൻഡ്‌ഷേക്ക് പൂർത്തിയാക്കുന്നു, വെറും TCP കണക്ഷനല്ല.
• ഹോസ്റ്റിന്റെ പങ്ക് നിങ്ങൾക്ക് അറിയാം, കൈമാറ്റത്തെ അനുമതിയായി കാണുന്നില്ല.
• നിങ്ങൾ ഉപയോഗിക്കുന്ന SOCKS ശ്രോതാവ് loopback ഉം നിങ്ങളുടേതുമാണ്, മറ്റൊരാളുടെ റിലേയിലെ പൊതു പോർട്ടല്ല.
• പ്രൊഫൈലിന്റെ കീകളോ സർട്ടിഫിക്കറ്റുകളോ നിങ്ങൾ ബന്ധിപ്പിക്കുന്ന എൻഡ്‌പോയിന്റിന്റേതാണ്.