VPN במארח או לקוח בתוך Genymotion: החליטו מי מחזיק במנהרה

VPN שולחני משפיע על Genymotion בשני מקומות, ותיקון האחד לא מוכיח דבר על השני. הראשון הוא החיבור שבו משתמשת אפליקציית השולחן כדי לשלוט בהתקן הווירטואלי; השני הוא הנתיב של אפליקציית Android הווירטואלית אל שירות פרטי. החליטו איזה משניהם אתם באמת משנים לפני שאתם נוגעים במתאם, ואז תעדו את גרסת Genymotion Desktop, את מערכת ההפעלה של המארח ואת ההיפרביזור, כי הנחיות שנכתבו למתאם רק-מארח של VirtualBox אינן עוברות להתקן QEMU או להפעלה מתארחת בענן.

שני נתיבים במכונה אחת

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

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

שמרו על חיבור הבקרה חי

הערת התמיכה של Genymotion Desktop עצמה מתעדת מקרה VirtualBox: ברגע ש-VPN במארח עולה, Desktop כבר לא רואה את ההתקן הווירטואלי, והחריגה החשובה היא מתאם הרק-מארח האמיתי הרשום במנהל הרשת של VirtualBox. פרטו את המתאמים האלה במקום לנחש טווח:

VBoxManage list hostonlyifs

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

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

אפשרות א: תנו למארח לשאת את התעבורה

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

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

אפשרות ב: הריצו לקוח נתמך בתוך Android

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

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

אמתו מהאפליקציה ותעדו את הסדר

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

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