שער ה-VPN שלך עדיין זקוק לדרך להתקין עדכונים

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

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

פלט מקומי אינו העברת לקוחות

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

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

נקוב בשם השלב שנכשל

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

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

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

קרא את רשימת המקורות לפני הוספת כלל

פרט את כתובות ה-URI האמיתיות של המקורות ואת תצורת הפרוקסי האפקטיבית, ולא את אלה שאתה זוכר. כלל שנכתב עבור HTTP פשוט חסר תועלת כשהמקור הוא HTTPS, ופרוקסי שהמעטפת מכירה עשוי להיות בלתי נראה לשירות שמופעל בעת האתחול עם סביבה אחרת.

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

שים לב לאילו משפחות כתובות המקורות נפתרים. כלל שמתיר IPv4 בלבד ימשיך להיכשל במארח שהמקורות שלו מעדיפים רשומת AAAA, והשגיאה נראית לסירוגין משום שהיא תלויה באיזו תשובה מגיעה ראשונה.

בחר נתיב תחזוקה אחד והיצמד אליו

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

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

אמת בלי להחליש את הבדיקות

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

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

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