כלל allow אחד ב-Squid משמעו AND; שניים יכולים לשמע OR
קראו שילובי ACL של Squid וכללי גישה מסודרים כדי שפרוקסי פרטי ייתן רק את הגישה המיועדת.
קראו את המדיניות הזו בקול: אפשרו לרשת המשרד להשתמש בפרוקסי ביעד המאושר. אם התנאים האלה שייכים יחד, החזיקו אותם יחד בכלל.
http_access allow office_clients approved_destination
שני ה-ACL חייבים להתאים כדי שהשורה הזו תאפשר את הבקשה. פיצול שלה משנה את המדיניות:
http_access allow office_clients
http_access allow approved_destination
כעת אפשר להתיר לקוחות משרד בלי הגבלת היעד, ובקשות ליעד הזה בלי הגבלת המשרד, אלא אם כלל קודם דחה אותן. שתי שורות אינן כתיב קריא יותר של שורה אחת.
הסדר הוא חלק מהמדיניות
Squid מעריך כללי גישה לפי הסדר. ההחלטה הראשונה שמתאימה שולטת בבקשה. allow all מוקדם מבטל הגבלה מאוחרת זהירה; דחייה מתאימה מוקדמת מונעת הגעה להתרה מאוחרת.
התיעוד של http_access מסביר את הסדר הזה. החזיקו דחייה סופית מכוונת במקום להסתמך על כך שהקורא יזכור את התנהגות ברירת המחדל המשתמעת.
להרבה הגדרות ACL יש יחס OR שונה: ACL מקור אחד בעל שם יכול לפרט כמה טווחים מותרים. זה לא הופך את זהות המקור והיעד לאותו סוג ACL. הגדירו אותם בנפרד, ואז שלבו את השמות בהחלטת גישה.
ביציאה פרטית זה משפיע על מי יכול להשתמש בכתובת ה-IP החיצונית שלכם. שקלו ארבעה מקרים: לקוח מאושר ליעד מאושר, לקוח מאושר למקום אחר, לקוח אחר ליעד המאושר, ולקוח אחר למקום אחר. אם הכללים מתירים יותר מקרים ממה שהמדיניות מתכוונת, תקנו את ההיגיון לפני הרחבת המאזין. תצורה תקינה תחבירית עדיין יכולה לבטא הרשאות שגויות.