IPv6 മാത്രം കണക്ഷൻ, IPv4 സേവനം: SOCKS പ്രോക്സിയെ പാലമാകാൻ അനുവദിക്കുക
SOCKS പ്രോക്സി ഒരു കണക്ഷൻ സ്വീകരിച്ച് മറ്റൊന്ന് തുറക്കുന്നു, അതിനാൽ IPv6 മാത്രമുള്ള ക്ലയന്റ് IPv4 സേവനത്തിൽ എത്തുന്നു. ഇത് റിലേയാണ്, സ്വദേശീയ IPv4 പ്രവേശനമല്ല.
ലക്ഷ്യത്തിന്റെ വിലാസ കുടുംബത്തിലെ വിലാസം ഇല്ലാതെയും അതിൽ എത്താം, വഴിയിൽ എന്തെങ്കിലും റിലേ ചെയ്യാൻ തയ്യാറാണെങ്കിൽ. അപ്ലിക്കേഷൻ പ്രോക്സിയിലേക്ക് ബന്ധിപ്പിക്കുന്നു, പ്രോക്സി ലക്ഷ്യത്തിലേക്ക് രണ്ടാമത്തെ കണക്ഷൻ തുറക്കുന്നു. ഇവ സ്വതന്ത്ര വിലാസ കുടുംബങ്ങളുള്ള രണ്ട് സോക്കറ്റുകളാണ്, ഏത് പ്രോട്ടോക്കോളും അവ ഒത്തുപോകണമെന്ന് ആവശ്യപ്പെടുന്നില്ല. ഇത് അപ്ലിക്കേഷൻ തലത്തിലെ റിലേയാണ്, സ്വദേശീയ IPv4 പാതയല്ല, ഈ വ്യത്യാസമാണ് എന്ത് പ്രവർത്തിക്കും എന്ത് പ്രവർത്തിക്കില്ല എന്ന് തീരുമാനിക്കുന്നത്. രണ്ടും കൂട്ടിക്കലർത്തുന്നതാണ് ലാപ്ടോപ്പിന് IPv4 കണക്റ്റിവിറ്റി ഉണ്ടെന്ന് വിവരിക്കാനുള്ള കാരണം, അതിൽ ഉള്ളത് ഒരു പ്രോക്സി മാത്രമാണെങ്കിലും.
രണ്ട് സോക്കറ്റുകൾ, രണ്ട് വിലാസ കുടുംബങ്ങൾ
SOCKS5 അഭ്യർത്ഥന ലക്ഷ്യത്തെ മൂന്ന് രൂപങ്ങളിൽ ഒന്നിൽ പേരിടുന്നു: അക്ഷരാർത്ഥ v4 വിലാസം, അക്ഷരാർത്ഥ v6 വിലാസം, അല്ലെങ്കിൽ പ്രോക്സി പരിഹരിക്കേണ്ട ഒരു പേര്. അഭ്യർത്ഥന പ്രോക്സി എവിടെ ബന്ധിപ്പിക്കണം എന്ന് വിവരിക്കുന്നു, ക്ലയന്റ്-പ്രോക്സി കണക്ഷൻ എങ്ങനെയിരിക്കും എന്നല്ല.
ഈ വിലാസ തരങ്ങളെ ഒരു സന്ദേശത്തിനുള്ളിലെ മൂന്ന് സ്വതന്ത്ര തിരഞ്ഞെടുപ്പുകളായി വായിക്കുക. IPv6 വഴി എത്താവുന്ന പ്രോക്സിക്ക് പ്രവർത്തിക്കുന്ന IPv4 എക്സിറ്റും അതിന്റെ നയം അഭ്യർത്ഥന അനുവദിക്കുകയും ചെയ്യുമ്പോൾ IPv4 ലക്ഷ്യ സോക്കറ്റ് തുറക്കാം. SOCKS5 വിവരണം ക്ലയന്റിന്റെ ഗതാഗതത്തെക്കുറിച്ച് ഒരു പരാമർശവുമില്ലാതെ അവ നിർവചിക്കുന്നു.
നിയന്ത്രിത SSH ഉദാഹരണം
ഉപയോഗിക്കാൻ അനുമതിയുള്ള ഒരു SSH ഹോസ്റ്റ് എടുക്കുക, അത് IPv6-ൽ ഉത്തരം നൽകുന്നു, സ്വയം v4-ൽ മാത്രം നിലനിൽക്കുന്ന HTTPS സേവനത്തിൽ എത്താനും കഴിയും. OpenSSH-ന്റെ ചലനാത്മക ഫോർവേഡിംഗ് ലോഗിൻ സെഷൻ v6 വഴി പോകുമ്പോൾ നിങ്ങളുടെ മെഷീനിൽ ഒരു പ്രാദേശിക SOCKS ശ്രോതാവ് ഇടുന്നു.
ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]മുകളിലെ ഹോസ്റ്റും അക്കൗണ്ടും ഉദാഹരണങ്ങളാണ്, ലൂപ്ബാക്ക് ബൈൻഡിംഗ് ശ്രോതാവിനെ ഈ കമ്പ്യൂട്ടറിൽ നിർത്തുന്നു. ഓഫീസിന് ഓതന്റിക്കേഷനില്ലാത്ത പ്രോക്സി പങ്കിടാൻ അതിനെ വൈൽഡ്കാർഡ് ബൈൻഡിംഗ് കൊണ്ട് മാറ്റരുത്. ExitOnForwardFailure=yes പരാജയപ്പെട്ട ഫോർവേഡിംഗ് സെഷൻ അവസാനിപ്പിക്കാൻ ഉള്ളതാണ്, പിന്നണിയിൽ നിശബ്ദമായ കമാൻഡ് ഓടാൻ വിടാനല്ല.
സെഷൻ പ്രവർത്തിക്കുമ്പോൾ അഭ്യർത്ഥന ഇങ്ങനെയിരിക്കും:
curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/ലൂപ്ബാക്ക് കണക്ഷൻ IPv4 ഇന്റർനെറ്റ് പാതയല്ല. നിങ്ങളുടെ മെഷീനിൽ നിന്ന് പുറത്തുപോകുന്നത് v6 വഴിയുള്ള ലോഗിൻ സെഷനാണ്, ലക്ഷ്യ സോക്കറ്റ് തുറക്കുന്നത് അകലെയുള്ള വശമാണ്. socks5h രൂപം പേര് പരിഹരിക്കലും ആ വശത്തിന് നൽകുന്നു, ക്ലയന്റിന് സ്വന്തം IPv4 പരിഹാരക പാത ഇല്ലാത്തപ്പോൾ ഇത് പ്രധാനമാണ്.
ലക്ഷ്യം യഥാർത്ഥത്തിൽ കാണുന്നത്
ലക്ഷ്യം റിലേയുടെ എക്സിറ്റ് വിലാസം കാണുന്നു. നിങ്ങളുടെ ലാപ്ടോപ്പിനുള്ള ഒരു വിലാസവും അവിടെ കാണുന്നില്ല. ആ സേവനത്തിലെ ഉറവിട-അനുമതി പട്ടികയിൽ റിലേയുടെ പേര് ഉണ്ടായിരിക്കണം. അതിന്റെ ലോഗുകളും ട്രാഫിക് റിലേയ്ക്ക് ആരോപിക്കും. ഓഡിറ്റിന് മുമ്പ് ഇത് മാറ്റരേഖയിൽ എഴുതുക, കാരണം ക്ലയന്റ് വിലാസങ്ങൾക്ക് ചുറ്റുമായി നിർമ്മിച്ച അനുമതി പട്ടിക ആദ്യ അഭ്യർത്ഥനയിൽത്തന്നെ പരാജയപ്പെടും.
സംഭാഷണത്തിന്റെ രണ്ട് പകുതികൾ കാണാവുന്ന സ്ഥലം കൂടിയാണ് റിലേ, ഇത് രോഗനിർണയത്തിൽ ഉപയോഗപ്രദമായ സ്വഭാവവും നയമില്ലാതെ റിലേ പങ്കിട്ടാൽ ഭാരവുമാണ്.
ഇത് DNS64 അല്ലെങ്കിൽ NAT64 അല്ല
DNS64 v4 ലക്ഷ്യങ്ങൾക്ക് പകരമായി സംശ്ലേഷിത റെക്കോർഡുകൾ നൽകി ഉത്തരം നൽകുന്നു, NAT64 ക്രമീകരിച്ച പാതയിലൂടെ പാക്കറ്റുകൾ തിരുത്തിയെഴുതുന്നു. ഇവിടെ സംഭവിക്കുന്നത് ഇവയൊന്നും വിവരിക്കുന്നില്ല, ഒരു ഗതാഗത സംഭാഷണം അവസാനിച്ച് മറ്റൊന്ന് തുടങ്ങുന്നിടത്ത് സംശ്ലേഷിത വിലാസം ഫലം വിശദീകരിക്കുന്നുമില്ല. അതിനാൽ വിജയകരമായ അഭ്യർത്ഥന നിങ്ങളുടെ ദാതാവ് ഏത് വിവർത്തന സേവനങ്ങൾ നടത്തുന്നു എന്നതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, പ്രോക്സി സ്വന്തം എക്സിറ്റിൽ സാധാരണ NAT പ്രവർത്തിപ്പിച്ചേക്കാം.
രണ്ട് സംവിധാനങ്ങളും ഒരേ നെറ്റ്വർക്കിൽ നിലനിൽക്കാം, അതിനാൽ ഏറ്റവും അടുത്ത് കേൾക്കുന്നതല്ല, നിങ്ങൾ യഥാർത്ഥത്തിൽ പരിശോധിച്ചത് വിവരിക്കുക.
വാഗ്ദാനം ചെയ്യുന്നതിന് മുമ്പ് പരിധി അറിയുക
OpenSSH-ന്റെ ചലനാത്മക ഫോർവേഡിംഗ് TCP കണക്ഷനുകൾ വഹിക്കുന്നു, ഏകപക്ഷീയ IP ട്രാഫിക്കല്ല, അതിനാൽ UDP, ICMP, പ്രോക്സിയെ അവഗണിക്കുന്ന ഏത് പ്രോട്ടോക്കോളിനും വേറെ പിന്തുണയുള്ള രൂപകൽപ്പന വേണം. SSH ഹോസ്റ്റ് കീ പരിശോധന, സെർവറിന്റെ ഫോർവേഡിംഗ് നിയന്ത്രണങ്ങൾ, HTTPS സർട്ടിഫിക്കറ്റ് സാധുത പരിശോധന എന്നിവ നിലനിർത്തുക, കാരണം പ്രോക്സി ഒരു അധിക വിശ്വസ്ത പങ്കാളിയാണ്, ഐഡന്റിറ്റി പരിശോധനകൾ ദുർബലമാക്കാനുള്ള കാരണമല്ല. ലക്ഷ്യം VPN-ന്റെ പുറം ഗതാഗതം പ്രോക്സിയിലൂടെ കൊണ്ടുപോകുകയാണെങ്കിൽ, ഏത് SOCKS ശ്രോതാവിനും അത് റിലേ ചെയ്യാമെന്ന് കരുതുന്നതിന് പകരം ഇരു അറ്റങ്ങളും ആ ഗതാഗതത്തെ പിന്തുണയ്ക്കുന്നുവെന്ന് പരിശോധിക്കുക.
ഇവയൊന്നും ക്ലയന്റിനെ ഇരട്ട-സ്റ്റാക്ക് ആക്കുന്നില്ല, അതിന്റെ ആവശ്യവുമില്ല. ഒരു അപ്ലിക്കേഷൻ ഒരു റിലേ വഴി ഒരു സേവനത്തിൽ എത്താൻ ഇത് സഹായിക്കുന്നു, അത് ചെറിയ അവകാശവാദവും പരിശോധിക്കാൻ വളരെ എളുപ്പവുമാണ്.