הפעילו משימות שלאחר VPN מהדיספצ'ר, לא מ-if-up

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

עבור VPN שמנוהל בידי NetworkManager, הדיספצ'ר הוא המקום הנכון, ו-vpn-up היא הפעולה הנכונה.

השתמשו ב-vpn-up, לא באירוע של הממשק

הדיספצ'ר מבחין בין up ל-vpn-up. הראשון מדווח על ממשק שהופעל; השני מדווח על חיבור VPN שהופעל. עליית Wi-Fi רק אומרת שהקישור הבסיסי קיים; המנהרה עשויה עדיין לנהל משא ומתן, או שלעולם לא תאומת.

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

הגבילו את ההתאמה לחיבור אחד

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

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

דעו מה ההפעלה לא מוכיחה

vpn-pre-up רץ לפני ש-NetworkManager מדווח שה-VPN הופעל במלואו, והמנהל ממתין לתסריטים האלה. השתמשו בשלב חוסם רק כשהמשימה באמת שייכת לשם, כי בדיקה איטית מעכבת את ההפעלה שכל רכיב אחר ממתין לראות.

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

כבדו את ההקשר שבו התסריט רץ

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

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

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

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

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