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 ਕੈਸ਼ਿੰਗ ਨਿਯਮ ਪ੍ਰਮਾਣਿਤ ਬੇਨਤੀਆਂ ਦੇ ਜਵਾਬ ਸੰਭਾਲਣ ’ਤੇ ਵੀ ਸੀਮਾ ਲਾਉਂਦੇ ਹਨ, ਅਤੇ ਉੱਥੇ ਹੀ ਨਿੱਜੀ ਸਫ਼ਾ ਡੇਟਾ ਖੁਲਾਸਾ ਬਣਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਨੂੰ ਖੁੱਲ੍ਹੀ ਰੀਲੇ ਵਜੋਂ ਦਿਖਾਉਣ ਦੀ ਥਾਂ ਮਨਜ਼ੂਰ ਕਲਾਇੰਟਾਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ।

ਹਿੱਟ ਮਾਪੋ, ਸਟਾਪਵਾਚ ਨਹੀਂ

ਤੇਜ਼ ਦੂਜੀ ਬੇਨਤੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਨਵੇਂ ਕੈਸ਼ ਨੇ ਕੁਝ ਕੀਤਾ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਆਪਣੇ ਆਪ ਹਮਲਾਵਰ ਢੰਗ ਨਾਲ ਕੈਸ਼ ਕਰਦੇ ਹਨ। ਪ੍ਰੌਕਸੀ ਤੋਂ ਹਿੱਟ ਅਤੇ ਮਿਸ ਕਾਊਂਟਰ ਮੰਗੋ ਅਤੇ ਨਿਯੰਤਰਿਤ ਦੁਹਰਾਓ ਦੌਰਾਨ ਮੂਲ ਦੀ ਟ੍ਰੈਫਿਕ ਦੇਖੋ। ਕਿਸੇ ਜਾਣੀ ਵਸਤੂ ਦਾ ਇੱਕ ਦੁਹਰਾਇਆ ਡਾਊਨਲੋਡ ਵਰਤੋ, ਪਹਿਲਾਂ ਕੈਸ਼ ਸਮਰਥਿਤ ਅਤੇ ਫਿਰ ਬਾਈਪਾਸ ਕਰਕੇ, ਅਤੇ ਬੀਤਿਆ ਸਮਾਂ ਨਹੀਂ, ਮੂਲ ਵੱਲੋਂ ਦਿੱਤੇ ਬਾਈਟ ਦੀ ਤੁਲਨਾ ਕਰੋ। ਫਿਰ ਅਧਿਕਾਰ ਹੱਦ ਜਾਂਚੋ: ਲੌਗਇਨ ਲੋੜੀਂਦਾ ਸਰੋਤ ਕਿਸੇ ਹੋਰ ਕਲਾਇੰਟ ਨੂੰ ਨਹੀਂ ਦਿੱਤਾ ਜਾਣਾ ਚਾਹੀਦਾ।

ਕੰਮ, ਕੈਸ਼ ਕੁੰਜੀ ਅਤੇ ਮੁੜ ਵਰਤੋਂ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲੀ ਨੀਤੀ ਦਰਜ ਕਰੋ। ਕੈਸ਼ ਅਪਟੀਮਾਈਜ਼ੇਸ਼ਨ ਦੇ ਭੇਸ ਵਿੱਚ ਡੇਟਾ ਸਾਂਝਾ ਕਰਨ ਦਾ ਫ਼ੈਸਲਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ