AD sayt xəritələməsi və VPN müştəriləri üçün domen nəzarətçisinin bərkidilməsi

VPN hovuzundakı uzaq giriş müştəriləri sonda dünyanın o biri tərəfindəki domen nəzarətçisi ilə danışa bilər və bunu düzəltməyin iki yolu var: hovuzu düzgün nəzarətçiləri saxlayan saytla bağlı Active Directory alt şəbəkəsi kimi təsvir etmək, ya da müştərini və ya tətbiqi bir konkret nəzarətçiyə bərkitmək. Birincisi DC Locator-ın üzərində işləyə biləcəyi topologiya bəyanatıdır. İkincisi topologiyanı tamamilə nəzərə almayan, hər tətbiq üzrə ləğvetmədir. Onların qiyməti fərqlidir və bu gün daha sürətli olana əl atmaq, bir kataloq komandasının sonda hər ikisini saxlamasına gətirib çıxarır.

Hər yanaşma əslində nəyi dəyişir

Alt şəbəkə obyekti hansı ünvan diapazonunun hansı sayta aid olduğunu bildirən kataloq qeydidir. Active Directory modulu və mövcud saytla əməliyyat önizləmə üçün kifayət qədər kiçikdir:

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

-WhatIf kataloqa yazmanı önizləyir. Obyekti yaratmır və həmin diapazondakı müştərinin hər hansı bir şeyə çata biləcəyini yoxlamır, insanların gözlədiyi hissə də elə budur. DC Locator sayt modelini xidmət qeydlərini həll edərkən oxuyur, buna görə də dəqiq alt şəbəkə obyekti müştəriyə təklif olunanı dəyişir.

Bərkitmə başqa qatda işləyir. Tətbiq konfiqurasiyasında sabit nəzarətçi adı, tərkibində host olan LDAP sətri və ya üstünlük verilən serveri adlandıran registr dəyəri — hamısı kəşfi yoldan çıxarır. Tətbiq kimsə parametri dəyişənə qədər həmin nəzarətçi ilə danışır və nasazlıq keçidi tətbiqin özünün həyata keçirdiyi şeydir.

Alt şəbəkə xəritələməsi harada qalib gəlir

Hovuzu xəritələmək şəbəkə məkanını DC Locator istifadə edən hər müştəri üçün bir dəfə təsvir edir. Hovuz bir /24-dən üçə böyüyəndə model tətbiq inventarında deyil, iki və ya üç obyektdə dəyişir. Bütün üstünlük budur və müştəri sayı sizin nəzarətinizdə olmadıqda bu böyükdür.

Çətinlik odur ki, obyekt nəzarətçinin həqiqətən gördüyü ünvanla uyğun olmalıdır. VPN şlüzü hər müştərini mərkəz ünvanına çevirirsə, çevrilməmiş hovuzu əlavə etmək heç bir nəzarətçinin heç vaxt görmədiyi şəbəkə məkanını təsvir edir. Dizaynın müştərinin mənbə ünvanını saxlayıb-saxlamadığını əvvəlcədən qərarlaşdırın və saxlamırsa, VPN serverində konfiqurasiya etdiyiniz hovuzun əvəzinə çevrilmiş diapazonu xəritələyin.

İkinci məhdudiyyət: sayt modeli bir üstünlük və topologiya bəyanatıdır. O, nəzarətçini əlçatan etmir və istifadəçiyə heç nə vermir. Əlçatanlığı marşrutlar və firewall siyasəti təmin edir; avtorizasiyanı hesab siyasəti təmin edir.

Bərkitmə harada qalib gəlir

Kəşf işləyə bilmədikdə bərkitmə düzgün cavabdir: nəzarətçini dəyişə bilmədiyiniz adla həll edən köhnə tətbiq, yalnız bir nəzarətçi ünvanına icazə verən filtr və ya nəzarətçinin tətbiq dizaynının bir hissəsi olduğu sabit server dəsti. Belə hallarda bərkitmə qısa yol deyil, real məhdudiyyətin sənədə salınmasıdır.

Bunun qiyməti xəritələmənin əksidir. Bərkidilmiş ad hovuzu izləmir, tətbiq bilmirsə nasazlıq keçidi etmir və inventar yoxlaması olmadan nəzarətçinin adının dəyişməsindən və ya istismardan çıxarılmasından sağ çıxmır. O, topologiya problemlərini də gizlədir, çünki bərkidən hər müştəri sağlam görünür, sayt modeli isə səssizcə çürüyür.

Domenin adi ünvan qeydlərini bir üstünlük verilən serverlə əvəz etmək üçüncü variant deyil. Bu, normal kəşf dəstini gözləyən hər istehlakçını pozur və kataloqdan xəbərdar müştərinin saytı necə seçdiyini hələ də idarə etmir.

Üç şərtlə seçin

Onları bu sıra ilə soruşun və qərar adətən özü verilir. Birincisi, tətbiq ümumiyyətlə DC Locator istifadə edir, yoxsa artıq nəzarətçi ünvanı daşıyır? İkincisi, nəzarətçi hovuz ünvanını görür, yoxsa çevrilmişini? Üçüncüsü, hovuz nə qədər tez dəyişir, bərkitmənin yenilənməli olduğu yerlərin sayı ilə müqayisədə?

Kataloqdan xəbərdar tətbiqlər üstəgəl mənbəni qoruyan marşrutlaşdırma üstəgəl dəyişən hovuz: alt şəbəkəni xəritələyin. Kəşf edə bilməyən tətbiq və ya bir ünvana icazə verən filtr: onu bərkidin və səbəbini yazın. Qalan hər şey topologiyanı düzəltmək üçün haldır, daha bir ləğvetmə əlavə etmək üçün deyil.

VPN müştərisindən yoxlayın və müqavilələri ayrı saxlayın

Saytda artıq olan LAN iş stansiyasından deyil, faktiki uzaq yoldan test edin. Yalnız müştərinin öz görünüşü vacibdir:

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

Bildirilən sayt xəritələdiyiniz saytdırsa, obyekt uyğundur. Müştəri heç bir sayt bildirmirsə, təqdim etdiyi ünvan heç bir alt şəbəkə obyektinin içinə düşmür, bu da adətən çevrilmə və ya köhnəlmiş prefiks deməkdir. Sonra xəritələmənin uğursuz olduğunu düşünməzdən əvvəl seçilmiş nəzarətçinin istədiyiniz olduğunu yoxlayın, çünki müştərilər kəşf nəticələrini keşləyir və nasazlıq keçidi qanuni olaraq başqa nəzarətçi seçə bilər.

Üç müqaviləni bir sənəddə saxlayın: hovuz və onun alt şəbəkə obyektləri, VPN yolundan əlçatan nəzarətçilər və daxil olmuş istifadəçinin nə edə biləcəyini müəyyən edən siyasət. Sayt firewall qaydası deyil və təcrid sərhədi deyil, və növbəti hovuz dəyişikliyi xəritələmə, marşrutlar və sənədləşdirilmiş alternativlər birlikdə hərəkət etməsə, uzaq istifadəçiləri kataloqun şəbəkə modelindən səssizcə ayıracaq.