הדומיין של ה-VPN שלך ב-dnsmasq אינו העברת אזור

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

מה שהלקוח קיבל אינו מה שהשער הציע

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

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

שני סוגים של רשומת דומיין

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

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

localhost ב-resolv.conf אינו באג

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

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

אל תבלבל בין ה-backends

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

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

בדוק את מרחב השמות, לא רק את התשובה

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

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