ה־VPN נופל כשהמסך נכבה: איזה מחזור חיים?

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

שלוש תקלות שנראות זהות

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

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

השוו מצב פעיל ובטל תחת בקרה

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

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

קראו את מדיניות הרקע של הפלטפורמה

באנדרואיד מחזור החיים של שירות ה־VPN הוא חלק מהפלטפורמה, ו־always-on ו־block-without-VPN הם מתגים נפרדים עם השפעות נפרדות. לקוח שאינו always-on יכול להיעצר כשהמערכת מחזירה משאבים, ושום הגדרה באפליקציה לא משנה זאת. iOS מחיל מגבלות רקע משלו על ספק המנהרה, וההתנהגות המתועדת שונה מדמון שולחני שפשוט ממשיך לרוץ. קראו את תיעוד הפלטפורמה עבור הרכיב המדובר, ולא מדריך כללי לאופטימיזציית סוללה.

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

מה המכשיר עושה לאחר היקיצה

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

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