איך להגיע לשירות פרטי דרך VPN במכונה וירטואלית

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

רשמו את שני המסלולים לפני שתשנו משהו

באורח, ipconfig /all מציג את המתאם שנושא את תעבורת ה-VPN ואת הכתובת שקיבל מה-DHCP של הרשת הווירטואלית. ב-Mac, רשמו את הממשק הווירטואלי שההיפרווויזור יצר עבור אותו קטע; ב-VMware Fusion התקן שמיועד רק למארח הוא בדרך כלל vmnet1, ו-Parallels נותן לו שם משלו. שימו לב מי מחלק שם כתובות, ואז רשמו הכול, כי תת-הרשת שמיועדת רק למארח מוקצית לעיתים קרובות מחדש כשהרשת הווירטואלית נוצרת שוב. בדקו את מצב הרשת של המכונה הווירטואלית בהיפרווויזור ולא בזיכרון שלכם ממנו. מצב משותף או מצב NAT למתאם הפונה לאינטרנט, בתוספת מצב שמיועד רק למארח למתאם הפונה ל-Mac, הם הסידור שהצעדים האלה מניחים.

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

אמתו תחילה את ה-VPN של האורח עצמו

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

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

הוסיפו את השלוחה שמיועדת רק למארח ובדקו אותה לבדה

חברו לאורח מתאם שמיועד רק למארח, תנו לו כתובת סטטית בתת-רשת שאיש אחר אינו משתמש בה, ואמתו שה-Mac יכול לבצע לו ping. בדקו עם ה-VPN מחובר ועם ניתוק שלו, כי הכתובת חייבת לשרוד את שניהם. אורח שעונה רק כל עוד המנהרה שלו למעלה סובל מבעיית ניתוב שעוד לא מצאתם.

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

העבירו פורט אחד, לא את תת-הרשת

העדיפו פורט מועבר אחד על פני העברת IP כללית. Windows מספק את netsh interface portproxy, שמעביר פורט מאזין אל מארח ופורט יעד, וזקוק לשירות IP Helper פועל.

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

אמתו, ואז רשמו את הנסיגה

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

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