מצב NEVPNManager אינו תקף עד שההעדפות נטענות
קריאת מצב או שמירה לפני ש-loadFromPreferences מסתיים מחזירה תוצאות מיושנות או כושלות. סדר הטעינה, הפניות למחזיק המפתחות וקבוצות הגישה קובעים זאת.
הפעילו מחדש את האפליקציה, שאלו את המנהל על מצב החיבור, והוא מדווח על מנותק בזמן שתפריט המערכת מציג בבירור מנהרה פעילה. או שקריאה לשמירה מחזירה שגיאה שלא מסבירה דבר, או שסוד משותף מוכרז כחסר שניות לאחר שהוקצה. שלושה תסמינים, מנגנון אחד: המנהל הוא תצוגה על מאגר מערכת, ותצוגה נקראת ריקה עד שמישהו טוען אותה.
לפני שמאתרים תקלות באחד מאלה, החליטו באיזה API אתם אמורים להשתמש. מנהרת IPsec או IKEv2 של המערכת מתאימה למנהל המובנה; פרוטוקול שהמערכת אינה מיישמת דורש ספק מנהרה עם טיפול משלכם בחבילות, ואף צירוף של שדות לא משנה זאת.
המנהל הוא תצוגה על מאגר
צרו או הביאו את המנהל, בקשו ממנו לטעון את העדפותיו, ותנו למטפל ההשלמה לסיים לפני קריאת מצב או שינוי הגדרות פרוטוקול. כשהמשימה היא למנות תצורות שמורות, השתמשו בקריאה של כל הווריאציות במקום למחזר מופע אחד לשתי מטרות. לפני שהטעינה מגיעה, המצב בדרך כלל אינו תקף, והמרת לא־תקף לכבוי היא בדיוק הבאג שגורם לאפליקציה להיראות שגויה רק לאחר הפעלה מחדש.
הכתיבה עוקבת אחר אותו סדר. ניסיון שמירה על מנהל שמעולם לא טען דבר עלול להיכשל בלי הודעה מועילה, כי אין זהות שמורה שהשינוי יחול עליה. טענו, שנו, שמרו ואז קראו את המצב שוב. האובייקט שהמערכת מתחברת אליו הוא הפרופיל השמור, לא זה שערכתם בזיכרון.
שינויי מצב מגיעים רק כשאתם מסתכלים
לאחר טעינת ההעדפות המצב עובר דרך מנותק, מתחבר, מחובר, מאשר מחדש ומנתק. אתחלו את הממשק מקריאה אחת, ואז האזינו להודעת השינוי במקום לסקר לפי טיימר. סקירה עובדת בחזית ומשקרת ברקע, וכך אפליקציות נשארות עם מחוון שמסתובב ולעולם אינו נפתר.
התראות מגיעות רק כשהאפליקציה בחזית. כל דבר שמחזיק מצב ברקע ייראה מיושן לאחר הפעלה מחדש, לכן רעננו בעת ההפעלה ושוב כשהאפליקציה חוזרת לחזית. אם ספק הוא הבעלים של המנהרה, הנהיגו אותה דרך אובייקט ההפעלה המתאים; מאפיין החיבור הפשוט אינו מדגמן את מחזור החיים של ספק.
סודות הם הפניות, לא מחרוזות
דיווח על סוד משותף חסר רק לעיתים נדירות אומר שלא הוקצה כזה. אובייקט הפרוטוקול רוצה הפניה: אחת לסיסמת המשתמש ואחת למפתח המשותף מראש של IPsec. העברת nil, או הפניה שנגזרה מהרשומה הלא נכונה במחזיק המפתחות, נותנת את אותה תלונה כמו מקום ריק. השגיאה נוקבת בתסמין ומסתירה את הסיבה, ולכן אנשים מזינים שוב ושוב את אותו סוד.
כתבו תחילה את הסוד כפריט סיסמה כללי, ואז קראו בחזרה הפניה מתמשכת אליו. הפניה מתמשכת שורדת הפעלה מחדש, שלא כמו מצביע בזיכרון, והיא הייצוג שהפרופיל ממיר לסדרה. בחרו מחלקת נגישות שמאפשרת גישה גם לאחר שהמכשיר נפתח, אחרת מנהרה שחייבת להתחבר מחדש במסך נעול תיכשל באימות עם סוד תקף לחלוטין.
להרחבה יש תצוגה משל עצמה של מחזיק המפתחות
הרחבת רשת היא תהליך נפרד, לכן גישת ברירת המחדל של האפליקציה למחזיק המפתחות אינה מגיעה אליה. תנו לשתי המטרות את אותה קבוצת גישה למחזיק המפתחות בהרשאותיהן, שמרו את הפריט פעם אחת בתוך הקבוצה הזו, ותנו לכל תהליך לקרוא אותו. בלי הקבוצה ההרחבה לא מוצאת דבר ומדווחת על כשל אישורים שהאפליקציה אינה יכולה לשחזר.
אם הספק מוגדר דרך אובייקט תצורת הספק שלו, אל תטמיעו את הסוד גם בתוך האפליקציה. שתי עותקים נודדים בנפרד, והנדידה מופיעה כאישורים גרועים ולא כשכפול. לווידג'ט או לתהליך שני שמדווח על מצב אחר יש אותו הסבר: כל אחד זקוק לקבוצה, וכל אחד חייב לטעון העדפות לפני שיקרא.
התאימו את ה-API לפרוטוקול
המנהל המובנה נושא אובייקטי פרוטוקול IPsec ו-IKEv2. הוא אינו הופך ללקוח SSL VPN כללי באמצעות שדות נוספים, ופרופיל לא מתאים יכול להישמר נקי ובכל זאת לא להתחבר לעולם. החליטו באיזו קטגוריה אתם נמצאים לפני חקירת המצב, כי באג במצב ופרוטוקול לא נתמך נראים זהים מבחוץ.
להפעלה מחדש הבאה רשימת הבדיקה קצרה: טענו העדפות, קראו מצב, החזיקו מינויים לשינויים בחזית, בנו מחדש הפניות מהקבוצה המשותפת, ואשרו שאובייקט הפרוטוקול תואם ל-API שיישמתם. מעבר על הרשימה הזו לוקח דקה; ניחוש לגביה לוקח אחר צהריים שלם.