Squid SO_ORIGINAL_DST ದೋಷವನ್ನು ಓದುವುದು

NF getsockopt(SO_ORIGINAL_DST) ಮೂಲ ಗಮ್ಯಸ್ಥಾನದ ಹುಡುಕಾಟವನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಇಂಟರ್ಸೆಪ್ಶನ್ ಸಂರಚನೆಯಲ್ಲಿ, ಮರುನಿರ್ದೇಶಿತ ಸಂಪರ್ಕವು ಮೊದಲು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತಿತ್ತು ಎಂಬುದನ್ನು Squid ಮರುಪಡೆಯಬೇಕು.

ಸ್ಪಷ್ಟವಾಗಿ ಸಂರಚಿಸಲಾದ ಬ್ರೌಸರ್ ತನ್ನ ವಿನಂತಿಗಳನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರಾಕ್ಸಿಗೆ ಕಳುಹಿಸುತ್ತದೆ. Squid ಕೇಳುಗರ ಪೋರ್ಟ್ ಪಕ್ಕ intercept ಬರೆದಿರುವುದರಿಂದ ಮಾತ್ರ ಆ ಸಂಪರ್ಕಕ್ಕೆ NAT ಇಂಟರ್ಸೆಪ್ಶನ್ ಇತಿಹಾಸ ಸಿಗುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ ಈ ಹೊಂದಾಣಿಕೆ ವೈಫಲ್ಯವು ಗಮ್ಯಸ್ಥಾನದ ಪ್ರಮಾಣಪತ್ರವು ಪ್ರಸ್ತುತವಾಗುವ ಮೊದಲೇ ವಿಫಲವಾಗಬಹುದು.

ಸಂಪರ್ಕವು ಹೇಗೆ ಬಂತು ಎಂಬುದರಿಂದ ಪ್ರಾರಂಭಿಸಿ

• ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ವಿಳಾಸ ಸಂರಚಿಸಲಾಗಿದ್ದರೆ, ಅದು ಬಳಸಬೇಕಾದ ಸಾಮಾನ್ಯ ಫಾರ್ವರ್ಡ್-ಪ್ರಾಕ್ಸಿ ಕೇಳುಗರನ್ನು ಗುರುತಿಸಿ.
• ಗೇಟ್‌ವೇ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ನೇರವಾದ ಸಂಚಾರವನ್ನು ಮರುನಿರ್ದೇಶಿಸಿದರೆ, ಅದು ಉದ್ದೇಶಿತ ಇಂಟರ್ಸೆಪ್ಶನ್ ಕೇಳುಗರನ್ನು ತಲುಪುತ್ತದೆಯೇ ಮತ್ತು ಬೆಂಬಲಿತ NAT ವಿನ್ಯಾಸವು ಅಗತ್ಯವಾದ ಗಮ್ಯಸ್ಥಾನ ಮಾಹಿತಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
• ಎರಡೂ ಮೋಡ್‌ಗಳಿದ್ದರೆ, ವಿಫಲವಾಗುತ್ತಿರುವ ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಯಾವ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್‌ಗೆ ಸಂಪರ್ಕಿಸಿತು ಎಂದು ಪರಿಶೀಲಿಸಿ.

Squid ನ http_port ದಾಖಲೆ ವ್ಯತ್ಯಾಸವನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುತ್ತದೆ: ಮೋಡ್ ಫ್ಲ್ಯಾಗ್ ಬಿಟ್ಟರೆ ಫಾರ್ವರ್ಡ್-ಪ್ರಾಕ್ಸಿ ಮೋಡ್ ಆಯ್ಕೆಯಾಗುತ್ತದೆ; intercept IP ಪದರದಲ್ಲಿ NAT ಇಂಟರ್ಸೆಪ್ಶನ್ ನಿರೀಕ್ಷಿಸುತ್ತದೆ.

ನಂತರ ಸಾರಿಗೆ ಭದ್ರತೆಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ನೋಡಿ. HTTP ಪ್ರಾಕ್ಸಿ CONNECT ಮೂಲಕ HTTPS ಸಾಗಿಸಬಹುದು. ಪ್ರಾಕ್ಸಿಗೆ TLS ಸಂಪರ್ಕಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ಕೇಳುಗ ಮತ್ತು ಕ್ಲೈಂಟ್ ಸಂರಚನೆ ಬೇಕು. ಗಮ್ಯಸ್ಥಾನ ಸಂಚಾರವನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುವುದು ಇನ್ನೊಂದು ಐಚ್ಛಿಕ ಸಾಮರ್ಥ್ಯ.

ಗಮ್ಯಸ್ಥಾನ URL HTTPS ನಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಪ್ರಮಾಣಪತ್ರ ರಚನೆಯನ್ನು ಆನ್ ಮಾಡುವ ಹಳೆಯ “HTTPS ಪರಿಹಾರ”ವನ್ನು ನಕಲಿಸಬೇಡಿ. ಮೊದಲು ಕ್ಲೈಂಟ್ ಮತ್ತು ಕೇಳುಗರ ನಡುವಿನ ಒಪ್ಪಂದವನ್ನು ಸರಿಪಡಿಸಿ. ನಂತರ ನಿಜವಾದ TLS ದೋಷ ಉಳಿದರೆ, ಅದು ತನಿಖೆಗೆ ಹೆಚ್ಚು ಉಪಯುಕ್ತ ದೋಷವಾಗುತ್ತದೆ.