שני VPN במחשב Linux אחד: לבדוק כל אחד בנפרד בלי לערבב תוצאות
שני סמלים ירוקים אינם השוואה. שימו כל מנהרה במרחב השמות שלה, כתבו את הציפייה קודם, והוכיחו את המסלול לפני שאתם סומכים על התוצאה.
שני סמלי חיבור ירוקים נראים כמו השוואה והם בדרך כלל מקרה. אם בקשת הבדיקה יכלה להשתמש בכל אחת משתי המנהרות, התוצאה מתארת במקרה הטוב אחת מהן ובמקרה הגרוע אף אחת. תנו לכל תצפית הקשר רשת, יעד מיועד וציפייה שנכתבה לפני שהבדיקה רצה. במחשב Linux שאתם מנהלים בעצמכם, מרחבי שמות רשת בעלי שם הם הדרך הזולה ביותר לקנות את ההפרדה הזו.
שני אורות ירוקים אינם השוואה
מרחב שמות מפריד טבלאות ניתוב, ממשקים ומצב מחסנית הרשת, כך שבקשה שהתחילה בתוך אחד מהם לא יכולה ללוות בשקט את המנהרה של אחר. מה שהוא לא מפריד הוא מעבד, קישור פיזי למעלה או תהליך פתרון השמות שרץ במארח. בדיוק ברווח האחרון הזה רוב הבדיקות האלה נכשלות בלי שמישהו ישים לב. חיפוש שיוצא ממרחב השמות ושואל את פותר המארח מחזיר תשובה שאין לה שום קשר למנהרה הנבדקת.
הנוהל הזה מניח שני מרחבי שמות בדיקה שכבר הוכנו ואושרו, עם קישוריות חיצונית עובדת ולקוחות נתמכים. הוא לא יוצר דבר, לא רושם דבר ולא מחליף שום תצורה. מכונות וירטואליות נפרדות נשארות הבחירה הכנה כאשר לקוח זקוק להפעלת שולחן עבודה מלאה או מסרב לרוץ מחוצה לה.
לקבוע את הציפייה לפני הריצה הראשונה
החליטו לכל הקשר איך נראית הצלחה: פותר השמות, שם השירות, הכתובת הצפויה וההתנהגות הנדרשת כשהמנהרה נופלת. שמרו את הערכים המתוכננים בעמודה משלהם, כי רשומה שמערבבת תכנון ותצפית היא בדיה עם חותמת זמן. רשימת הבדיקה שלמטה היא הצורה שהרשומה צריכה, וכל שורה חייבת להיות ניתנת למילוי לפני החיבור הראשון.
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
החיווט של פותר השמות זקוק לשורה משלו ברשומה הזו, כי זה השדה שהכי סביר שישקר. קבצים שמשויכים למרחב השמות, כמו /etc/netns/vpn-a/resolv.conf מופיעים בנתיבים הרגילים שלהם כשפקודה רצה בתוך מרחב השמות, ראו את מדריך iproute2 למרחבי שמות, אבל תצורת החלפת שירות השמות וכל פותר מקומי שהיא מפעילה עדיין יכולים למשוך חיפוש חזרה אל המארח.
מנהרה אחת בכל פעם, השנייה מנותקת
חברו את A דרך הבעלים הקיים שלו כשהמנהרה B נשארת למטה, ואז בדקו את המדיניות, המסלולים והנתיב הנבחר מהקשר הניהול. שלוש מהפקודות שלמטה קוראות מצב; רק האחרונה פונה לשירות שמות, ואף אחת מהן לא שולחת בקשת יישום.
sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internalחיפוש מסלול עונה על שאלה היפותטית לגבי יעד, ולכן אינו יכול להראות שהשירות מקבל תעבורה. שמרו את שני סוגי הראיות בעמודות נפרדות, כי מסלול תקין לצד חיבור שנדחה הוא תוצאה אמיתית ונפוצה. אחר כך שלחו בקשה מורשית אחת בלתי מזיקה עם היישום האמיתי, כשהיא מופעלת בהקשר של A כמשתמש הרגיל שלו בלי הרשאות, עם אימות תעודות ואימות יישום שלמים, ותעדו את התוצאה יחד עם כתובת המקור שהשירות ראה. נתקו את A דרך הבעלים שלו וחזרו על קו הבסיס כולו עבור B, תוך ציון כל שינוי תצורה שתעשו, אחרת שני קווי הבסיס מפסיקים להיות בני השוואה.
שתיהן למעלה, ואז אחת למטה בכל פעם
מצב יציב הוא החלק הקל. כששתי המנהרות מחוברות, חזרו על החיפוש ועל בקשת היישום של כל הקשר, ואז שברו מנהרה אחת ובדקו את האחרת. התחברו מחדש בסדר ההפוך כאשר סדר החיבור עצמו הוא השאלה.
sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20הלכידה מכריעה ויכוחים שתוצאת יישום לא יכולה: היא מראה אם הבקשה יצאה דרך הממשק שציפיתם לו או דרך משהו אחר לגמרי. לכל מעבר תעדו את פעולת הבעלים, חותמת הזמן, תוצאת המסלול, תוצאת השם ותוצאת היישום. אחר כך בדקו את דרישת הסגירה הבטוחה בתוך מרחב השמות שנפגע, כי בידוד אינו מתג השבתה. מרחב שמות מחזיק שתי מנהרות בנפרד; הוא לא מונע מאף אחת מהן לשאת תעבורה כשהפרופיל שלה אומר שהתעבורה חייבת לעצור.
מה הרשומה הזו יכולה לטעון ומה לא
מעבר מוכיח את התצפיות האלה עבור הסידור הזה, במארח הזה, באותו זמן. הוא לא אומר דבר על שני לקוחות שחולקים טבלת ניתוב אחת של שולחן עבודה, ולא על תפוקה כששתי המנהרות נושאות עומס. אלה שאלות נפרדות עם בדיקות נפרדות, והשוואה טובה רק כמו ההקשר שמצורף לכל שורה.
שמרו את הכישלונות ברשומה לצד ההצלחות, מסומנים באיזו מנהרה הייתה למעלה באותו זמן. דף נקי שמסתיר את המצב ברגע המדידה גרוע מדף מכוער שמראה אותו. מה שהופך את הרשומה לשימושית שוב מאוחר יותר הוא ההקשר, לא הציון.
אפשר להשוות שתי מנהרות במחשב אחד ביושר, אבל רק בתוך כמספר ההקשרים שבאמת שלטתם בהם. כל מה שמעבר לזה הוא משאלה עם סמל ירוק לצידה.