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

למה מפורקת שורת ה-DNS

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

DNS = 10.24.8.53, lab.internal.example

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

שני שדות של Apple, שתי משימות שונות

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

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

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

למה כל שם עדיין מגיע ל-resolver של המנהרה

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

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

מה DNS מפוצל באמת היה דורש

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

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

קראו את ההגדרות המותקנות, לא את התצורה

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

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

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

מאמרים קשורים