אמולטור אנדרואיד ו-VPN במארח: תצלום DNS והסבר NAT

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

האורח הוא מחסנית נפרדת מאחורי NAT קבוע

רשת QEMU במצב משתמש מציבה את האורח בכתובת 10.0.2.15, את השער ב-10.0.2.2 ואת שירות ה-DNS ב-10.0.2.3 עד 10.0.2.6. ליבת המארח אינה מעבירה את התעבורה היוצאת של האורח; היא מתורגמת לשקעים בצד המארח, אחד לכל חיבור של האורח, והשקעים האלה יוצאים ממרחב הכתובות של המארח. לכן חיבור של האורח יורש את החלטת הניתוב של המארח ברגע יצירתו, ולכן לאורח אין רשומה בטבלת הניתוב שמזכירה את המנהרה שלכם.

אותו מנגנון נותן לאורח מוצא שימושי. 10.0.2.2 הוא כינוי של ממשק הלולאה במארח, ולכן שירות שמאזין ב-127.0.0.1 במחשב הנייד נגיש מהאורח בכתובת הזאת. כל מה שהלקוח חושף רק בלולאה נגיש בדרך הזאת, וזה הבסיס לסידור ה-proxy שמתואר בהמשך.

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

DNS הוא תצלום, לא תצוגה חיה

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

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

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

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

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

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

הניתוב הולך אחרי המארח בזמן החיבור

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

האימות שייך לממשק המארח, לא לסטטיסטיקה של האורח:

sudo tcpdump -ni tun0 'host 203.0.113.10'

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

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

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

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

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

הוכיחו את התוצאה מתוך האורח

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

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