Քեշ VPN-ի հետևում. ինչ է դեռ թաքցնում HTTPS-ը ձեզանից

VPN սերվերի կողքին քեշը հնչում է որպես անվճար թողունակություն թունելի հետևում գտնվող բոլորի համար: Բայց այդպես չէ, որովհետև այդ կետով անցնող բայթերը մնում են պաշտպանված TLS սեսիայով, որի ծայրերը բրաուզերն ու կայքն են: VPN դարպասը հեռացնում է միայն իր արտաքին գաղտնագրումը, ոչ հավելվածինը: Որոշեք, թե որ կրկնվող օբյեկտն եք ուզում վերօգտագործել, նախքան սարքավորում ավելացնելը:

TLS սեսիան պատկանում է բրաուզերին

Սովորական HTTPS-ում բրաուզերը բանալիներ է համաձայնեցնում կայքի հետ, և ձեռքսեղմումից հետո յուրաքանչյուր գրառում գաղտնագրվում է այդ ծայրերի զույգի համար: VPN դարպասը վերծանում է իր ստեղծած թունելը, ապա փոխանցում անթափանց TLS գրառումներ: Այն տեսնում է նպատակակետերը, ժամանակը և ծավալը, ոչ հարցման տողը կամ պատասխանի մարմինը: Սա այն սահմանն է, որի հետ պետք է ապրի ցանկացած քեշ:

Ցանկացած ձևավորում, որը կոտրում է այն, TLS ընդհատման ձևավորում է՝ իր սեփական հետևանքներով վկայագրերի վստահության և սարքերի կառավարման համար:

CONNECT-ը թունել է, ոչ քեշ

Բացահայտ առաջադիր փրոքսին սովորաբար ստանում է HTTP CONNECT հարցում և ապա բայթերը փոխանցում երկու ուղղությամբ: Փոխանցումը հիմնական բառն է. փրոքսին չի վերլուծում գաղտնագրված զրույցը:

curl -sSI -x http://proxy.example:3128 https://example.com/

Պատասխանի վերնագրերը գալիս են փրոքսիի թունելի մշակումից, ոչ էջի քեշավորված պատճենից: Հաջող CONNECT-ը նշանակում է, որ ուղին աշխատում է, ոչ թե որ ինչ-որ բան պահվել է վերօգտագործման համար: 443 պորտը քեշին ուղղելը նույնպես չի սովորեցնում նրան խոսել TLS, քանի որ քեշավորումը պահանջում է ընթեռնելի հաղորդագրություններ: Հաճախորդի կարգավորումը պետք է օգտագործի աջակցվող բացահայտ փրոքսի կարգավորումը, ոչ թե չբացատրված վերահղում:

Քեշավորեք այն, ինչ ղեկավարում եք, ոչ այն, ինչ դիտարկում եք

Երբ բովանդակությունը ձերն է, հակադարձ փրոքսին կարող է ավարտել TLS-ը և գիտակցաբար պահել հաստատված պատասխանները: Երբ այն փաթեթների պահոցինն է, օգտագործեք այն հայելին, որին աջակցում է նախագիծը:

nginx -T | grep -n "proxy_cache"
curl -sSI https://mirror.example/pkg/index.json | grep -i -E "cache-control|age"

Առաջին հրամանը ցույց է տալիս՝ արդյոք քեշ գոտին կարգավորված է և որտեղ է գործում, երկրորդը ցույց է տալիս աղբյուրի սեփական քեշավորման հրահանգները մեկ օբյեկտի համար: Համօգտագործվող քեշը պետք է հարգի թարմությունը, քեշի կառավարումը և հարցման այն հատկանիշները, որոնք տարբերում են ներկայացումները. private և no-store տարբեր բաներ են նշանակում, և ոչ մեկը չպետք է հեռացվի հարվածների մակարդակը բարձրացնելու համար: HTTP քեշավորման կանոնները նաև սահմանափակում են պատասխանների պահումը նույնականացված հարցումների համար, և հենց այնտեղ անհատականացված էջը դառնում է տվյալների բացահայտում: Պահեք փրոքսին սահմանափակված հաստատված հաճախորդներով, փոխարենը բաց ռելե ցուցադրելու:

Չափեք հարվածը, ոչ վայրկյանաչափը

Ավելի արագ երկրորդ հարցումը չի ապացուցում, որ նոր քեշն ինչ-որ բան արեց, որովհետև բրաուզերներն ու օպերացիոն համակարգերը ինքնուրույն ագրեսիվ քեշավորում են: Խնդրեք փրոքսիից հարվածների և բացթողումների հաշվիչներ և դիտեք աղբյուրի երթևեկությունը վերահսկվող կրկնության ընթացքում: Օգտագործեք հայտնի օբյեկտի մեկ կրկնվող ներբեռնում՝ նախ քեշը միացված, ապա շրջանցված, և համեմատեք աղբյուրի մատուցած բայթերը, ոչ թե անցած ժամանակը: Ապա ստուգեք լիազորման սահմանը. մուտք պահանջող ռեսուրսը չպետք է մատուցվի այլ հաճախորդի:

Գրանցեք ծանրաբեռնվածությունը, քեշի բանալին և այն քաղաքականությունը, որը թույլ տվեց վերօգտագործումը: Քեշը տվյալների կիսման որոշում է օպտիմալացման զգեստով: