Git 403 עם VPN מחובר: למצוא מי עונה
403 הוא תגובה, לא פסק דין על ה-VPN. זהו איזה רכיב סירב לבקשה, ואז השוו משתנה אחד בכל פעם בין רשתות ותעדו מה השתנה.
זה עובד ב-Wi-Fi של המשרד ונכשל בנקודת הגישה של הטלפון, כשה-VPN מחובר בשני המקרים. Git מחזיר 403 והשגיאה היא שלוש שורות. הפיתוי הוא לראות בנקודת הגישה את הסיבה ולשנות הגדרות רשת עד שמשהו זז. HTTP 403 פירושו ששרת הבין את הבקשה וסירב לה, ולכן השאלה המועילה היא איזה שרת, והצעד הבא המועיל הוא השוואה שמשנה דבר אחד בכל פעם.
קראו את הסטטוס לפני הרשת
403 אינו כשל חיפוש, לא פסק זמן של TCP ולא לחיצת יד של TLS שלא הושלמה. זו החלטה, שקיבל משהו שניתוח את הבקשה שלכם.
עד שתדעו מה קיבל את ההחלטה הזו, כל שינוי רשת שתנסו הוא ניחוש עם סיפור סביר.
מי יכול לענות ב-403?
אפליקציית המאגר היא רק מועמדת אחת. פרוקסי, שער או שירות סינון יכולים לשבת לפניה ולענות ראשונים, והלקוח רואה את אותו סטטוס בשני המקרים. שמרו את הסטטוס, את הכותרות הרלוונטיות ואת גוף שגיאה מסונן, ואז תאמו אותם עם יומני השירות המורשה. כתובת ה-URL המרוחקת ונקודת הקצה שאליה הגעתם בפועל יכולים גם הם להיות שונים בגלל DNS או תצורת פרוקסי, לכן בדקו את הכתובת המוגדרת ואת התהליך ששולח את הבקשה.
אם הסירוב מעולם לא הגיע למאגר, היומנים שלו יהיו שקטים, והשתיקה הזו היא ראיה.
השוו משתנה אחד בכל פעם
ההשוואה לנקודת הגישה מועילה כי היא מצמצמת את הבעיה, לא כי היא מוכיחה סיבה. שתי רשתות יכולות להיות שונות באותו רגע בכתובות, במשפחת IP, בפרוקסי, במשא ומתן TLS ובמדיניות יציאה.
שנו דבר אחד בכל ניסיון ותעדו את השאר. הטבלה שלמטה היא המינימום שאני שומר בהערה בזמן שאני עושה זאת:
| Keep constant | Record when it changes |
|---|---|
| Repository, operation and credentials | Resolved address and IP family |
| Git process and configuration | Proxy use and the responding component |
| Intended VPN profile | Actual route and exit seen by the service |
שורה אחת ששונה בין הריצה שעובדת לזו שנכשלת היא המקום שאליו הולכת השעה הבאה.
עקיפה היא ראיה, לא הסבר
כפיית משפחת כתובות אחרת יכולה לשנות את היעד, את המסלול או את המתווך שנבחר, ולכן היא יכולה לשנות את התוצאה בלי להוכיח ש-IPv6 אינו תואם למאגר. גרסת TLS אחרת שנוהלה היא תצפית באותה קטגוריה. אף אחת מהן אינה מצדיקה לכבות בדיקות תעודות או להחליש את החיבור. עקבו אחרי המדיניות והיומנים של הרכיב שסירב עד להחלטה בפועל, במקום לעצור בשינוי הראשון שעובד.
עקיפה שלא תצליחו להסביר תיכשל שוב במקום אחר.
כתבו דוח שאפשר לתקן
תנו לבעל הרכיב שענה את אותה פעולה, שני נתיבים ואת הרכיב שאמר לא. הסירו כותרות הרשאה, פרטי התחברות מוטמעים ופרטי מאגר פרטיים לפני שמשתפים משהו.
הדוח המועיל קצר, ניתן לשחזור ומציין את השכבה ולא את התסמין.
הבדיקה שאני מבצע, לפי הסדר
ודאו את כתובת ה-URL המרוחקת ואת נקודת הקצה שנפתרה, ואז תעדו את הסטטוס והכותרות מריצה שנכשלת. חזרו על אותה פעולה ברשת שנייה והשוו בין שני התיעודים.
אחר כך הביאו את ההפרש הזה לרכיב שענה:
- תצורת פרוקסי בלקוח וברשת.
- מדיניות יציאה או סינון לפני המאגר.
- היקף האסימון או החשבון, כולל תפוגה ותנאי SSO.
- הרשאת המאגר לזהות שהאסימון מייצג.
הסמנטיקה של הסטטוס עצמו מופיעה במסמך RFC 9110, וכדאי לצטט אותה כשכותבים את הדוח.