חיבור בקר קטן ל-VPN של NetworkManager
ההפעלה מחזירה ידית, לא הפעלה מוכנה. החזק את הפרופיל, הבקשה והחיבור הפעיל בנפרד, ובנה מחדש את המצב לאחר אתחול.
תוכנית קטנה שמחברת VPN קיים זקוקה לבקר, ולא למימוש VPN חדש. המנוע הנתמך אמור לטפל במשא ומתן ובתעבורת המנהרה; התוכנית שלך אמורה להביע את בקשת המשתמש ולהסביר את התוצאה בכנות. ב-Linux ממשק ה-D-Bus של NetworkManager נותן לבקר הזה מודל קונקרטי שאפשר לפעול לפיו.
ארבע בדיקות מונעות מהבקר לבלבל בין פרופיל שמור, בקשת הפעלה והפעלה שעובדת.
בדיקה ראשונה: איזו זהות נבחרת
החזק את ה-UUID של הפרופיל כזהות מתמשכת, ופתור אותו דרך המנהל כשאתה צריך את נתיב האובייקט. שם תצוגה יכול להיות משותף לשני פרופילים, ונתיב אפיק בזמן ריצה אינו העדפת משתמש סבירה לאחסון. רשום את הבחירה בקונפיגורציה שלך, ולא בהערה על איזו רשומה הייתה השנייה ברשימה.
אמת מה המנהל מחזיר לפני שאתה קורא לזה התאמה. UUID שכבר אינו קיים מפיק כשל חיפוש, וזה נתיב קוד שונה מפרופיל שקיים ומסרב להיות מופעל.
בדיקה שנייה: מה קורא ההפעלה מחזיר
קריאת ההפעלה המתועדת מקבלת נתיב אובייקט של חיבור קיים, נתיב התקן ואובייקט מסוים. היא מחזירה נתיב של חיבור פעיל, והתשובה הזו היא ידית ולא תוצאת מוכנות. אל תקבע את דגל המוכנות של האפליקציה מערך ההחזרה; הירשם במקום זאת למצב החיבור הפעיל ולסיבתו.
ב-VPN האובייקט המסוים בוחר את חיבור הבסיס הפעיל. העברת נתיב השורש משאירה את בחירת ההתקן ל-NetworkManager, שבוחר את זה שהוא ברירת המחדל באותו רגע. זו החלטה של הקשר ניתוב ולא שדה סיסמה, והיא משנה על איזה התקן המנהרה מונחת.
אל תיקח דוגמה כללית של הוספה והפעלה ותצפה שהיא תיצור פרופיל VPN. העוזר המתועד מוציא חיבורי VPN, ולכן אספקת הפרופיל או ייבואו הם שלב נפרד ומבוקר. זה חשוב כי אספקה דורשת הרשאה וסקירה שכפתור חיבור אינו נותן. התייחס לייבוא כפעולה מנהלית עם שורת יומן משל עצמה ומאשר משלה.
בדיקה שלישית: כיצד המצב מיוצג
חיבור פעיל עובר דרך הפעלה, פעיל, השבתה ומושבת, ושדה הסיבה אומר למה. דחיסת כל זה לערך בוליאני בשם loggedIn מאבדת את המידע שהמשתמש צריך ואת זה שהתמיכה תבקש. הצג לפחות אם החיבור ממתין, מבוסס או נעלם, ושמור את מחרוזת הסיבה למקרה הכשל.
קשר תשובות אסינכרוניות לבקשה שהפיקה אותן. השלמה מאוחרת של ניסיון קודם לא תדרוס פעולת משתמש חדשה יותר, ולחיצה כפולה על Connect צריכה להיות מותעלמת או להיחשב כביטול וניסיון חוזר עם מדיניות גלויה.
בדיקה רביעית: מה קורה לאחר אתחול
כשהמנהל מתאתחל או כשהבקר שלך מתחבר מחדש לאפיק, בנה מחדש את המצב הנצפה מהבעלים. אל תמשיך להציג הפעלה שמורה במטמון כפעילה מפני שנתיב אובייקט ישן עדיין בזיכרון. אותות שינוי המצב קיימים בדיוק כדי שבקר יוכל לסנכרן מחדש במקום לנחש.
בחר מה משמעות סגירת הבקר. השארת חיבור קיים בבעלות המכונה פתוח יכולה להיות נכונה, ופירוק הפעלה קצרת מועד במכוון יכול גם הוא להיות נכון. השארת חיבור קיים בבעלות המכונה פתוח יכולה להיות נכונה; פירוק הפעלה קצרת מועד במכוון יכול גם הוא להיות נכון. כתוב את חוזה הבעלות הזה בממשק במקום להניח שיציאת התהליך מבצעת את פעולת הרשת. משתמשים לא אמורים לנחש אם סגירת החלון תפיל את המנהרה שלהם. שים את התשובה בטקסט הממשק, ולא רק בהערת קוד.
החזק סמכות וסודות אצל הבעלים שלהם
הרשאות חוזרות כ-כן, auth או לא, והממשק צריך לשקף את ההבדל בין מותר, מותר לאחר אימות ואסור. הרצת הבקר כ-root אינה מיישמת מדיניות הרשאות; היא מסירה את השאלה.
פרטי גישה שייכים לסוכן הסודות הנתמך או לשילוב הלקוח עבור שיטת האימות המוגדרת. סיסמה בקוד מקור, בארגומנט או ביומן היא ממצא, והרשאה מנהלית מקומית אינה אותו אירוע כמו אימות מול השער.
לבסוף, דווח על מצב החיבור בנפרד מהמשימה שהמשתמש רוצה לבצע. מנהרה יכולה להיות פעילה בעוד שם פרטי או יישום נשארים לא זמינים, והכשל השני הזה ראוי להודעה משלו ולסטטוס משלו. בקר שאומר בדיוק איזו שכבה נכשלה שימושי יותר מזה שאומר שה-VPN למטה.