מרחבי שמות רשת של Linux ל-VPN: מה הם לא מבודדים

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

מה מרחב השם מחזיק, ואיפה הסוקט נולד

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

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

מה מרחב שם לא מבודד

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

הפתרון הוא קובץ לכל מרחב שם ב-/etc/netns/<name>/resolv.conf, או bind mount של קובץ מוכן, שמצביע על פותר נגיש מבפנים. עריכת /etc/resolv.conf במארח לא משנה דבר ממה שמרחב השם רואה.

מיקום התהליכים הוא הבקרה

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

ip netns add vpn1
ip link set wg0 netns vpn1
ip netns exec vpn1 wg show
wg show

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

בדקו מתוך ההקשר של האפליקציה

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

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

העברה, מדיניות כשל וניקוי

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

רשמו את שמות מרחבי השם, את הממשקים ואת מי שמחזיק בתצורה, כדי שהניקוי יסיר רק את מה שהפריסה יצרה. איפוס הרשת של המארח במהלך החזרה הופך ניקוי להפסקה. דף network_namespaces(7) קצר וכדאי לקרוא אותו לפני שתעצבו את המסלול הזה.