VPN פועל וה-VM לא נגיש? הנתיב כנראה מעולם לא היה הבעיה

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

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

הנתיב בדרך כלל נשאר מקומי

שאלו את הקרנל ולא את העמוד הראשון של טבלת הניתוב. בלינוקס, ip route get 192.168.56.10 מדווח את הנתיב, הממשק וכתובת המקור המדויקים שבהם ייעשה שימוש, וזו תשובה שונה מקריאת נתיב ברירת מחדל וניחוש. אם הפלט מציין את ממשק ה-host-only, המנהרה אינה מעורבת בנתיב הזה כלל.

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

בחירת נתיב וקבלת מנות הן החלטות שונות

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

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

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

לאורח יש שלוש דרכים לומר לא

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

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

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

מהו גשר באמת, ומה הוא עולה

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

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

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

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