ഒരു പ്രോക്സി പോർട്ട് എങ്ങനെ HTTP ഉം SOCKS ഉം സ്വീകരിക്കാം

ഒരു മിശ്രിത പ്രോക്സി ലിസണറിന് ഒരു TCP പോർട്ടിൽ HTTP-യും SOCKS-ഉം സ്വീകരിക്കാനാകും, കാരണം സെർവർ പ്രോട്ടോക്കോളിന്റെ ആദ്യ ബൈറ്റുകൾ പരിശോധിക്കുന്നു. പോർട്ട് നമ്പർ ആ തിരിച്ചറിയൽ ചെയ്യുന്നില്ല.

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

ഇത് വ്യക്തമായ ഒരു നടപ്പാക്കൽ സവിശേഷതയാണ്. സാധാരണ Squid HTTP ലിസണർ അതിന്റെ പോർട്ട് 1080 ആക്കി മാറ്റിയതുകൊണ്ട് മിശ്രിതമാകുന്നില്ല, കൂടാതെ SOCKS മാത്രമുള്ള ലിസണർ ബ്രൗസർ ക്രമീകരണത്തിൽ നിന്ന് HTTP പഠിക്കുന്നില്ല.

TLS മറ്റൊരു അതിർത്തി കൂട്ടിച്ചേർക്കുന്നു: എൻക്രിപ്റ്റ് ചെയ്ത പ്രോക്സി കണക്ഷൻ TLS-ൽ ആരംഭിക്കുന്നു, കാണാവുന്ന HTTP രീതിയിലല്ല. അതേ എൻഡ്പോയിന്റിൽ അത് പിന്തുണയ്ക്കാൻ അധിക ബോധപൂർവമായ കൈകാര്യം ആവശ്യമാണ്; സാധാരണ ടെക്സ്റ്റ് HTTP-യും SOCKS-ഉം തിരിച്ചറിയുന്നത് ആ കഴിവ് സ്ഥാപിക്കുന്നില്ല.

എൻഡ്പോയിന്റിനായി രേഖപ്പെടുത്തിയ ക്ലയന്റ് പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുക. രണ്ടും പ്രവർത്തിക്കുന്നുവെങ്കിൽ, അത് ആ സെർവറിന്റെ മിശ്രിത ലിസണറിനെക്കുറിച്ചുള്ള തെളിവാണ്, എല്ലാ ക്ലയന്റിലും പ്രോട്ടോക്കോൾ വ്യക്തമാക്കാതെ വിടാനുള്ള കാരണമല്ല.

Glider-ന്റെ മിശ്രിത ലിസണർ ഒരു വ്യക്തമായ ഉദാഹരണം നൽകുന്നു: അത് ഒരു ബൈറ്റ് ഉപഭോഗിക്കാതെ അതിൽ എത്തിനോക്കുന്നു, 0x05 അതിന്റെ SOCKS5 ഹാൻഡ്ലറിലേക്ക് അയയ്ക്കുന്നു, അല്ലാത്തപക്ഷം അതിന്റെ HTTP പാഴ്സർ വിളിക്കുന്നു. ആ പാഴ്സർ ഇപ്പോഴും വരുന്ന അഭ്യർത്ഥന സാധൂകരിക്കുന്നു; അയയ്ക്കാനുള്ള തിരഞ്ഞെടുപ്പ് ഏകപക്ഷീയമായ ഇൻപുട്ടിനെ സാധുവായ HTTP ആക്കുന്നില്ല.

TCP ലിസണർ പങ്കിടുന്നത് അതിൽത്തന്നെ SOCKS5 UDP അസോസിയേഷൻ നൽകുന്നില്ല. Glider അതിന്റെ UDP ലിസണർ വെവ്വേറെ ആരംഭിക്കുന്നു. TCP പ്രോട്ടോക്കോൾ തിരഞ്ഞെടുപ്പും പിന്നീടുള്ള ഡാറ്റാഗ്രാം റിലേയും വെവ്വേറെ കഴിവുകളാണ്.