ADB והאמולטור של Android נכשלים מאחורי VPN: שלושה מסלולים
גילוי ADB, הכרטיס הוירטואלי של האמולטור ופותר השמות של המארח נכשלים בנפרד מאחורי VPN. בדקו כל מסלול לפי הסדר לפני שמאשימים את המנהרה.
אתם מתחברים ל-VPN של המשרד ו-Android Studio מאבד את האמולטור הפעיל, adb start-server נתקע, וטלפון פיזי ב-Wi-Fi נופל מרשימת ההתקנים. נראה שמוצר אחד חסום על ידי מנהרה אחת. בפועל שלושה מסלולים נפרדים נכשלים בשלוש דרכים: גילוי התקנים של adb, הרשת הוירטואלית של האמולטור ופותר השמות של המארח. המנהרה בדרך כלל מחזיקה רק את האחרון, ולעיתים רק חלק ממנו.
שלושה שקעים, שלושה בעלים
שרת adb מאזין בפורט 5037 במארח ומדבר עם התקנים דרך USB או TCP, עם mDNS לגילוי ברשת. האמולטור רץ מאחורי נתב וירטואלי משלו: האורח הוא 10.0.2.15, השער שלו 10.0.2.2 ושרת ה-DNS שלו 10.0.2.3, ותהליך האמולטור מתרגם הכול לשקעים של המארח. פותר השמות של המארח הוא המקום שבו לקוח ה-VPN מתקין DNS ותחומי חיפוש.
ההפרדה הזו מסבירה למה תיקון נראה שעובד בכלי אחד ולא באחר. לקוח שמשנה את פותר השמות משאיר את תהליך האמולטור עם מצב הפותר שקרא בהפעלה. לקוח שמסנן multicast שובר את הגילוי בלי לגעת ב-DNS. לקוח שמסנן מתאמים וירטואליים דוחה את האמולטור בזמן שהדפדפן של המארח ממשיך לעבוד. לכל תסמין סיבה אחרת, לכן זהו את המסלול שנכשל לפני שתשנו הגדרה.
התחילו במה ש-adb רואה
הריצו adb devices לפני שנוגעים ב-VPN. רשימה ריקה היא בעיית תעבורה, לא בעיית ניתוב, ואף הגדרת מנהרה לא תתקן התקן שהשרת מעולם לא מנה. הפעילו מחדש את השרת בצורה נקייה: תחילה adb kill-server ואחר כך adb start-server, וקראו את הפלט כדי לראות איזה פורט הוא תפס. אם ההפעלה עצמה נתקעת, גילוי mDNS הוא החשוד הרגיל ברשת שמסננת multicast; הפתרון המתועד הוא להפעיל את השרת עם גילוי כבוי:
ADB_MDNS_OPENSCREEN=0 adb start-server
adb devicesלהתקן פיזי USB הוא המסלול הקצר. אם צריך TCP, העבירו את ההתקן למצב האזנה עם adb tcpip 5555 והתחברו לכתובת ולפורט של ההתקן, adb connect 192.0.2.10:5555. פורט 5037 הוא פורט השרת במארח, לא הפורט שההתקן מאזין עליו.
בדקו את האמולטור מבפנים
האמולטור עונה ל-DNS מ-10.0.2.3, והפותר הזה ניזון מתהליך המארח. כשלקוח ה-VPN משנה את פותר המארח האמולטור יכול לרשת אותו; כשלקוח מסנן את תהליך האמולטור או שרשימת המתאמים משתנה אחרי ההפעלה, הוא לא יכול. הפרידו בין השניים ביעד מספרי ובשם מאותו shell. adb shell ping -c 2 10.0.2.2 מוכיח שהרשת הוירטואלית מגיעה לצד המארח. חיפוש שם אחר כך מראה אם הפתרון חצה את הגבול.
אחר כך הריצו את אותו חיפוש שם במארח. המארח פותר והאמולטור לא משמע שהשבר בין פותר השמות של המארח לרשת הוירטואלית של האמולטור, לא במנהרה. שניהם נכשלים משמע שפותר השמות של המארח הוא המקום לבדוק. הפעלה מחדש של האמולטור אחרי חיבור VPN שווה ניסיון אחד, כי חלק מהלקוחות מתקינים מצב פותר שתהליך אמולטור פעיל לא קולט.
בדקו את פותר השמות של המארח ואת מסנני הלקוח
לקוח מנהרה מלאה מחליף את פותר השמות של המארח בשלו, ולקוח split-DNS מוסיף תחומי חיפוש ומעבירים מותנים. שמות פנימיים תלויים לעיתים קרובות באותה תצורת split-DNS, לכן בדקו מה המארח משתמש בו בזמן חיבור: כתובת הפותר, תחום החיפוש והאם האזור הפנימי מנותב ל-DNS הארגוני. פותר שעונה לשמות ציבוריים אבל לא לפנימיים הוא שאלת מדיניות, לא מנהרה שבורה.
חלק מלקוחות הארגון חוסמים גם תעבורה ממתאמים וירטואליים. עבור דרייבר סינון האמולטור נראה כמו מתאם וירטואלי, כך שהמארח יכול לעבוד היטב בזמן שהמדיניות דוחה את האמולטור. המדיניות הזו אינה נראית מתחנת העבודה, וניחוש הגדרות פרוקסי לא יחשוף אותה. אם המארח פותר והאמולטור חסום ללא תלות בהגדרות הפותר, ההסלמה הנכונה היא לצוות שמחזיק במדיניות הלקוח.
סדר הבדיקות ומה כל תוצאה אומרת
עבדו מלמעלה למטה ועצרו בשורה הראשונה שנכשלת. כל תוצאה מצביעה על בעלים אחר, ואף אחת מהן לא נפתרת בהתקנה מחדש של Android Studio.
| Result | Likely owner | Next check |
|---|---|---|
| adb devices is empty with USB attached | USB, driver or adb server | cable, authorization prompt, adb kill-server |
| adb start-server hangs | mDNS discovery | ADB_MDNS_OPENSCREEN=0 |
| Emulator reaches 10.0.2.2, names fail | Host resolver to emulator boundary | host lookup of the same name |
| Host resolves, emulator still fails | Emulator process or client filter | restart emulator, ask IT about virtual adapters |
| Both fail for internal names only | Split DNS or search domain | resolver and zone configuration |
רק שתי השורות האחרונות הן שאלות VPN במובן הרגיל, ורק האחרונה עוסקת בתוכן DNS. תיעוד adb מכסה את פורט השרת ואת משתני הסביבה המוזכרים כאן, מספיק כדי לשמור על צד התעבורה כן בזמן שאתם בודקים את השאר.