Squid ನ myportname ಮತ್ತು src ಅನ್ನು ಪ್ರತ್ಯೇಕ ACL ಗಳೊಂದಿಗೆ ಸೇರಿಸುವುದು

ಸಂರಚನೆಯು ಮೊದಲ ನೋಟಕ್ಕೆ ಸಮಂಜಸವಾಗಿ ಕಾಣುತ್ತದೆ:

acl team_a myportname 3128 src 198.51.100.0/24

ಆದರೆ ACL ವ್ಯಾಖ್ಯಾನಕ್ಕೆ ಒಂದೇ ಪ್ರಕಾರ ಇರುತ್ತದೆ. ಇಲ್ಲಿ myportname ಪ್ರಕಾರ; src ಪದವನ್ನು ಸೇರಿಸಿದರೆ ಎರಡನೇ ಪರೀಕ್ಷೆ ಆರಂಭವಾಗುವುದಿಲ್ಲ. ಉಳಿದ ಪದಗಳು ಮೊದಲ ಪ್ರಕಾರದ ಮೌಲ್ಯ ಪಟ್ಟಿಗೆ ಸೇರುತ್ತವೆ. ಆ ಸಾಲು “ಈ listener ಮತ್ತು ಈ ಕ್ಲೈಂಟ್ ನೆಟ್‌ವರ್ಕ್” ಎಂದು ಹೇಳುವುದಿಲ್ಲ.

ಪ್ರತಿ ಷರತ್ತಿಗೆ ಹೆಸರು ನೀಡಿ

ಕೇಳುವ socket ಗೆ ಹೆಸರು ಮತ್ತು ಮೂಲಕ್ಕೆ ಪ್ರತ್ಯೇಕ ACL ಬಳಸಿ. ಈ ತುಣುಕು ದಾಖಲೆ ವಿಳಾಸಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಅವುಗಳನ್ನು ನಿಯೋಜನೆಗೆ ಸೂಕ್ತವಾದ ವಿಳಾಸಗಳಿಂದ ಬದಲಾಯಿಸಬೇಕು:

http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24

http_access allow team_a_port team_a_clients
http_access deny all

ಅಸುರಕ್ಷಿತ ಗಮ್ಯವಾಹಿನಿ ಪೋರ್ಟ್‌ಗಳು, ಸೀಮಿತ CONNECT ಗುರಿಗಳು ಮತ್ತು ನಿರ್ವಹಣಾ ಪ್ರವೇಶಕ್ಕೆ ಇರುವ ರಕ್ಷಣೆಗಳ ನಂತರ allow ನಿಯಮವನ್ನು ಇರಿಸಿ. ತುಣುಕು ಕ್ಲೈಂಟ್/listener ಷರತ್ತನ್ನು ತೋರಿಸುತ್ತದೆ; ಅದು ಆ ರಕ್ಷಣೆಗಳನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ.

ಒಂದು http_access ಸಾಲಿನ ಷರತ್ತುಗಳು AND ನಿಂದ ಸೇರುತ್ತವೆ. ಎರಡು ಪ್ರತ್ಯೇಕ allow ಸಾಲುಗಳು ಪ್ರತಿ ಷರತ್ತನ್ನು ಸ್ವತಂತ್ರವಾಗಿ ಅನುಮತಿಸುತ್ತಿದ್ದವು, ಇದು ನೀತಿಯನ್ನು ಬಹಳ ಬದಲಾಯಿಸುತ್ತಿತ್ತು. ಒಂದು ACL ಒಳಗಿನ ಹಲವು ಮೌಲ್ಯಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಆ ಒಂದೇ ಪರೀಕ್ಷೆಗೆ ಪರ್ಯಾಯಗಳನ್ನು ನೀಡುತ್ತವೆ.

ನಿರ್ಗಮನವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಆರಿಸಿ

ಹೊಂದುವ listener ಅನ್ನು tcp_outgoing_address ಮೂಲಕವೂ ಸ್ಥಳೀಯ ಮೂಲ ವಿಳಾಸ ಆರಿಸಲು ಬಳಸಬಹುದು. ಅದು routing ಆಯ್ಕೆ, proxy ಬಳಕೆಯ ಅನುಮತಿ ಅಲ್ಲ. outgoing-address ನಿಯಮವು ನಿರಾಕರಿಸಿದ ವಿನಂತಿಯನ್ನು http_access ಮೂಲಕ ಹಾದುಹೋಗಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಬಹು-ವಿಳಾಸ ಸಂರಚನೆಯು ಅಪ್‌ಗ್ರೇಡ್ ನಂತರ ಕೆಲಸ ಮಾಡದಿದ್ದರೆ ಸಾಕ್ಷ್ಯವನ್ನು ಬೇರ್ಪಡಿಸಿ: parse ದೋಷ ಸಂರಚನಾ ವಾಕ್ಯರಚನೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ; access denial ನಿಯಮ ಹೊಂದಾಣಿಕೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ; ತಪ್ಪು exit ನೊಂದಿಗೆ ಅನುಮತಿಸಿದ ವಿನಂತಿ outgoing selection ಅಥವಾ ನಂತರದ NAT ಅನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಮೂರನ್ನೂ ಒಟ್ಟಿಗೆ ಬದಲಿಸಿದರೆ ಸಣ್ಣ ACL ತಪ್ಪನ್ನು ಹುಡುಕುವುದು ಬಹಳ ಕಷ್ಟವಾಗುತ್ತದೆ.