एका क्लायंट IPसाठी Squid 6 प्रवेश नियम
Squid 6.13 फॉरवर्ड प्रॉक्सी ज्ञात क्लायंटपुरती मर्यादित करा, गंतव्य सुरक्षा ठेवा आणि लागू करण्यापूर्वी नियमक्रम तपासा.
ही मांडणी Squid 6.13साठी आहे, Debian 13च्या पॅकेजसह. स्थापित आवृत्ती squid -vने तपासा; Squidच्या निर्देश संदर्भात http_access आवृत्ती 8मध्ये उपलब्ध नसल्याचे नमूद आहे.
आधी पत्ते निवडा
लिसनरला सर्व्हरला दिलेला पत्ता हवा. क्लायंट नियमाला Squidला दिसणारा स्रोत पत्ता हवा; तो लॅपटॉपचा खासगी पत्ता नसून NAT नेटवर्कचा सार्वजनिक निर्गमन पत्ता असू शकतो.
खालील दस्तऐवजी पत्ते बदला. क्लायंट निर्बंध एक पत्ता आहे, /32 म्हणून दाखवलेला.
http_port 192.0.2.10:3128
acl proxy_client src 198.51.100.27/32
acl Safe_ports port 80 443
acl SSL_ports port 443
acl CONNECT method CONNECT
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny manager
http_access deny to_localhost
http_access deny to_linklocal
http_access allow proxy_client
http_access deny all
पॅकेज मांडणीतील संबंधित लिसनर, ACL व्याख्या आणि प्रवेश नियम बदला, पण लॉगिंग व फाइल प्रणाली सेटिंग ठेवा. आधीच्या क्लायंट परवानगीखाली हे नियम जोडल्यास निर्बंध टाळला जाऊ शकतो. सूची ACLच्या पुनरावृत्त व्याख्याही मूल्ये जोडू शकतात.
विनंत्या नियमांतून कशा जातात
सुरुवातीच्या नकारांत नको असलेले गंतव्य पोर्ट, व्यवस्थापन विनंत्या आणि स्थानिक किंवा link-local गंतव्ये नाकारली जातात. या तपासणीनंतर ज्ञात क्लायंटला परवानगी मिळते; बाकी सर्व विनंत्या अंतिम नकारापर्यंत जातात. गंतव्य सुरक्षा अजूनही गरजेची आहे, कारण केवळ स्रोत परवानगी सूची गंतव्ये मर्यादित करत नाही.
लिसनर उघडण्यापूर्वी होस्ट किंवा नेटवर्क फायरवॉल इच्छित स्रोतापुरता मर्यादित करा. बाइंडिंग Squid कुठे जोडण्या स्वीकारतो ते ठरवते; प्रवेश नियम कोणत्या विनंत्यांना परवानगी ते ठरवतात.
sudo squid -k parse -f /etc/squid/squid.conf
व्यवस्थापित सेवा पुन्हा लोड करण्यापूर्वी पार्स त्रुटी सुधारा. परवानगी असलेल्या क्लायंटकडून आणि नाकारायला हवा अशा दुसऱ्या नियंत्रित स्रोताकडून चाचणी करा. लक्ष्याला केवळ अधिकृत विनंती मिळते हे तपासा; एकटी TCP जोडणी पुढे पाठवण्याची परवानगी सिद्ध करत नाही.