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

הדגל שאתה מנקה אינו נבדק

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

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

עדיפות חיבור אוטומטי מדרגת מועמדים; גם היא אינה מתג כיבוי.

קרא את שני הפרופילים לפני העריכה

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

nmcli -f NAME,UUID,TYPE connection show
nmcli -f connection.secondaries connection show "Wired connection 1"
nmcli -f connection.autoconnect,connection.autoconnect-priority connection show "Work VPN"

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

הסר רשומה אחת, לא את כל הרשימה

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

nmcli connection modify uuid BASE_UUID -connection.secondaries VPN_UUID
nmcli -f connection.secondaries connection show "Wired connection 1"

בדוק את הרשימה לפני ואחרי, במיוחד במכונה שתלויה ב-VPN שני.

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

בדוק מעבר אמיתי, לא הפעלה מחדש ידנית

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

nmcli connection show --active
ip -brief address
ip route get 10.8.0.1

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

השאר את המסלול הידני עובד, כי זו הדרישה האמיתית.

איך נראית תוצאה טובה

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

כתוב את ה-UUID של חיבור הבסיס ב-runbook, כי זה הפרופיל שתערוך בפעם הבאה.

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

מאמרים קשורים