Squid SO_ORIGINAL_DST പിശക് വായിക്കുന്നത്

NF getsockopt(SO_ORIGINAL_DST) യഥാർത്ഥ ലക്ഷ്യസ്ഥാനത്തിന്റെ തിരച്ചിലിനെ സൂചിപ്പിക്കുന്നു. ഇന്റർസെപ്ഷൻ ക്രമീകരണത്തിൽ, വഴിതിരിച്ചുവിട്ട കണക്ഷൻ ആദ്യം എവിടേക്കായിരുന്നു എന്ന് Squid വീണ്ടെടുക്കണം.

വ്യക്തമായി കോൺഫിഗർ ചെയ്ത ബ്രൗസർ അഭ്യർത്ഥനകൾ ബോധപൂർവ്വം പ്രോക്സിയിലേക്ക് അയയ്ക്കുന്നു. Squid ലിസണറുടെ പോർട്ടിന് അടുത്ത് intercept എഴുതിയിരിക്കുന്നത് കൊണ്ട് മാത്രം ആ കണക്ഷന് NAT ഇന്റർസെപ്ഷൻ ചരിത്രം ലഭിക്കുന്നില്ല.

അതിനാൽ ഈ പൊരുത്തക്കേട് ലക്ഷ്യസ്ഥാനത്തിന്റെ സർട്ടിഫിക്കറ്റ് പ്രസക്തമാകുന്നതിന് മുമ്പ് പരാജയപ്പെടാം.

കണക്ഷൻ എങ്ങനെ എത്തി എന്നതിൽ നിന്ന് തുടങ്ങുക

• ആപ്ലിക്കേഷനിൽ പ്രോക്സി വിലാസം കോൺഫിഗർ ചെയ്തിട്ടുണ്ടെങ്കിൽ, അത് ഉപയോഗിക്കേണ്ട സാധാരണ ഫോർവേഡ്-പ്രോക്സി ലിസണർ നിർണ്ണയിക്കുക.
• ഗേറ്റ്‌വേ മറ്റൊരു വിധത്തിൽ നേരിട്ടുള്ള ട്രാഫിക് വഴിതിരിച്ചുവിടുന്നുവെങ്കിൽ, അത് ഉദ്ദേശിച്ച ഇന്റർസെപ്ഷൻ ലിസണറിൽ എത്തുന്നുണ്ടോ എന്നും പിന്തുണയ്ക്കുന്ന NAT രൂപകൽപ്പന ആവശ്യമായ ലക്ഷ്യ വിവരങ്ങൾ സൂക്ഷിക്കുന്നുണ്ടോ എന്നും പരിശോധിക്കുക.
• രണ്ട് മോഡുകളും ഉണ്ടെങ്കിൽ, പരാജയപ്പെടുന്ന ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഏത് വിലാസത്തിലേക്കും പോർട്ടിലേക്കും ബന്ധിപ്പിച്ചു എന്ന് പരിശോധിക്കുക.

Squid-ന്റെ http_port രേഖകൾ വ്യത്യാസം വ്യക്തമാക്കുന്നു: മോഡ് ഫ്ലാഗ് ഒഴിവാക്കുന്നത് ഫോർവേഡ്-പ്രോക്സി മോഡ് തിരഞ്ഞെടുക്കുന്നു; intercept IP പാളിയിൽ NAT ഇന്റർസെപ്ഷൻ പ്രതീക്ഷിക്കുന്നു.

തുടർന്ന് ഗതാഗത സുരക്ഷ വെവ്വേറെ കൈകാര്യം ചെയ്യുക. HTTP പ്രോക്സിക്ക് CONNECT വഴി HTTPS കൊണ്ടുപോകാം. പ്രോക്സിയിലേക്കുള്ള TLS കണക്ഷന് അനുയോജ്യമായ ലിസണറും ക്ലയന്റ് കോൺഫിഗറേഷനും ആവശ്യമാണ്. ലക്ഷ്യ ട്രാഫിക് ഡീക്രിപ്റ്റ് ചെയ്യുന്നത് മറ്റൊരു ഓപ്ഷണൽ കഴിവാണ്.

ലക്ഷ്യ URL HTTPS-ൽ തുടങ്ങുന്നു എന്ന കാരണത്താൽ സർട്ടിഫിക്കറ്റ് ഉൽപ്പാദനം ഓണാക്കുന്ന പഴയ “HTTPS പരിഹാരം” പകർത്തരുത്. ആദ്യം ക്ലയന്റും ലിസണറും തമ്മിലുള്ള യോജിപ്പ് ശരിയാക്കുക. അതിനുശേഷം യഥാർത്ഥ TLS പിശക് അവശേഷിക്കുന്നുവെങ്കിൽ, അത് അന്വേഷിക്കാൻ കൂടുതൽ ഉപയോഗപ്രദമായ പിശകായിരിക്കും.