DNS ציבורי שעובד לא אומר שאפשר למצוא את Active Directory

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

המיתוס: שמות נפתרים, אז ה-DNS גמור

אתר ציבורי שנפתר אומר רק שמאפיין כלשהו ענה לשאילתת A או AAAA אחת עבור שם באזור ציבורי. Active Directory משתמש באותו פרוטוקול לשאלה אחרת: היכן שירותי התחום, ואיזה בקר אמור הלקוח הזה להשתמש בו. השאלה מובעת כרשומות SRV תחת אזור שנקרא על שם התחום, ולמאפיין ציבורי רקורסיבי אין סיבה להחזיק אותן.

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

מה לקוח תחום באמת מבקש, לפי הסדר

עבור תחום כמו corp.example, שאילתת האיתור הכללית היא _ldap._tcp.dc._msdcs.corp.example. תשובות SRV מכנות בקרים מועמדים ואת הפורטים שלהם, ואחר כך הלקוח זקוק לרשומות כתובת עבור שמות המארח האלה לפני שיוכל לפתוח חיבור. גילוי מודע לאתר מוסיף שאילתות תחת תת-האזור של האתר, והתשובות קובעות אילו בקרים מועדפים ולא איזה מהם חובה.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

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

למה מאפיין ציבורי עונה ובכל זאת שובר את הכניסה

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

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

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

שמרו על התאמה בין ה-DNS של המנהרה למסלולים שלה

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

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

קבלו בקריאת גילוי ובפעולה חיה אחת

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

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

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