למה VPN האורח שלכם נכשל מאחורי NAT של VirtualBox?

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

אתרו את תהליך ה-VPN לפני שאתם מאשימים את הרשת

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

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

ההחלפה החיצונית קובעת את התאימות

מדריך הרשת של VirtualBox מפרט מגבלות NAT שרלוונטיות כאן: הוא לא יעביר פרוטוקולים מלבד TCP ו-UDP, GRE מוזכר כלא נתמך, ו-PPTP ניתן כדוגמה שנפגעת. PPTP משתמש בהחלפת בקרה ב-TCP וב-GRE לנתונים, ולכן חיבור הבקרה יכול להצליח בעוד נתיב הנתונים אינו יכול לחצות את אותו גבול. אלו שתי ראיות שונות, ורק אחת מהן עוסקת בנשיאת תעבורה. מתן אישור לפורט TCP 47 בכלל חומת אש אינו אותו דבר כמו מתן אישור לפרוטוקול IP 47, והשניים מתבלבלים כל הזמן.

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

מה גשר באמת משנה

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

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

שתי מנהרות, שני נתיבי ראיות

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

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

איזה תנאי באמת חוסם אתכם

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

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