ייצוא VPN באנדרואיד: מה באמת עובר לטלפון חדש

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

הקובץ הוא החלק הקל. שני האחרים קובעים אם ההעברה תעבוד.

מה באמת מכיל פרופיל מיוצא

פתחו את הקובץ בעורך טקסט לפני שאתם סומכים עליו. פרופיל OpenVPN הוא שפת תצורה קטנה: remote, proto, data-ciphers ולעיתים בלוקים מוטבעים <ca>, <cert>, <key> או <tls-crypt> שהלקוח מוסר למחסנית ה-TLS שלו. תצורת WireGuard שטוחה יותר: [Interface] מחזיק את PrivateKey ו-Address, ואז [Peer] אחד לכל נקודת קצה הנושא את PublicKey, AllowedIPs ו-Endpoint. IKEv2 מגיע כ-.mobileconfig עם מילוני מטען במקום בלוקי מפתח.

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

היכן המפתח באמת חי באנדרואיד

אנדרואיד שומר נתוני אפליקציות תחת /data/data/<package>, קריאים רק ל-UID של אותה אפליקציה. אין דרך נתמכת להעתיק תיקייה פרטית של אפליקציה אחרת מטלפון ללא root, ו-adb backup חדל להיות תשובה כללית לאחר שאנדרואיד 12 ביטל אותו ולקוחות החלו להצהיר allowBackup="false". לכן ייצוא מלקוח אנדרואיד פירושו מה שהלקוח הזה מיישם, ולא העתקה של מערכת הקבצים.

שכבת הזהות נמצאת מתחת לאפליקציה. אם לקוח ייבא את המפתח שלכם ל-Android Keystore, החומר נוצר או נעטף שם, וייצוא מאוחר יותר יכול לשאת הפניה לכינוי Keystore במקום לבתים. מפתחות עם תמיכת חומרה בנויים כך שאפילו האפליקציה הבעלים לא יכולה לקרוא אותם, כפי ש-Keystore documentation מתאר, ולכן פרופיל שמפנה לכינוי הזה מיובא נקי באותו טלפון ונכשל בכל מקום אחר.

זה לא ייצוא שבור. זו התכונה שהתבקשה מהפלטפורמה לספק.

מה פרופיל לא יכול לשאת

השוו את האובייקטים למה שיעד יקבל:

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

ייבוא הוא פרסור ואז בקשת הסכמה

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

ואז מגיע שלב הרשאה שאף קובץ לא יכול לדלג עליו. אנדרואיד דורש שהאפליקציה תקרא ל-VpnService.prepare() ותקבל את הסכמתכם לפני שתוכל להקים מנהרה, ולכן פרופיל שיובא זה עתה עדיין מציג את דו-השיח של המערכת פעם אחת. אחר כך המנהרה נבנית במפורש דרך addAddress, addRoute, addDnsServer ו-addAllowedApplication או addDisallowedApplication לניתוב לפי אפליקציה. שום דבר מזה אינו נגזר מנקודת קצה, ולכן אותו פרופיל יכול להפיק סט מסלולים אפקטיבי שונה בשני לקוחות.

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

אמתו את המכשיר החדש לפני שמוציאים את הישן משימוש

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

בדיקה אחת מכריעה את כתובת היציאה. פתחו https://ifconfig.me בדפדפן הטלפון, ואז הריצו curl -s https://ifconfig.me ממחשב נייד באותה Wi-Fi והשוו את שתי התשובות לכתובת שהקצה לכם הספק.

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

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

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