نگاشت سایت 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، و سیاستی که تعیین می کند کاربر وارد شده چه کاری می تواند بکند. سایت یک قاعده فایروال نیست و یک مرز جداسازی نیست، و تغییر بعدی استخر کاربران راه دور را بی صدا از مدل شبکه دایرکتوری جدا می کند مگر اینکه نگاشت، مسیرها و جایگزین های مستند با هم حرکت کنند.