ಒಂದೇ ಸಬ್‌ನೆಟ್‌ನ ವೆಬ್‌ಸೈಟ್‌ಗಳು ಗೇಟ್‌ವೇಯ ಪಾರದರ್ಶಕ ಪ್ರಾಕ್ಸಿಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಬಹುದು
ಇಂಟರ್ನೆಟ್ ವಿನಂತಿಗಳು ಅದರ ಲಾಗ್‌ನಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡರೂ ಒಂದೇ ಸಬ್‌ನೆಟ್‌ನ ಸಂಚಾರವು ಗೇಟ್‌ವೇಯ ಪ್ರತಿಬಂಧ ನಿಯಮವನ್ನು ಏಕೆ ಬೈಪಾಸ್ ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.
ಇಂಟರ್ನೆಟ್ ಬ್ರೌಸಿಂಗ್ ಗೇಟ್‌ವೇ ಪ್ರಾಕ್ಸಿಯ ಲಾಗ್‌ನಲ್ಲಿ ಕಾಣಿಸುತ್ತದೆ. ಕಚೇರಿ LANನಲ್ಲಿರುವ ವೆಬ್‌ಸೈಟ್ ಕಾಣಿಸುವುದಿಲ್ಲ. URL ಫಿಲ್ಟರ್ ಬದಲಿಸುವ ಮೊದಲು LAN ವಿನಂತಿ ಗೇಟ್‌ವೇಯನ್ನು ತಲುಪಿತೇ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
ನೇರವಾಗಿ ಸಂಪರ್ಕಗೊಂಡ IPv4 ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ, ಕ್ಲೈಂಟ್ ಗಮ್ಯಸ್ಥಾನದ ಲಿಂಕ್-ಲೇಯರ್ ವಿಳಾಸವನ್ನು ಪರಿಹರಿಸಿ ಸ್ಥಳೀಯ ವಿಭಾಗದಲ್ಲಿ ಅದಕ್ಕೆ ಕಳುಹಿಸಬಹುದು. ಅದರ ಡೀಫಾಲ್ಟ್ ಗೇಟ್‌ವೇ ಆ ಮಾರ್ಗದಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಇರುವುದಿಲ್ಲ. ಗೇಟ್‌ವೇಯಲ್ಲಿನ ಪಾರದರ್ಶಕ ಪ್ರತಿಬಂಧ ನಿಯಮವು ಗೇಟ್‌ವೇ ಎಂದಿಗೂ ಸ್ವೀಕರಿಸದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಮರುನಿರ್ದೇಶಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
ಉದಾಹರಣೆಗೆ, ಒಂದೇ ಆನ್-ಲಿಂಕ್ ಸಬ್‌ನೆಟ್‌ನ ಎರಡು ಹೋಸ್ಟ್‌ಗಳು ಸ್ವಿಚ್ ಮೂಲಕ ಸಂಚಾರವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬಹುದು, ಆದರೆ ಪ್ರಾಕ್ಸಿ ಯಂತ್ರವು ಇನ್ನೊಂದು ಸ್ವಿಚ್ ಪೋರ್ಟ್‌ಗೆ ಸಂಪರ್ಕಗೊಂಡಿರುತ್ತದೆ. ಆ LANನಲ್ಲಿರುವುದು ಮಾತ್ರ ಪ್ರಾಕ್ಸಿಯನ್ನು ಫಾರ್ವರ್ಡಿಂಗ್ ಬಿಂದುವನ್ನಾಗಿ ಮಾಡುವುದಿಲ್ಲ.
ಉದ್ದೇಶಿಸಿದ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆಮಾಡಿ
ಸ್ಪಷ್ಟ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಭಾಗವಹಿಸುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ವಿನಂತಿಯನ್ನು ಗುರಿ ವೆಬ್‌ಸೈಟ್ ಸ್ಥಳೀಯವಾಗಿದ್ದರೂ ಪ್ರಾಕ್ಸಿಗೆ ಕಳುಹಿಸಬಹುದು. ಬೈಪಾಸ್ ನಿಯಮಗಳು ಮತ್ತು PAC ನಿರ್ಧಾರಗಳನ್ನು ಸಹ ಪರಿಶೀಲಿಸಿ: ಅವು ಖಾಸಗಿ ಹೆಸರುಗಳು ಅಥವಾ ವಿಳಾಸಗಳಿಗೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ DIRECT ಆಯ್ಕೆ ಮಾಡಬಹುದು.
ಪ್ರತಿಬಂಧ ಅಗತ್ಯವಿದ್ದರೆ, ನೆಟ್‌ವರ್ಕ್ ಪ್ರತಿಬಂಧ ಬಿಂದುವನ್ನು ನಿಜವಾಗಿ ಮಾರ್ಗದಲ್ಲಿ ಇರಿಸಬೇಕು; Linux ಗೇಟ್‌ವೇಯಲ್ಲಿ ಸ್ಥಳೀಯ ಮತ್ತು ಫಾರ್ವರ್ಡ್ ಮಾಡಿದ ಪ್ಯಾಕೆಟ್ ಮಾರ್ಗಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಿ. ರೂಟೆಡ್ ಸಬ್‌ನೆಟ್ ವಿಭಜನೆ ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕ ಇನ್‌ಲೈನ್ ಸೇತುವೆ ಸೂಕ್ತ ವಿನ್ಯಾಸಗಳಲ್ಲಿ ಅದನ್ನು ಮಾಡಬಹುದು, ಆದರೆ ಪ್ರತಿಯೊಂದೂ ಫಾರ್ವರ್ಡಿಂಗ್ ಮತ್ತು ವೈಫಲ್ಯದ ವರ್ತನೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ. LANನ ಬೇರೆಡೆ ಇರುವ ಸೇತುವೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಇನ್‌ಲೈನ್ ಅಲ್ಲ.
ಅಪ್ಲಿಕೇಶನ್ ಪ್ರೋಟೋಕಾಲ್ ಅಗತ್ಯವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಸಂಚಾರ ಸಾಧನವನ್ನು ದಾಟಿದ ನಂತರವೂ ಆಲಿಸುವವರು ಪ್ರತಿಬಂಧ ಮೋಡ್ ಅನ್ನು ಬೆಂಬಲಿಸಬೇಕು. ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸರಿಸುವುದು HTTPS ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಲು ಅನುಮತಿ ಅಲ್ಲ, ಮತ್ತು ಸಾಮಾನ್ಯ SOCKS ಪೋರ್ಟ್ ಅವುಗಳನ್ನು ಸ್ವೀಕರಿಸಬಹುದು ಎಂಬ ಖಾತರಿಯೂ ಅಲ್ಲ.
ಕ್ಲೈಂಟ್ ಆಯ್ಕೆ ಮಾಡಿದ ಮಾರ್ಗ, ಸ್ಥಳೀಯ ವಿಭಾಗ ಮತ್ತು ನಿಜವಾದ ಫಾರ್ವರ್ಡಿಂಗ್ ಸಾಧನವನ್ನು ದಾಖಲಿಸಿ. ಪ್ರಾಕ್ಸಿ ಲಾಗ್ ಇಲ್ಲದಿರುವುದು ಲಾಗಿಂಗ್ ವೈಫಲ್ಯವಲ್ಲ, ಟೋಪಾಲಜಿಯ ಸರಿಯಾದ ವಿವರಣೆಯಾಗಿರಬಹುದು.