האם ה-VM שלכם משתמש ב-VPN של המארח? בדקו מתוך האורח
כתובת היציאה של המארח לא אומרת דבר על המסלולים של האורח. רשמו את מצב הרשת, בדקו את המסלול והפותר של האורח, ואז בדקו את מקרה הכשל.
אתם בודקים את כתובת ה-IP הציבורית של המארח, היא מציגה את ה-VPN, ואתם מסיקים שה-VM מכוסה. המסקנה הזו אינה נתמכת על ידי הבדיקה. לאורח יש טבלת ניתוב משלו, פותר משלו וממשקים משלו, וכתובת היציאה של המארח לא אומרת דבר עליהם.
הבדיקה חייבת לרוץ בתוך האורח, והיא חייבת לנקוב במה שהיא מדדה.
התחילו בתוך האורח, לא בדפדפן של המארח
רשמו קודם את מצב הרשת של ההיפרביזור: NAT, bridged, host-only או macvtap. במצב NAT המארח מנתב את התעבורה של האורח, ולכן המנהרה של המארח עשויה לחול או לא, בהתאם לאופן שבו הלקוח מתקין מסלולים. במצב bridged האורח הוא עמית ברשת ה-LAN הפיזית והמנהרה של המארח אינה רלוונטית. שני המצבים האלה נותנים תשובות הפוכות מאותו תצורת מארח.
כתבו את המצב לפני שאתם משנים משהו, כי הוא קובע מה התוצאה יכולה לומר.
שלחו בקשה אחת שאתם יודעים את היעד שלה
השתמשו בבקשה לא מזיקה לשירות שמדווח על כתובת המקור שהוא ראה. לאחר מכן בדקו את החלטת הניתוב של האורח עצמו עבור היעד הזה: ip route get 203.0.113.5 מדפיס את הממשק ואת שער היציאה שהאורח ישתמש בהם.
אם הממשק הוא כרטיס הרשת הרגיל של האורח, התעבורה לא עוברת במנהרה בתוך האורח.
מתאם שני, הגדרת פרוקסי או לקוח VPN בצד האורח יכולים לשנות את התשובה עבור יישום אחד ולא עבור אחר. בדקו את היישום שבאמת חשוב לכם, לא בקשה כללית ממעטפת.
בדקו את הפותר בנפרד
כתובת יציאה שונה לא אומרת לכם איזה פותר טיפל בשם המארח. שאלו את השם במפורש בכלי שמתאים לפלטפורמה, ורשמו איזה שרת ענה. DNS מפוצל אומר שלשאלת הפותר ולשאלת הניתוב יש תשובות שונות.
שני אלה יכולים להתפצל לכל כיוון, והפיצול הוא לעתים קרובות הבאג האמיתי.
במארח עם systemd, resolvectl query נוקב בממשק ובשרת ה-DNS שמאחורי התשובה. הגדרות ישנות יותר מציגות את השרת בפלט של dig — בכל מקרה הנקודה היא לראות איזה שרת ענה, לא רק אם הגיעה תשובה.
בדקו את מדיניות הכשל, לא רק את ההצלחה
אם הדרישה היא ששום תעבורה לא יוצאת מחוץ למנהרה, בקשה מוצלחת לא מוכיחה דבר. השתמשו בבדיקת הכשל המבוקרת הנתמכת של הלקוח: עצרו את המנהרה בדרך הנתמכת וראו אם בקשה חדשה של האורח נחסמת. אל תניחו שה-kill switch של לקוח המארח מכסה כל פריסת העברה וירטואלית. ההיקף המתועד שלו הוא הדבר היחיד שאפשר לסמוך עליו.
אורח שחוזר לכרטיס הרשת הפיזי כשהמנהרה נופלת עושה בדיוק את מה שמצב NAT מתיר.
רשמו את המצב ואת ההיקף
רשמו את מצב ההיפרביזור, את הממשק והמסלול של האורח, את הפותר ואת היישום שבדקתם. הוסיפו את התאריך, כי שחזור snapshot או עדכון היפרביזור יכולים לשנות את כל הארבעה.
אם IPv4 עקב אחרי המנהרה, אמרו זאת. אל תרחיבו את הקביעה ל-IPv6, למרחב שמות אחר או ל-VM אחר ברשת אחרת.