עדכון שער ה-VPN נכשל: קראו את השלב לפני שפותחים את היציאה
עדכון שנכשל מציין שלב, לא פורט חסר. התאימו את ההודעה לבעלים שלה, קראו את נתיב ה-proxy ואז החליטו במכוון על מדיניות התחזוקה.
סירוב להתקין עדכוני אבטחה הוא שבוע רע אחד בלבד מלהפוך לבעיה של מישהו אחר, ושער שמכניס לקוחות הוא המקום הקל ביותר לפתח את ההרגל הזה. הסיבה הרגילה אינה מסלול חסר אלא החלטה חסרה: איש לא אמר איך המארח עצמו אמור להגיע למאגר כשהעברת הלקוחות צרה בכוונה. ההחלטה הזו חייבת להתקבל במפורש, והיא חייבת להיות צרה יותר מכיבוי מדיניות היציאה אחר צהריים אחד.
ארבעה שלבים, ארבעה בעלים שונים
כשל עדכון הוא שלב בעל שם, בין אם ההודעה אומרת זאת ובין אם לא, וכל שלב שייך לבעלים אחר. שם שאינו נפתר הוא שאלה לפותר. חיבור שפג תוקפו הוא שאלה לתעבורה, ל-proxy או לקצה המרוחק. שגיאת זהות TLS היא שאלת אמון, ו מטא-נתוני מאגר שנדחו הם שאלת חתימה. ארבעה שלבים, ארבעה בעלים, וכלל פורט עונה תמיד רק על אחד מהם.
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
פינג ופתרון שמות הם שני המבחנים שאנשים פונים אליהם קודם, ושניהם עונים על שאלות שאיש לא שאל. תגובת הד היא פרוטוקול שונה מחיבור המאגר, וחיפוש מוצלח נעצר בפתרון שמות בלי לבחון את ההורדה. שניהם יכולים לעבור בזמן שהעסקה האמיתית נכשלת, ושניהם יכולים להיכשל מסיבות שאינן קשורות לנתיב.
קראו את הנתיב שהמנהל באמת עובר בו
בדקו את כתובות ה-URI של המקור שהוגדרו ואת סידור ה-proxy בפועל במקום להניח אחד מהם. כלל שנכתב ל-HTTP פשוט אינו תיקון כשהמאגר מדבר ב-HTTPS, וארגון שמחייב proxy כבר בחר את הנתיב. מנהלי חבילות מכבדים משתני סביבה ואת התצורה שלהם, והגדרות ספציפיות למארח יכולות לעקוף הגדרה גלובלית. מה שדפדפן אינטראקטיבי עושה אינו חייב להיות מה שהמנהל עושה.
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyתיעוד התעבורה של APT מתאר אילו הגדרות חלות על איזו סכימת URI ואיך נכתבות בחירות ספציפיות למארח. שמרו את פלט הפקודות עם הכרטיס, משום שהוא מפריד בין בעיית proxy למסלול חסר מהר יותר מכל מספר של תוצאות פינג. רשמו את היעד, הפורט והפרוטוקול המדויקים שהמנהל מנסה, ותנו לשינוי בחומת האש להישען על הרשומה הזו ולא על כתובת מראה משוערת שמתיישנת בתוך חודשים.
בחרו מדיניות תחזוקה, לא חריגה
שלוש מדיניות ניתנות להגנה: תחזוקה דרך המנהרה, תחזוקה דרך proxy עדכונים מנוהל, או תחזוקה דרך מסלול ישיר מורשה באופן צר. כל אחת מהן מניחה סידור פותר שמתאים לה. מה שאינו ניתן להגנה הוא חריגה שהופכת בשקט למסלול חלופי בלתי מוגבל בכל פעם שהמנהרה נופלת.
רשמו את המדיניות שנבחרה עם בעלים, משום שהמפעיל הבא ימצא את הכלל ולא את הנימוק שמאחוריו. החילו את ההרשאה דרך חומת האש הקיימת ובעל הרשת במקום לרוקן כללים או להוסיף מנהל מדיניות שני למארח אחד. כסו את משפחות הכתובות ואת נקודות הקצה של השירות שהמקור האמיתי משתמש בהן, ועיינו ברשימה כשהמאגר עובר.
אמתו בלי להחליש את האמון
תעבורה מוצלחת אינה רשות להקל באימות: אימות הארכיון וזהות שרת ה-TLS הם שני בדיקות נפרדות, וכיבוי מי מהן מעלים שגיאה תוך שינוי מה המארח יקבל. proxy מיירט הוא החלטת אמון של בעל הרשת ולא סיבה לכבות את הבדיקה מקומית, ופרטי הכניסה של המאגר אינם שייכים לאבחון משותף, משום שיומן מפורט הוא המקום הקל ביותר להדליף אותם.
קבלו את השינוי בשליפת מטא-נתונים מבוקרת ואחריה עסקת חבילה אחת מאושרת, ואז בדקו מה קורה כשהמנהרה נופלת. נתיב תחזוקה שמתרחב בשקט בזמן תקלה גרוע מזה שנכשל סגור, והתוצאה צריכה להיות נתיב עדכונים עם בעלים בעל שם והיקף מוגבל.