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 કેશિંગ નિયમો પ્રમાણિત વિનંતીઓના પ્રતિસાદ સંગ્રહિત કરવાને પણ મર્યાદિત કરે છે, અને ત્યાં જ વ્યક્તિગત પૃષ્ઠ ડેટા જાહેર થવાનું બને છે. પ્રોક્સીને ખુલ્લા રિલે તરીકે દર્શાવવાને બદલે મંજૂર ક્લાયન્ટ સુધી મર્યાદિત રાખો.

હિટ માપો, સ્ટોપવોચ નહીં

ઝડપી બીજી વિનંતી સાબિત કરતી નથી કે નવા કેશે કંઈ કર્યું છે, કારણ કે બ્રાઉઝરો અને ઓપરેટિંગ સિસ્ટમો પોતે આક્રમક રીતે કેશ કરે છે. પ્રોક્સી પાસેથી હિટ અને મિસ કાઉન્ટર માંગો અને નિયંત્રિત પુનરાવર્તન દરમિયાન મૂળનો ટ્રાફિક જુઓ. જાણીતી વસ્તુનું એક પુનરાવર્તિત ડાઉનલોડ વાપરો, પહેલા કેશ સક્ષમ અને પછી બાયપાસ સાથે, અને વીતેલા સમયને બદલે મૂળે પરોસેલા બાઇટ્સની સરખામણી કરો. પછી અધિકૃતિ સીમા તપાસો: લોગિન જરૂરી હોય તેવું સંસાધન બીજા ક્લાયન્ટને આપવું ન જોઈએ.

વર્કલોડ, કેશ કી અને ફરી વાપરવાની પરવાનગી આપનારી નીતિ નોંધો. કેશ એ ઓપ્ટિમાઇઝેશનના પોશાકમાં ડેટા શેરિંગનો નિર્ણય છે.