האתרים נטענים דרך VPN, אבל apt לא מגיע למאגר

ה-VPN מתחבר, הוויקי הפנימי נטען בדפדפן, ו-apt update עדיין נתקע על מראה שהוא לא מצליח להגיע אליה. בתמונה הזאת שום דבר במנהרה לא שבור. הדפדפן ומנהל החבילות קיבלו שתי החלטות proxy נפרדות, ורק אחת מהן הייתה מוגדרת.

איזו החלטה נכשלה הוא הדבר היחיד ששווה לקבוע קודם.

קראו את השגיאה לפני שאתם נוגעים בהגדרה

כל שלב משאיר הודעה אחרת. שם שלעולם לא נפתר הוא DNS, חיבור שלעולם לא מושלם הוא ניתוב או חומת אש, 407 מיידי הוא אימות proxy, תלונה על התעודה היא אימות TLS, ואזהרה על חתימה היא מטא-נתונים של המאגר. חמשת הכשלים האלה דורשים חמישה תיקונים שונים, ושורת proxy שהודבקה מעל בעיית DNS רק מזיזה את התקיעה.

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

ל-APT יש הגדרות proxy משלו

APT קורא את /etc/apt/apt.conf.d/, את apt.conf הראשי ואת כל קובץ ש-APT_CONFIG מציין. הוא לא קורא פרופיל proxy של שולחן העבודה, הגדרת רשת של GNOME או תוסף דפדפן. לעומת זאת התעבורה מכבדת משתני סביבה של proxy, ולכן export https_proxy=... שעובד במעטפת שלכם לא מוכיח דבר לגבי טיימר שרץ בסביבה אחרת.

הדפיסו את מה שהתהליך שנכשל באמת רואה: apt-config dump | grep -i proxy.

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

הגדירו את ה-proxy במקום שבו בעל התצורה מצפה לו

עבור proxy מפורש שאושר על ידי המנהל, מספיק קטע קטן בקובץ חדש:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

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

הוסיפו את הקטע כקובץ חדש וממוספר, למשל /etc/apt/apt.conf.d/95proxy. דריסה של קובץ הפצה פירושה שהעדכון הבא של החבילות יחזיר את השינוי שלכם בשקט.

פרטי ההתחברות נשארים מחוץ ל-URI

אזכור התעבורה של APT מפנה לאימות אל apt_auth.conf, ושם שייכים שם המשתמש והסיסמה. הטמעתם ב-URI של ה-proxy שמה אותם ברשימות תהליכים, בהיסטוריית המעטפת ובכל הדפסת תצורה ששמודבת לכרטיס. קובץ האימות זקוק להרשאות מגבילות, כי הוא מאגר של פרטי התחברות.

בדקו גם את הסכימה. מאגר HTTPS עדיין נגיש דרך proxy HTTP, והתעבורה היא בחירה נפרדת מסכימת ה-URI של המראה.

מרכז תוכנה גרפי הוא חזית נפרדת. אם הוא משתמש ב-PackageKit או ב-backend של snap, הקטע של APT לא משנה עבורו דבר, אז ודאו איזה תהליך ביצע את הבקשה שנכשלה.

אמתו את המסלול, לא רק את קוד היציאה

כשהקטע במקום, עקבו אחרי הבקשה במקום לסמוך על תוצאה ירוקה. apt-get -o Debug::Acquire::http=true update מדפיס את ניסיון החיבור, את ה-proxy שנבחר ואת קוד התגובה, וזה מפריד בין proxy שגוי ל-proxy שסירב לכם.

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

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