למה Windows שולח את שמות ה-VPN שלכם לשרת DNS שמעולם לא הגדרתם

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

מה שיניתם, ומה באמת מחליט

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

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

איך הטבלה מתאימה שם

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

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

קראו את הטבלה האפקטיבית, לא את רשימת המשאלות

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

השוו את הסיומת בפלט הזה לשם שאתם בודקים, תו אחר תו. כלל עבור corp.example לא תופס שם שמסתיים ב-corp.example.com, ונקודה בסוף במקום אחד ולא במקום אחר מספיקה כדי לשנות את ההתאמה.

בלי כלל, Windows שואל יותר ממתאם אחד

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

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

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

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

בדקו גם אם האפליקציה מתחברת לכתובת שמורה מהפעלה קודמת. Clear-DnsClientCache ואחר כך אותה חיפוש נותנים תשובה נקייה יותר מלהסיק מתוצאה מיושנת.

בדקו עם השם שנכשל

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

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