פרוטוקול PROXY של Squid: סמכו על השולח לפני בדיקות גישה ל-HTTP

השתמשו ב-proxy_protocol_access כדי לסמוך על הממסר שמספק את המטא-נתונים, ולא כדי לבחור אתרים מורשים. ב-Squid 5–7 הבדיקה רצה פעם אחת לאחר הקמת TCP במאזין require-proxy-header, לפני עיבוד כותרות בקשת ה-HTTP:

acl trusted_relay src 192.0.2.20/32
http_port 3128 require-proxy-header
proxy_protocol_access allow trusted_relay
proxy_protocol_access deny all

החליפו את כתובת הממסר בדוגמה והגבילו גישת רשת למאזין הזה. בשלב זה Squid בודק את עמית ה-TCP בפועל לפני קבלת המטא-נתונים שסופקו. לאחר הקבלה הוא משתמש בכתובת הלקוח הנטענת לבדיקות ACL ולתיעוד בהמשך. אמון בממסר על סמך כתובת הלקוח שהוא טוען לה היה הופך את הסדר הזה.

השאירו את http_access להרשאות המאוחרות של מקור הלקוח ושל היעד. קבלת מטא-נתונים אינה מאשרת גישה לאתרים, ו-ACL של תחום יעד אינו יכול לענות על השאלה המוקדמת בדבר האמון בשולח.

השולח והמקבל חייבים להסכים על גרסה נתמכת של פרוטוקול PROXY. לקוח HTTP רגיל אינו יכול להשתמש במאזין עם הקידומת החובה כנקודת קצה רגילה של פרוקסי. אם נדרשים שני המצבים, השתמשו במכוון בנקודות קצה נפרדות במקום לשכפל את אותה כתובת האזנה ואותו פורט.

ממסר מהימן יכול להשפיע על הרשאה מבוססת כתובת באמצעות זהות הלקוח שהוא מספק. העניקו יכולת זו רק למתווך המיועד.