שליחת בקשות Squid דרך פרוקסי אב

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

ב-Squid 6.13, הדוגמה הזאת מגדירה אב אחד ואוסרת העברה ישירה למקור עבור מקור לקוח אחד:

cache_peer 192.0.2.20 parent 3128 0 no-query default name=upstream
acl routed_client src 198.51.100.27/32
never_direct allow routed_client

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

בדקו את כללי הניתוב הקיימים

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

עברו על הגדרות always_direct קיימות ועל בחירות עמיתים אחרות לפני הוספת הבלוק. דחיית התאמה ב-always_direct אינה מחייבת לבדה שימוש באב. כלל never-direct המפורש מבטא את הדרישה ללקוח שנבחר.

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

בדקו את המסלול ואת ההתנהגות בכשל

השתמשו ביעד שבשליטתכם והשוו מידע היררכיה ביומן הגישה לתצפיות ביעד. סטטוס HTTP סופי לבדו אינו אומר אם Squid השתמש באב או במסלול ישיר.

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