Squid ವಿನಂತಿಗಳನ್ನು ಪೇರೆಂಟ್ ಪ್ರಾಕ್ಸಿಯಿಂದ ಕಳುಹಿಸಿ

Squidನಲ್ಲಿ ಪೇರೆಂಟ್ ಘೋಷಿಸಿದಷ್ಟರಿಂದ ಪ್ರತಿಯೊಂದು ಫಾರ್ವರ್ಡ್ ವಿನಂತಿ ಅದನ್ನು ಕಡ್ಡಾಯವಾಗಿ ಬಳಸುವುದಿಲ್ಲ. ನೇರ ಮಾರ್ಗ ನೀತಿಯನ್ನು ಉಲ್ಲಂಘಿಸಿದರೆ ಆ ಅವಶ್ಯಕತೆ ಸ್ಪಷ್ಟವಾಗಿ ಹೊಂದಿಸಿ ಮತ್ತು ಪೇರೆಂಟ್ ಇಲ್ಲದಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ಪರೀಕ್ಷಿಸಿ.

Squid 6.13ನ ಈ ಉದಾಹರಣೆ ಒಂದು ಪೇರೆಂಟ್ ಹೆಸರಿಸಿ ಒಂದು ಕ್ಲೈಂಟ್ ಮೂಲಕ್ಕೆ ಮೂಲ ಸರ್ವರ್‌ಗೆ ನೇರವಾಗಿ ಕಳುಹಿಸುವುದನ್ನು ನಿಷೇಧಿಸುತ್ತದೆ:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream
acl routed_client src 198.51.100.27/32
never_direct allow routed_client

ಎರಡೂ ವಿಳಾಸಗಳು ಮಾದರಿಗಳು. ಸಾರ್ವಜನಿಕ HTTP ಪೇರೆಂಟ್ ಅನುಮತಿಸಿದ ನಿಯಂತ್ರಿತ ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಪರೀಕ್ಷೆಗೆ HTTP ಪ್ರಾಕ್ಸಿ ಪಟ್ಟಿಯಿಂದ ವಿಳಾಸ ಆಯ್ಕೆ ಮಾಡಿ. ಬೇಕಾದ ಕ್ಲೈಂಟ್‌ಗಳಿಗೆ ಮಾತ್ರ ಅನುಮತಿ ಕೊಡುವ ಪ್ರತ್ಯೇಕ http_access ನೀತಿ ಉಳಿಸಿ. ರೂಟಿಂಗ್ ನಿಯಮ ಕ್ಲೈಂಟ್‌ಗೆ ಪ್ರಾಕ್ಸಿ ಬಳಸುವ ಅಧಿಕಾರ ನೀಡುವುದಿಲ್ಲ.

ಈಗಿರುವ ರೂಟಿಂಗ್ ನಿಯಮ ಪರಿಶೀಲಿಸಿ

no-query ಈ peerಗೆ ICP ಪ್ರಶ್ನೆಗಳನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಶೂನ್ಯ peerನ ಪ್ರಶ್ನೆ ಪೋರ್ಟ್; ಅದರ HTTP ಲಿಸನರ್ ಅಲ್ಲ. ಕ್ಲೈಂಟ್‌ಮುಖದ ಲಿಸನರ್ ಮತ್ತು ಪ್ರವೇಶ ನಿಯಮಗಳು ಪ್ರತ್ಯೇಕವಾಗಿರುತ್ತವೆ.

ಈ ಬ್ಲಾಕ್ ಸೇರಿಸುವ ಮೊದಲು ಈಗಿರುವ always_direct ಸೆಟ್ಟಿಂಗ್ ಮತ್ತು ಬೇರೆ peer ಆಯ್ಕೆ ನೋಡಿ. always_directನಲ್ಲಿ ಹೊಂದಿಕೆಯನ್ನು ನಿರಾಕರಿಸುವುದೇ ಪೇರೆಂಟ್ ಕಡ್ಡಾಯ ಮಾಡುವುದಿಲ್ಲ. ಸ್ಪಷ್ಟ never-direct ನಿಯಮ ಆಯ್ದ ಕ್ಲೈಂಟ್‌ಗೆ ಈ ಅಗತ್ಯ ತಿಳಿಸುತ್ತದೆ.

ಇದು ಫಾರ್ವರ್ಡ್ ಅಗತ್ಯವಿರುವ ವ್ಯವಹಾರಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಬಳಕೆಗೆ ಬರುವ ಸ್ಥಳೀಯ ಕ್ಯಾಶ್ ಎಂಟ್ರಿ ಪೇರೆಂಟ್ ಸಂಪರ್ಕಿಸದೆ ನೀಡಬಹುದು; ಆದ್ದರಿಂದ ಹೊಸ ಪೇರೆಂಟ್ ಸಂಪರ್ಕ ಇಲ್ಲದಿರುವುದೇ ರೂಟಿಂಗ್ ಉಲ್ಲಂಘನೆ ಅಲ್ಲ.

ಮಾರ್ಗ ಮತ್ತು ವಿಫಲ ವರ್ತನೆ ಪರಿಶೀಲಿಸಿ

ನಿಯಂತ್ರಿತ ಗಮ್ಯಸ್ಥಾನ ಬಳಸಿ ಪ್ರವೇಶ ಲಾಗ್‌ನ hierarchy ಮಾಹಿತಿಯನ್ನು ಗಮ್ಯಸ್ಥಾನದ ಗಮನಿಕೆಯೊಂದಿಗೆ ಹೋಲಿಸಿ. ಕೊನೆಯ HTTP ಸ್ಥಿತಿ ಮಾತ್ರ Squid ಪೇರೆಂಟ್ ಅಥವಾ ನೇರ ಮಾರ್ಗ ಬಳಸಿದೆಯೆಂದು ಹೇಳುವುದಿಲ್ಲ.

ನಿರ್ವಹಣೆ ಪರೀಕ್ಷೆಯಲ್ಲಿ ಪೇರೆಂಟ್ ಲಭ್ಯವಿಲ್ಲದಂತೆ ಮಾಡಿ ಅದೇ ಕ್ಯಾಶ್ ಇಲ್ಲದ ವಿನಂತಿ ಪುನರಾವರ್ತಿಸಿ. ನೀತಿ ನೇರ ಫಾರ್ವರ್ಡ್ ನಿಷೇಧಿಸಿದರೆ ವ್ಯವಹಾರ ಬೇರೆ ಮಾರ್ಗದಿಂದ ಮೂಲಕ್ಕೆ ಹೋಗದೆ ವಿಫಲವಾಗಬೇಕು. ನಿಮ್ಮ ನಿಯಂತ್ರಣದ ಸೇವೆಗಳಲ್ಲಷ್ಟೇ ಮಾಡಿ, ನಂತರ ನಿರೀಕ್ಷಿತ ಹೊಂದಿಕೆ ಮರುಸ್ಥಾಪಿಸಿ.