Mapowanie lokacji AD a przypinanie kontrolera domeny dla klientów VPN

Klienci dostępu zdalnego w puli VPN mogą w końcu rozmawiać z kontrolerem domeny na drugim końcu świata, a to da się naprawić na dwa sposoby: opisać pulę jako podsieć Active Directory powiązaną z lokacją, w której są właściwe kontrolery, albo przypiąć klienta lub aplikację do jednego konkretnego kontrolera. Pierwsze to deklaracja topologii, na której DC Locator może działać. Drugie to nadpisanie na poziomie aplikacji, które całkowicie ignoruje topologię. Kosztują różne rzeczy, a sięganie dziś po szybsze jest dokładnie tym, jak zespół katalogu kończy z utrzymywaniem obu.

Co naprawdę zmienia każde podejście

Obiekt podsieci to rekord w katalogu, który mówi, do której lokacji należy zakres adresów. Z modułem Active Directory i istniejącą lokacją operacja jest dość mała, by ją podejrzeć:

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

-WhatIf podgląda zapis w katalogu. Nie tworzy obiektu i nie sprawdza, czy klient z tego zakresu cokolwiek osiągnie, a właśnie tego ludzie oczekują. DC Locator czyta model lokacji, gdy rozwiązuje rekordy usług, więc dokładny obiekt podsieci zmienia to, co jest oferowane klientowi.

Przypinanie działa w innej warstwie. Stała nazwa kontrolera w konfiguracji aplikacji, ciąg LDAP z hostem w środku albo wartość rejestru wskazująca preferowany serwer — wszystkie usuwają odnajdywanie ze ścieżki. Aplikacja rozmawia z tym kontrolerem, dopóki ktoś nie zmieni ustawienia, a przełączenie przy awarii to to, co implementuje sama aplikacja.

Gdzie wygrywa mapowanie podsieci

Zmapowanie puli opisuje położenie sieciowe raz, dla każdego klienta, który używa DC Locator. Gdy pula rośnie z jednej /24 do trzech, model zmienia się w dwóch lub trzech obiektach zamiast w inwentarzu aplikacji. To cała zaleta i jest duża, gdy populacja klientów nie jest pod twoją kontrolą.

Haczyk polega na tym, że obiekt musi odpowiadać adresowi, który kontroler naprawdę widzi. Jeśli brama VPN tłumaczy każdego klienta na adres koncentratora, dodanie nieprzetłumaczonej puli opisuje położenie sieciowe, którego żaden kontroler nigdy nie obserwuje. Zdecyduj wcześnie, czy projekt zachowuje adres źródłowy klienta, a jeśli nie, zmapuj zakres przetłumaczony zamiast puli skonfigurowanej na serwerze VPN.

Druga granica: model lokacji to preferencja i deklaracja topologii. Nie czyni kontrolera osiągalnym i nic nie daje użytkownikowi. Osiągalność zapewniają trasy i polityka zapory; autoryzację zapewnia polityka kont.

Gdzie wygrywa przypinanie

Przypinanie jest właściwą odpowiedzią, gdy odnajdywanie nie może działać: stara aplikacja, która rozwiązuje kontroler po nazwie, której nie można zmienić, filtr dopuszczający dokładnie jeden adres kontrolera albo stały zestaw serwerów, w którym kontroler jest częścią projektu aplikacji. W tych przypadkach przypięcie jest udokumentowaniem realnego ograniczenia, a nie skrótem.

Jego koszt jest przeciwieństwem mapowania. Przypięta nazwa nie podąża za pulą, nie przełącza się przy awarii, jeśli aplikacja tego nie umie, i nie przetrwa zmiany nazwy ani wycofania kontrolera bez przeglądu inwentarza. Ukrywa też problemy topologii, bo każdy przypięty klient wygląda zdrowo, podczas gdy model lokacji po cichu gnije.

Zastąpienie zwykłych rekordów adresowych domeny jednym preferowanym serwerem nie jest trzecią opcją. Łamie każdego konsumenta, który oczekuje normalnego zestawu odnajdywania, i nadal nie kontroluje tego, jak klient świadomy katalogu wybiera lokację.

Wybieraj według trzech warunków

Zadaj je w tej kolejności, a decyzja zwykle podejmuje się sama. Po pierwsze, czy aplikacja w ogóle używa DC Locator, czy już nosi adres kontrolera? Po drugie, czy kontroler widzi adres puli, czy przetłumaczony? Po trzecie, jak często pula się zmienia w porównaniu z tym, w ilu miejscach trzeba by zaktualizować przypięcie?

Aplikacje świadome katalogu plus routing zachowujący źródło plus zmieniająca się pula: zmapuj podsieć. Aplikacja, która nie potrafi odnaleźć, albo filtr dopuszczający jeden adres: przypnij ją i zapisz dlaczego. Wszystko inne to sprawa naprawy topologii, a nie dodawania kolejnego nadpisania.

Weryfikuj z klienta VPN i trzymaj umowy osobno

Testuj z rzeczywistej ścieżki zdalnej, a nie ze stacji roboczej w sieci LAN, która już siedzi w lokacji. Liczy się tylko widok samego klienta:

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

Jeśli zgłoszona lokacja to ta, którą zmapowałeś, obiekt się zgadza. Jeśli klient nie zgłasza żadnej lokacji, adres, który przedstawia, nie wpada w żaden obiekt podsieci, co zwykle oznacza tłumaczenie albo nieaktualny prefiks. Następnie sprawdź, czy wybrany kontroler jest tym, który miałeś na myśli, zanim uznasz, że mapowanie zawiodło, bo klienci buforują wyniki odnajdywania, a przełączenie przy awarii może zgodnie z prawem wybrać inny kontroler.

Trzymaj trzy umowy w jednym dokumencie: pulę i jej obiekty podsieci, kontrolery osiągalne ze ścieżki VPN oraz politykę, która decyduje, co może robić zalogowany użytkownik. Lokacja nie jest regułą zapory ani granicą izolacji, a następna zmiana puli po cichu odetnie użytkowników zdalnych od modelu sieci katalogu, jeśli mapowanie, trasy i udokumentowane alternatywy nie będą się poruszać razem.