ബ്രൗസർ Squid വഴി ഒരു HTTP പേജ് ലോഡ് ചെയ്യുന്നു. അതേ ലക്ഷ്യം proxychains-ൽ പരാജയപ്പെടുന്നു. രണ്ട് പ്രോഗ്രാമുകളിൽ ഒന്ന് തെറ്റായ പ്രോക്സി IP തിരഞ്ഞെടുത്തു എന്ന് ഇത് അർത്ഥമാക്കുന്നില്ല.

HTTP മനസ്സിലാക്കുന്ന സാധാരണ ക്ലയന്റിന് വെബ് അഭ്യർത്ഥന HTTP പ്രോക്സി രൂപത്തിൽ ഫോർവേഡ് പ്രോക്സിയിലേക്ക് അയക്കാം. എന്നാൽ ഒരു സാധാരണ സോക്കറ്റ് ആവരണത്തിന് അപ്ലിക്കേഷൻ തുറക്കാൻ ആഗ്രഹിച്ച കണക്ഷന് ബൈറ്റ് ടണൽ ആവശ്യമാണ്. സ്വന്തം ശൃംഖലയിലെ HTTP പ്രോക്സിക്ക് proxychains CONNECT ഉപയോഗിക്കുന്നു.

അതായത് പോർട്ട് 80-ലെ സാധാരണ ടെക്സ്റ്റ് വെബ്സൈറ്റിന് പോർട്ട് 80-ലേക്ക് CONNECT അഭ്യർത്ഥന സൃഷ്ടിക്കാനാകും. അംഗീകൃത TLS പോർട്ട് പട്ടികയിലേക്ക് മാത്രം CONNECT അനുവദിക്കുന്ന Squid നയം, പോർട്ട് 80-ലേക്കുള്ള സാധാരണ HTTP അഭ്യർത്ഥനകൾ അനുവദിച്ചിട്ടും ആ ടണൽ നിരസിച്ചേക്കാം.

ഹോസ്റ്റ്നാമങ്ങൾ മാത്രമല്ല, അഭ്യർത്ഥനകൾ താരതമ്യം ചെയ്യുക

proxychains-ng-ന്റെ ഡോക്യുമെന്റേഷൻ അതിന്റെ HTTP CONNECT പിന്തുണ വിവരിക്കുന്നു. Squid-ന്റെ ആക്സസ് നിയമങ്ങൾ രീതിയും ലക്ഷ്യ പോർട്ടും വേർതിരിക്കാം. ഇവ ഒരേ വെബ്സൈറ്റിലേക്കുള്ള വ്യത്യസ്ത അഭ്യർത്ഥന പാതകളാണ്.

മാറ്റുന്നതിന് മുമ്പ് നിരസിക്കലും ഉദ്ദേശിച്ച നയവും വായിക്കുക. CONNECT ആക്സസ് എല്ലാ പോർട്ടുകളിലേക്കും വിപുലീകരിക്കുന്നത് വലിയ മാറ്റമാണ്; ആവരണത്തിന്റെ പൊരുത്തക്കേടിനുള്ള സ്ഥിരസ്ഥിതി പ്രതികരണമായിരിക്കരുത് അത്.

അപ്ലിക്കേഷന് സ്വദേശീയ HTTP പ്രോക്സി പിന്തുണ ഉണ്ടെങ്കിൽ, അത് ഉപയോഗിക്കുന്നത് സാധാരണ ടെക്സ്റ്റ് HTTP-ക്കുള്ള അനാവശ്യ പൊതു ടണൽ ഒഴിവാക്കാം. അതിന് യഥാർത്ഥത്തിൽ അസംസ്കൃത TCP ടണൽ ആവശ്യമുണ്ടെങ്കിൽ, അത് നൽകുന്ന അംഗീകൃത പ്രോക്സി പ്രോട്ടോക്കോളും പോർട്ട് നയവും തിരഞ്ഞെടുക്കുക.

വിജയകരമായ ബ്രൗസർ അഭ്യർത്ഥന പ്രോക്സിയുടെ എത്തിച്ചേരാനുള്ള കഴിവിനെക്കുറിച്ചും ഒരു പിന്തുണയുള്ള അഭ്യർത്ഥന രീതിയെക്കുറിച്ചും ഉപയോഗപ്രദമായ തെളിവാണ്. എന്നാൽ എല്ലാ ടണലിംഗ് രീതിയും ലക്ഷ്യ പോർട്ടും അപ്ലിക്കേഷൻ പ്രോട്ടോക്കോളും ആ പ്രോക്സി വഴി അനുവദനീയമാണെന്ന് അത് തെളിയിക്കുന്നില്ല.

അനുബന്ധ ലേഖനങ്ങൾ