מיפוי אתר AD לעומת נעיצת בקר תחום עבור לקוחות VPN

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

מה כל גישה באמת משנה

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

New-ADReplicationSubnet -Name "10.90.0.0/24" -Site "Remote-Access-Hub" -WhatIf
Get-ADReplicationSubnet -Filter * | Select-Object Name,Site

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

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

איפה מיפוי תת-רשת מנצח

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

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

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

איפה נעיצה מנצחת

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

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

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

בחרו לפי שלושה תנאים

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

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

אמתו מלקוח ה-VPN והפרידו בין החוזים

בדקו מהנתיב המרוחק האמיתי, לא מתחנת עבודה ב-LAN שכבר יושבת באתר. רק התצוגה של הלקוח עצמו קובעת:

nltest /dsgetsite
nltest /dsgetdc:corp.example.com /force
echo %LOGONSERVER%

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

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