VPN משני שייך לפרופיל Wi-Fi אחד, לא לכולם

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

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

מהו בעצם משני

לחיבור בסיס יש זהות, UUID ורשימה של משניים. כשמפעילים אותו, המנהל מפעיל גם את המשניים האלה לפי הסדר, וכך VPN עוקב אחרי רשת Wi-Fi בלי לחיצה ידנית. הקשר חי על חיבור הבסיס, כתוב כמחרוזות UUID ולא כשמות. הבחירה הזאת בייצוג אינה מקרית; היא מה שמאפשר לשיוך לשרוד שינוי שם.

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

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

הציבו את השיוך במקום שבו נוצרים הפרופילים

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

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

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

תכננו את שינוי הזהות של ה-VPN

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

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

הפעלה אינה אכיפה

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

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

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

בדקו עם פרופיל חדש באמת

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

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