למה 403 מאתר VPN אינו כשל של פרוקסי
403 מהמקור, CONNECT שנדחה ואתגר 407 מסמנים גבולות שונים. השוו תחילה את נתיב היציאה של הפרוקסי עם כתובת ה-VPN של הדפדפן.
משתמשים מנתקים את ה-VPN, נתקלים ב-403 באתר פנימי ומדווחים שהפרוקסי שבור. שלושה דברים נפרדים יכולים ליצור את הדף הזה: המקור סירב לבקשה, הפרוקסי הקדמי סירב לפתוח את המנהרה, או הפרוקסי דרש את האישורים שלו עצמו. כל אחד מהם הוא תשובה נכונה לשאלה אחרת, ורדידתם לדף כשל כללי אחד הורסת את הראיה היחידה שיש לכם. מיינו את הסירוב לפי הרכיב שיצר אותו, ואז השוו את נתיב הרשת שכל רכיב משתמש בו בפועל.
תנו שם לרכיב שהפיק את ה-403
קוד סטטוס HTTP שייך לצד ששלח אותו. כשהמקור מחזיר 403, הוא ניתח את הבקשה והחליט שהקורא אולי אינו מחזיק במשאב, וזו תשובת הרשאה ולא בעיית תעבורה. כשפרוקסי קדמי עונה 403 ל-CONNECT, הוא סירב לבנות את המנהרה כלל, ושום דבר במעלה הזרם לא נוצר איתו קשר. כשהוא עונה 407, הוא רוצה את האישורים שלו עצמו, שאין להם דבר עם הכניסה של היישום.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
RFC 9110 מגדיר את התפקידים האלה, כולל האתגר הייחודי לפרוקסי. קראו את הסטטוס של התגובה עצמה ואת כל כותרת Proxy-Authenticate לפני קריאת הגוף, כי דף שגיאת HTML ידידותי מסתיר בדרך כלל איזה רכיב כתב אותו.
מה מנהרת CONNECT מסתירה מממסר בתים
לאחר שפרוקסי מחזיר 200 ל-CONNECT, הוא מעביר בתים והדפדפן שומר על הפעלת ה-TLS שלו עם המקור. לכן פרוקסי שמעביר בתים אינו יכול לקרוא את ה-403 המוצפן בתוך אותה הפעלה, והוא לעולם אינו הופך לכותב הסירוב. סירוב לפני פתיחת המנהרה הוא אירוע אחר לגמרי, שנוצר שכבה אחת נמוך יותר.
פרוקסי הפוך שמסיים TLS נמצא בעמדה אחרת: הוא הבעלים של גבול ה-TLS, מנתח HTTP ויכול לשכתב או ליירט תגובות כדין. היכולת הזו היא בחירת תצורה, לא תכונה של פרוקסי באופן כללי, והיא אינה מתירה לעקוף את מדיניות הגישה של היישום. קריאת התגובה היא יכולת; ההחלטה מה הקורא רשאי לראות נשארת עבודתו של המקור.
ההשלכה המעשית היא שעליכם לדעת איזו משלוש הצורות אתם מריצים לפני שאתם מפרשים 403. הוספת כללי בדיקת HTTP לפרוקסי זרימה אינה נותנת לו נראות, וציפייה שממסר בתים יסביר סירוב של המקור תשלח אתכם לחפש ביומן הלא נכון.
השוו את נתיב היציאה של הפרוקסי עם כתובת המנהרה של הדפדפן
דפדפן המחובר ל-VPN אינו מעביר אוטומטית שרת פרוקסי נפרד אל אותה מנהרה. המקור רואה את כתובת היציאה של הפרוקסי, ואם הפרוקסי עדיין יוצא דרך נתיב ברירת המחדל המקומי, האתר המוגן רואה כתובת שמעולם לא הוגדר לבטוח בה. כתובת ה-VPN הפנימית במחשב הנייד אינה נראית לאותו מקור. זו הסיבה הנפוצה ביותר לכך שמנהרה שעובדת עדיין מחזירה 403 מאתר שמתנהג נכון כלפי כל האחרים.
בדקו את שני הנתיבים בנפרד כדי שלא ניתן יהיה לבלבל בין הכתובות.
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateהבקשה הראשונה מראה מה המקור עונה לכתובת שלכם, השנייה מראה מה הוא עונה לזו של הפרוקסי. זוג 403 תואם מצביע על כללי ההרשאה של המקור; 200 שאחריו 403 מצביע על נתיב הפרוקסי. שאלו את בעל המקור אילו כתובות מקור מערכת הכללים באמת מתירה, במקום להניח שמאגר ה-VPN נכלל.
בדקו כל גבול בבקשה שמבודדת אותו
בודדו את שכבת הפרוקסי בכך שתבקשו ממנה משהו שהיא אינה יכולה לסרב לו מסיבות יישומיות. CONNECT למארח שהפרוקסי רשאי להגיע אליו, כשהפלט נזרק, אומר לכם אם קבלת המנהרה עובדת בכלל.
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
אם זה מדפיס 200 ל-CONNECT ואחר כך לחיצת יד TLS, קבלת הפרוקסי תקינה וה-403 המאוחר הגיע מהמקור. אם זה מדפיס 407, ספקו אישורי פרוקסי עם --proxy-user וחזרו לפני שתסיקו מסקנה כלשהי על האתר. אם זה מדפיס 403 בשורת CONNECT, רשימת ההיתרים של הפרוקסי עצמו היא הגבול שיש לבדוק, והיישום אינו מעורב.
הרחיקו אישורים מהיסטוריית המעטפת ומתמלילים שהודבקו. סיסמת פרוקסי שהוקלדה בשורת פקודה גלויה למשתמשים מקומיים אחרים, ועקבות CONNECT שנלכדו עם אישורים גרועים מאין עקבות כלל.
השאירו את הפסיקה קריאה במקום לשכתב את הדף
לאחר שתדעו איזה רכיב סירב, שמרו על התשובה הזו. פרוקסי הפוך שמתייג מחדש 403 של המקור כזמן המתנה 504, או מחליף אותו בדף הצלחה, מסתיר החלטת הרשאה מאחורי סיפור זמינות ושולח את המגיב הבא לצוות הלא נכון. דפי שגיאה מותאמים אישית טובים כשהם שומרים על הסטטוס ומוסיפים הקשר.
מטמון ראוי לאותו טיפול. RFC 9111 קובע כיצד מטמונים משותפים רשאים לעשות שימוש חוזר בתגובות, ואסור למסור סירוב שנוצר עבור קורא אחד לאחר כאילו היה הרשאה. אם תגובות סירוב נשמרות בכלל, החזיקו אותן פרטיות ומוגבלות, ואל תוסיפו לעולם כלל רעננות ציבורי רק כדי לצמצם תעבורה במעלה הזרם.
סיימו בפסיקה כתובה שמציינת את הרכיב, את הסטטוס שהוא הפיק ואת כתובת המקור שהמקור ראה. תעדו את הבקשה המדויקת, את הגדרות הפרוקסי הבתוקף ואת הזמן, כדי שאפשר יהיה להתאים את הדוח הבא לאותן ראיות במקום לגזור אותן מחדש מהזיכרון. התיעוד הזה עונה לדוח הבא בתוך שניות ומונע אבחון חוזר של אותו 403 כהפסקת VPN.