מדוע MagicDNS פותר התקנים אבל לא שמות מארח של משרד

MagicDNS נותן לכל התקן ב-tailnet שם שנגזר משם המכונה שלו ומתחום ה-DNS של ה-tailnet. השם הזה נוצר על ידי Tailscale ועונים עליו לאורך נתיב הפותר של Tailscale. שם מארח משרדי כמו files.office.example שייך לאזור ש-Tailscale מעולם לא כתב, ולכן שינוי שם של התקן לא יכול ליצור אותו. שני מרחבי השמות מתקיימים זה לצד זה; פשוט יש להם בעלים שונים.

המנגנון הזה עומד מאחורי דיווח נפוץ מאוד: מארח Tailscale עונה, ושרת הקבצים עדיין מחזיר שגיאת פתרון.

שני מרחבי שמות, שני בעלים

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

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

כוונו את אזור המשרד אל הפותר שלו

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

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

הנגישות באה לפני הפתרון

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

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

הפרידו בין כשל השם לכשל השירות

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

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

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