לקרוא שגיאת SO_ORIGINAL_DST של Squid

NF getsockopt(SO_ORIGINAL_DST) מצביע על חיפוש היעד המקורי. בתצורת יירוט, Squid צריך לשחזר לאן החיבור שהופנה מחדש היה אמור להגיע במקור.

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

לכן אי-ההתאמה הזו עלולה להיכשל לפני שהתעודה של היעד הופכת רלוונטית.

התחילו מאיך שהחיבור הגיע

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

התיעוד של Squid בנושא http_port מבהיר את ההבדל: השמטת דגל מצב בוחרת במצב פרוקסי מקדמי; intercept מצפה ליירוט NAT בשכבת ה-IP.

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

אל תעתיקו “תיקון HTTPS” ישן שמפעיל יצירת תעודות רק מפני שכתובת היעד מתחילה ב-HTTPS. תקנו קודם את ההתאמה בין הלקוח למאזין. אם נשארת אחר כך שגיאת TLS אמיתית, זו תהיה שגיאה שימושית יותר לחקור.