Squid-ի SO_ORIGINAL_DST սխալի ընթերցում

NF getsockopt(SO_ORIGINAL_DST) մատնանշում է սկզբնական նպատակակետի որոնումը։ Ընդհատման կարգավորումում Squid-ը պետք է վերականգնի, թե ուր էր սկզբում գնում վերուղղորդված կապը։

Բացահայտ կարգավորված դիտարկիչը դիտավորյալ ուղարկում է իր հարցումները վստահված սերվերին։ Այդ կապը չի ստանում NAT ընդհատման պատմություն միայն այն պատճառով, որ Squid-ի լսիչի պորտի կողքին գրված է intercept։

Ուստի այս անհամապատասխանությունը կարող է ձախողվել նախքան նպատակակետի վկայականի արդիական դառնալը։

Սկսեք նրանից, թե ինչպես ժամանեց կապը

• Եթե հավելվածն ունի կարգավորված վստահված սերվերի հասցե, որոշեք սովորական ուղարկող վստահված սերվերի լսիչը, որը պետք է օգտագործի։
• Եթե դարպասը վերուղղորդում է այլապես ուղիղ երթևեկությունը, ստուգեք, որ այն հասնում է նախատեսված ընդհատման լսիչին, և որ աջակցվող NAT լուծումը պահպանում է անհրաժեշտ նպատակակետային տեղեկությունը։
• Եթե երկու ռեժիմներն էլ կան, ստուգեք, թե որ հասցեին և պորտին է իրականում միացել ձախողվող հաճախորդը։

Squid-ի http_port փաստաթղթերը հստակ տարբերակում են. ռեժիմի դրոշակը բաց թողնելը ընտրում է ուղարկող վստահված սերվերի ռեժիմը. intercept սպասում է NAT ընդհատում IP մակարդակում։

Այնուհետև տրանսպորտային անվտանգությունը դիտարկեք առանձին։ HTTP վստահված սերվերը կարող է HTTPS փոխանցել CONNECT-ով։ Վստահված սերվերին TLS կապը պահանջում է համատեղելի լսիչ և հաճախորդի կարգավորում։ Նպատակակետ երթևեկության ապակոդավորումը ևս առանձին ընտրովի հնարավորություն է։

Մի պատճենեք հին “HTTPS լուծում”, որը միացնում է վկայականների գեներացումը միայն այն պատճառով, որ նպատակակետի URL-ը սկսվում է HTTPS-ով։ Նախ վերականգնեք հաճախորդի և լսիչի համաձայնությունը։ Եթե դրանից հետո մնա իրական TLS սխալ, այն ավելի օգտակար սխալ կլինի քննելու համար։