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 निवड आहे, प्रॉक्सी वापरण्याची परवानगी नाही. outgoing-address नियम नाकारलेली विनंती http_access मधून जाऊ देत नाही.

बहु-पत्ता कॉन्फिगरेशन अपग्रेडनंतर काम करणे थांबवत असल्यास पुरावे वेगळे करा: parse त्रुटी कॉन्फिगरेशन सिंटॅक्सकडे निर्देश करते; access denial नियम जुळणीकडे; चुकीच्या exit सह अनुमत विनंती outgoing selection किंवा नंतरच्या NAT कडे. तिन्ही एकत्र बदलल्यास छोटी ACL चूक शोधणे खूप कठीण होते.