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

מה שמבלבל הוא שסמל המטוס לא אומר לכם אם Wi-Fi זמין, ו-Connecting לא אומר אם הלקוח מאמת או רק ממתין. הפרידו בין שתי הקריאות האלה והאבחון ייקח דקה.

סמל המטוס אינו דוח רדיו

במכשירי Android נתמכים, Wi-Fi ו-Bluetooth יכולים להישאר פעילים במצב טיסה, והמכשיר זוכר את הבחירה שעשיתם בפעם הקודמת. המדריך של Google למצב טיסה ב-Pixel מתאר בדיוק את ההתנהגות הזו. כלומר הסמל יכול לומר שהסלולרי כבוי ושום דבר אחר.

בדקו את המצב בפועל ולא את הגליף. adb shell settings get global airplane_mode_on מחזיר 0 או 1 עבור המצב עצמו, ו-adb shell dumpsys connectivity מפרט את הרשתות שיש למכשיר כרגע, עם מצב האימות שלהן. שתי הפלטים האלה יחד עונים על השאלה שהסמל לא יכול.

אם Wi-Fi כבוי, או דלוק אך לא משויך לשום דבר, אין נתיב לנקודת הקצה של ה-VPN וכמות כלשהי של התחברויות מחדש לא תיצור אחד. זה המקרה שכדאי לשלול ראשון, כי הוא היחיד שבו התיקון הנכון נמצא מחוץ לאפליקציית ה-VPN.

מה Connecting באמת אומר

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

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

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

ארבעה מצבים שכדאי להבחין ביניהם

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

StateWhat you will seeWhat to do
Airplane mode, Wi-Fi offNo networks in dumpsys, VPN retries foreverTurn Wi-Fi on, or accept that the tunnel cannot exist
Wi-Fi on, not associatedInterface exists, no default networkJoin the access point
Associated, not validatedNetwork listed, captive-portal flag setComplete the portal sign-in, then reconnect
Validated, tunnel downInternet works, VPN fails or blocksDebug the tunnel, not the radio

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

למה חסימה גורמת לזה להיראות גרוע יותר

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

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

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

סדר אבחון שמסיים את הניחושים

עבדו מלמטה למעלה. אשרו את המצב, אשרו שקיימת רשת, שהיא אומתה, שהיא יכולה להגיע למשהו מחוץ לתת-הרשת המקומית, ורק אז הסתכלו בלקוח. adb shell ping -c 3 1.1.1.1 הוא מבחן גס אבל הוא מפריד בין נתיב חסר לנתיב שקיים בזמן שהמנהרה לא מרוצה.

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

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

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