סדר הרשומות ב-resolvconf של Debian: שימו את רשומת ה-VPN ראשונה

שרת השמות של ה-VPN ממשיך ליפול מתחת לזה של ה-LAN, ועריכת /etc/resolv.conf מתקנת זאת לכמה דקות. הקובץ הזה נוצר מחדש, ולכן התיקון לא שורד לעולם. ב-resolvconf של Debian קלט הסדר הוא /etc/resolvconf/interface-order, והוא ממיין שמות רשומות ולא כתובות DNS. ודאו איזו ערימת resolver באמת שולטת לפני שאתם נוגעים באחד משני הקבצים.

ודאו ש-resolvconf הוא הבעלים של הפלט

התחילו בשאלה מה כתב את הקובץ הנוכחי ומה יכתוב אותו שוב. חבילת resolvconf מתארת את עצמה כמסגרת לתצורת resolver דינמית, ומארח שמריץ systemd-resolved או resolver המנוהל בידי NetworkManager יכול להיראות זהה מבחוץ ובכל זאת להשתמש במדיניות שונה לחלוטין.

readlink -f /etc/resolv.conf
dpkg -l resolvconf 2>/dev/null | tail -n 1

אם הנתיב שנפתר אינו מוביל לספריית הריצה של resolvconf, עצרו כאן: ספר הפעולות הזה שייך לערימה אחרת.

רק אחרי הבדיקה הזו כדאי לרשום את הרשומות ש-resolvconf מחזיק כעת.

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

interface-order מתאים לשמות רשומות של ספקים, לא לכתובות ולא לשמות ממשקי ליבה. רשמו מה רשום כדי שהתבניות שלכם יתייחסו לרשומות קיימות.

ls /run/resolvconf/interfaces
cat /etc/resolvconf/interface-order

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

כתבו את הסדר כתבניות התאמה ראשונה

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

# /etc/resolvconf/interface-order
lo*
tun_work.*
enp*
*

שימו את תבנית המנהרה הספציפית מעל התבנית שתופסת הכול ומעל תבנית הממשק הפיזי.

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

צרו מחדש ואמתו את התוצאה

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

resolvconf -u
cat /etc/resolv.conf

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

הוציאו את הרשומה המיושנת מכלל שימוש במקום להוריד את דרגתה

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

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

רשמו את שם הספק, את התבנית ששיניתם ואת שתי השאילתות שהרצתם. האדם הבא זקוק לשמות האלה יותר מאשר לסיפור.