איך לקרוא את ניתוב ה-DNS של ה-VPN לכל קישור מפלט resolvectl

הריצו resolvectl status ותקבלו קיר של בלוקים לכל קישור, כל אחד עם השרתים שלו ועם שורת הדומיינים שלו. השורה שקובעת את הניתוב היא רשימת הדומיינים, לא כתובת שרת השמות, מפני שה-stub המקומי מעביר כל שאילתה לקישור שתובע את השם. קראו את התביעות האלה לפני קריאת התשובה, ואז שאלו את השם ובדקו איזה קישור יצר אותו. תשובה שגויה מהקישור הנכון היא בעיה אחרת מתשובה נכונה מהקישור השגוי.

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

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

כתובת stub כמו 127.0.0.53 בקובץ /etc/resolv.conf אומרת רק שה-stub נמצא מלפנים. היא אינה נוקבת בשם המקור שענה, ולכן אבחון המבוסס על resolv.conf בלבד נתקע.

קראו נכון את שלושת סוגי רשומות הדומיין

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

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

שאלו שם וראו איזה קישור ענה

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

resolvectl status
resolvectl query host.corp.example

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

הפרידו בין ניתוב שמות לניתוב חבילות

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

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

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

בדקו שוב אחרי שהקישור משתנה

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

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