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 ಕ್ಯಾಶಿಂಗ್ ನಿಯಮಗಳು ದೃಢೀಕೃತ ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದನ್ನೂ ಮಿತಿಗೊಳಿಸುತ್ತವೆ, ಮತ್ತು ಅಲ್ಲಿಯೇ ವೈಯಕ್ತಿಕ ಪುಟ ಡೇಟಾ ಬಹಿರಂಗವಾಗುತ್ತದೆ. ಪ್ರಾಕ್ಸಿಯನ್ನು ಮುಕ್ತ ರಿಲೇ ಆಗಿ ಒಡ್ಡುವ ಬದಲು ಅನುಮೋದಿತ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ.

ಹಿಟ್ ಅನ್ನು ಅಳೆಯಿರಿ, ಸ್ಟಾಪ್‌ವಾಚ್ ಅನ್ನಲ್ಲ

ವೇಗವಾದ ಎರಡನೇ ವಿನಂತಿ ಹೊಸ ಕ್ಯಾಶ್ ಏನಾದರೂ ಮಾಡಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಬ್ರೌಸರ್‌ಗಳು ಮತ್ತು ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗಳು ತಾವೇ ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಕ್ಯಾಶ್ ಮಾಡುತ್ತವೆ. ಪ್ರಾಕ್ಸಿಯಿಂದ ಹಿಟ್ ಮತ್ತು ಮಿಸ್ ಕೌಂಟರ್‌ಗಳನ್ನು ಕೇಳಿ ಮತ್ತು ನಿಯಂತ್ರಿತ ಪುನರಾವರ್ತನೆಯ ಸಮಯದಲ್ಲಿ ಮೂಲ ಸಂಚಾರವನ್ನು ಗಮನಿಸಿ. ತಿಳಿದಿರುವ ವಸ್ತುವಿನ ಒಂದು ಪುನರಾವರ್ತಿತ ಡೌನ್‌ಲೋಡ್ ಬಳಸಿ, ಮೊದಲು ಕ್ಯಾಶ್ ಸಕ್ರಿಯವಾಗಿ ನಂತರ ಬೈಪಾಸ್ ಮಾಡಿ, ಮತ್ತು ಕಳೆದ ಸಮಯವಲ್ಲ, ಮೂಲ ನೀಡಿದ ಬೈಟ್‌ಗಳನ್ನು ಹೋಲಿಸಿ. ನಂತರ ಅಧಿಕಾರ ಗಡಿಯನ್ನು ಪರಿಶೀಲಿಸಿ: ಲಾಗಿನ್ ಅಗತ್ಯವಿರುವ ಸಂಪನ್ಮೂಲವನ್ನು ಬೇರೆ ಕ್ಲೈಂಟ್‌ಗೆ ನೀಡಬಾರದು.

ಕೆಲಸ, ಕ್ಯಾಶ್ ಕೀ ಮತ್ತು ಮರುಬಳಕೆಗೆ ಅನುಮತಿ ನೀಡಿದ ನೀತಿಯನ್ನು ದಾಖಲಿಸಿ. ಕ್ಯಾಶ್ ಎಂಬುದು ಆಪ್ಟಿಮೈಜೇಶನ್ ವೇಷದಲ್ಲಿ ಡೇಟಾ ಹಂಚಿಕೆಯ ನಿರ್ಧಾರ.