Kusoma hitilafu ya SO_ORIGINAL_DST ya Squid

NF getsockopt(SO_ORIGINAL_DST) inaelekeza kwenye utafutaji wa lengwa asilia. Katika mpangilio wa kukatiza, Squid lazima irejeshe mahali muunganisho ulioelekezwa upya ulikokuwa ukienda awali.

Kivinjari kilichosanidiwa waziwazi hutuma maombi yake kwa proksi kwa makusudi. Muunganisho huo haupati historia ya kukatiza ya NAT kwa sababu tu intercept imeandikwa kando ya lango la kisikilizaji cha Squid.

Kwa hiyo kutofautiana huku kunaweza kushindwa kabla cheti cha lengwa hakijawa muhimu.

Anza na jinsi muunganisho ulivyofika

• Ikiwa programu ina anwani ya proksi iliyosanidiwa, tambua kisikilizaji cha kawaida cha proksi ya mbele ambacho inapaswa kutumia.
• Ikiwa lango linaelekeza upya trafiki ambayo kwa kawaida ingekuwa ya moja kwa moja, angalia kwamba inafikia kisikilizaji cha kukatiza kilichokusudiwa na kwamba muundo wa NAT unaotumika unahifadhi taarifa ya lengwa inayohitajika.
• Ikiwa hali zote mbili zipo, angalia anwani na lango ambalo mteja anayeshindwa aliwasiliana nayo kwa kweli.

Nyaraka za Squid kuhusu http_port zinafanya tofauti iwe wazi: kuacha bendera ya hali huchagua hali ya proksi ya mbele; intercept inatarajia kukatiza kwa NAT katika tabaka la IP.

Kisha shughulikia usalama wa usafirishaji kando. Proksi ya HTTP inaweza kubeba HTTPS kupitia CONNECT. Muunganisho wa TLS kwa proksi unahitaji kisikilizaji na usanidi wa mteja unaoendana. Kusimbua trafiki ya lengwa ni uwezo mwingine wa hiari.

Usinakili “suluhisho la HTTPS” la zamani linalowasha utengenezaji wa vyeti kwa sababu tu URL ya lengwa inaanza na HTTPS. Kwanza rekebisha makubaliano kati ya mteja na kisikilizaji. Ikiwa baada ya hapo hitilafu halisi ya TLS itabaki, itakuwa hitilafu yenye manufaa zaidi kuchunguza.