ip netns exec ו-DNS: למה שמות נכשלים בתוך מרחב השמות

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

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

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

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

עבור מרחב שמות שנוצר עם ip netns add, בדיקת הקריאה בלבד קצרה:

ip netns exec vpn cat /etc/resolv.conf

שימו לב אם התוצאה מציינת כתובת נגישה, שלוחת loopback, או קישור סמלי שמצביע למקום עם נגישות שונה.

מה עוזר ה-exec מעגן בפועל

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

פותר ה-loopback הוא המלכודת כאן: 127.0.0.53 פירושו ה-loopback של מרחב השמות עצמו, לא השלוחה של המארח. שלוחה שמאזינה רק במרחב השמות של המארח אינה הופכת לשירות בחדש.

בחרו פותר שמרחב השמות יכול להגיע אליו

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

יישומים עם פותר משלהם, כמו כזה שמשתמש ב-DNS over HTTPS, עשויים להתעלם מהקובץ לגמרי. אם לכלי יש הגדרת DNS משלו, שינוי resolv.conf לא ישפיע עליו, ומרחב השמות מעולם לא היה הבעיה.

כתבו את הקובץ במקום הנכון

צרו את הקובץ לכל מרחב שמות תחת /etc/netns/NAME/resolv.conf ותנו למפעיל להציג אותו. החזיקו אותו מינימלי: שרת אחד או שניים נגישים ותחומי החיפוש שהמשימה צריכה. אל תערכו את קובץ הפותר שנוצר של המארח כדי לתקן תצוגה שמיועדת לקבוצת תהליכים אחת, כי זה משנה כל יישום במכונה. אם המארח משתמש במנהל פותר, הגדירו את נתיב מרחב השמות דרך אותו מנהל במקום להיאבק בו.

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

בחנו מחדש את כל הנתיב

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

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