VPN תמיד פעיל באנדרואיד: איך שם נקודת הקצה נפתר ראשון

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

מה בונה ה-VPN באמת מבקש

אפליקציית VPN לאנדרואיד לא מוסרת לפלטפורמה כתובת שרת. היא בונה ממשק מקומי: כתובות ומסלולים למנהרה, הפותרים שהאפליקציות אמורות להשתמש בהם בפנים, ואז establish() מחזיר מתאר קובץ שהאפליקציה קוראת וכותבת כחבילות IP גולמיות. נקודת הקצה המרוחקת לא מופיעה בבונה הזה בכלל.

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

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

שתי שאלות DNS, לא אחת

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

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

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

למה האתחול יכול להיתקע

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

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

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

למה הצמדת התשובה אינה תיקון

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

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

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

תכנונים ששורדים הפעלה מחדש

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

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

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

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