אפליקציית VPN של הספק מול NetworkManager: למי שייך המצב?
פרופיל מכנה תוסף, לא את התנהגות לקוח הספק. מפו למי שייכים רישום, DNS, חסימה ועדכונים לפני החלפת מחשב נייד מנוהל.
ייבוא פרופיל אינו אותו דבר כמו החלפת לקוח. NetworkManager שומר סוג תוסף יחד עם נתונים וסודות ייחודיים לתוסף, והתוסף ששולט בסוג הזה הוא שמחליט מה החיבור יכול לעשות. כל מה שאפליקציית הספק מוסיפה מעל זה, מרישום ועד חסימה תמידית, חי מחוץ לקובץ. אם ההחלפה בטוחה תלוי באילו מהשכבות האלה אתם באמת מסתמכים.
הקובץ מכנה תוסף, לא סט תכונות
מדריך הגדרות VPN של NetworkManager מתאר סוג שירות שבוחר את התוסף, יחד עם מילון נתונים אטום ומילון סודות שרק התוסף מפרש. הפרופיל הוא חוזה עם מימוש אחד, לא תיאור של התנהגות שכל לקוח יכול לשחזר. שני לקוחות יכולים לדבר באותו פרוטוקול ובכל זאת להיבדל במה שהם מנהלים משא ומתן ובאילו נתיבי נתונים הם מאפשרים. תווית של פרוטוקול אומרת לכם מהו המנהור, לעולם לא מה הלקוח שסביבו עושה איתו.
השוו דרישות ולא עטיפות, אם כן. השאלה אינה אם החלופה יכולה להתחבר, כי בדרך כלל היא יכולה; השאלה היא אם כל דרישה שהפכה את הלקוח המקורי לקביל שורדת את המעבר. כתבו את הדרישות האלה לפני שאתם מתקינים משהו, אחרת ההשוואה הופכת למצוד אחר מה שיישבר ראשון.
מה אפליקציית הספק מוסיפה סביב המנהור
לקוחות ספקים בדרך כלל אוגדים רישום ובדיקות מצב של המכשיר, זרימת גורם שני עם ממשק משלה, חסימה תמידית, ערוץ עדכונים וכלי תמיכה. חלק מזה עומד לצד הפרוטוקול, וחלק הוא מוצר נפרד שרק חולק מתקין. NetworkManager יכול להחליף את המנהור ואת הניתוב שלו, וסקריפטים של שולח יכולים להפעיל פעולות כשמצב החיבור משתנה. אבל הוא אינו משחזר מנוע חסימה, תהליך חידוש תעודה או הנחה לגבי איזה משתמש רשאי להעלות את החיבור.
יותר רכיבים לא אומר בטוח יותר, ופחות לא אומר חלש יותר. השאלה היא איזה רכיב אוכף את המדיניות שנאמר לכם לפעול לפיה. אם מבקר שואל מה חוסם תעבורה כשהמנהור נופל, התשובה חייבת לנקוב במשהו שבאמת עושה זאת, ופרופיל שרק מתחבר אינו התשובה הזאת.
היכן הבעלות באמת שונה
קראו את זה כמפת בעלות ולא כרשימת בדיקה, כי הכשלים שלמטה הם פערי בעלות ושום כמות של תצורת לקוח לא סוגרת אותם. כל שורה מכנה את השכבה, את הצד שבדרך כלל מחזיק בה היום, ואת המקום שבו הפער נראה ראשון.
| Layer | Vendor application | NetworkManager connection | Where the gap shows up |
|---|---|---|---|
| Enrollment and posture | built into the client | absent unless something else supplies it | a managed device fails its next posture check |
| Address and resolver authority | the client sets both | the plugin plus dispatcher scripts | names resolve through the wrong resolver after a state change |
| Blocking on drop | a bundled engine | nothing by default | traffic continues in the clear after the tunnel dies |
| Upgrade path | the vendor's own channel | the distribution package and its plugin | a plugin update changes behaviour with no vendor note |
| Diagnostics and support | vendor tooling with client state | journal and dispatcher output | support cannot see why negotiation failed |
הצמידו לכל שורה תצפית שאפשר לחזור עליה ולא תחושה לגבי הלקוח. שם שנפתר דרך הפותר המיועד, נתיב שנעלם כשהמנהור נעצר, וחיבור חסום לאחר ניתוק מדומה הם שלוש תצפיות שביחד מכסות את רוב הטבלה. כתבו את התצפית לצד הדרישה שהיא מוכיחה, ושמרו את אלו שנכשלו, כי תצפית שנכשלה היא החלק היחיד ברשומה שחוזה את התקרית הבאה.
החלפה בלי בעלות חופפת
הרצה בו-זמנית של לקוח הספק וחיבור NetworkManager לאותו שירות היא הדרך הנפוצה ביותר שבה ההשוואות האלה משתבשות. שניהם מתקינים נתיבים, שניהם עשויים לקבוע DNS, ושניהם עשויים לגעת במצב חומת האש. מה שאתם מודדים אז הוא סידור שלישי שלא מתאים להתנהגות המתועדת של אף אחד משני הלקוחות.
nmcli -f NAME,UUID,TYPE connection show
nmcli connection show work --show-secrets | grep -E "^vpn\."
journalctl -u NetworkManager -b --since "10 min ago"הפקודה הראשונה אומרת אם הפרופיל הוא בכלל מסוג VPN. השנייה מציגה את סוג השירות של התוסף ואילו סודות נשמרו, וזה חשוב כשמצפים למפתח מסוכן ולא מהקובץ. היומן הוא המקום שבו תוסף שנטען אך לא הצליח לנהל משא ומתן יגיד זאת. אם אף אחד מהשלושה לא מראה בעיה, הפער נמצא בשכבות המדיניות מעל המנהור ולא בחיבור.
נתקו את הלקוח הישן לפני הפעלת החיבור החדש, שמרו על נקודות קצה וחשבון זהים, ורשמו איזה רכיב שולט בנתיבים, בהגדרות הפותר ובחסימה. הפתק הזה הוא מה שמונע מהעדכון הבא להסתיים עם שני בעלים.