VPN - Konfiguracja serwera Active Directory [AD] przez tunel VPN

Ważna informacja:
Drogi kliencie, pamiętaj, że korzystamy z tłumaczenia maszynowego, aby dostarczać artykuły w Twoim lokalnym języku. Nie wszystkie teksty mogą być przetłumaczone dokładnie. W przypadku pytań lub rozbieżności dotyczących dokładności informacji w przetłumaczonej wersji, prosimy o zapoznanie się z oryginalnym artykułem tutaj:Wersja oryginalna

Ten artykuł zawiera szczegółowy przegląd sposobu konfigurowania serwera Active Directory (AD) za pośrednictwem tunelu L2TP VPN przy użyciu metody uwierzytelniania USG FLEX/ATP VPN. Ponadto przedstawione tutaj wskazówki mają zastosowanie do konfiguracji IPsec IKEv2 i IKEv1 VPN.

Tunele VPN są krytycznym elementem przy tworzeniu sieci, które są z natury ekspansywne, takich jak globalne sieci korporacyjne lub główne lokalizacje połączone z lokalizacjami zależnymi.

Podstawową cechą sieci korporacyjnych jest proces uwierzytelniania użytkowników na serwerze, wykazując w ten sposób wiarygodność i uzyskując dostęp do zasobów wewnętrznych. Ten samouczek ma na celu wyposażenie użytkownika w niezbędne narzędzia do skonfigurowania uwierzytelniania do serwera uwierzytelniania za pośrednictwem tunelu VPN.
mceclip2.png

Dwie zapory sieciowe są połączone za pośrednictwem sieci VPN typu Site-to-Site, a w głównej lokalizacji A w sieci LAN znajduje się serwer RADIUS. W witrynie B może być kilku klientów, którzy chcą uwierzytelnić się na serwerze RADIUS w witrynie A. W witrynie B znajdują się albo lokalni klienci, którzy wymagają połączenia z serwerem RADIUS w witrynie A, albo klienci L2TP VPN, którzy wymagają uwierzytelnienia na serwerze RADIUS w witrynie A.

Tutaj musimy dokonać ważnego rozróżnienia między klientem VPN a klientem LAN w witrynie B - podczas gdy jest bardzo prawdopodobne, że klient z witryny B może bez problemu uwierzytelnić się w RADIUS witryny A, klienci L2TP VPN najprawdopodobniej nie będą w stanie tego zrobić. Dlaczego?

Sieci VPN typu Site-to-Site są konfigurowane za pomocą zasad lokalnych i zdalnych. Zasady te określają, które trasy sieciowe są tworzone podczas tworzenia tunelu, co oznacza, które sieci mogą ze sobą "rozmawiać". W tym przypadku zakładamy, że routing między 192.168.10.0/24 i 192.168.20.0/24 jest w porządku. Sieć L2TP VPN, która z natury musi być inną podsiecią niż lokalne podsieci w witrynie B, nie może komunikować się z witryną A, ponieważ nie jest objęta polityką lokalną ani zdalną.

To znaczy, jeśli nie dodamy dodatkowych tras polityki. Za pomocą tego rodzaju tras możemy wymusić każdą próbę uwierzytelnienia pochodzącą z sieci L2TP VPN w kierunku miejsca docelowego w witrynie A. Najpierw musimy zdefiniować, że uwierzytelnianie w witrynie B jest kierowane do usługi RADIUS w witrynie A.

Konfiguracja serwera AAA

Konfiguracja > Obiekt > Serwer AAA

i skonfigurować obiekt uwierzytelniania dla adresu IP 192.168.10.100:

mceclip0.png

Przetestuj uwierzytelnianie AD

Konfiguracja -> Obiekt -> Serwer AAA

Pamiętaj, aby zapisać konfigurację przed przetestowaniem jej poprawności.

Dobry wynik Zły wynik

Skonfiguruj metodę Auth. Method

Ten obiekt serwera AAA musi teraz zostać połączony z metodą uwierzytelniania, która z kolei zostanie ustawiona jako główne uwierzytelnianie dla naszej sieci VPN. Najpierw przejdź do menu

Configuration > Object > Auth. Method

i dodać nowo utworzony serwer AAA do domyślnej metody Auth. Method:

mceclip1.png

Przyłącz zaporę do serwera AD

Następnie USG musi dołączyć do domeny AD z nazwą domeny serwera AD

Przejdź do Konfiguracja -> System -> Nazwa hosta

Obszar to nazwa domeny serwera reklam, a nazwa NetBIOS to domena.

Aby skierować zaporę na serwer AD, musimy utworzyć rekord DNS, aby pomyślnie znaleźć serwer AD za pośrednictwem adresu IP serwera AD:

Konfiguracja VPN

Poprzez IKEv2

Konfiguracja -> VPN -> IPSec VPN -> Brama VPN - Dodaj/Edytuj

Kliknij "Pokaż ustawienia zaawansowane" i włącz "Rozszerzony protokół uwierzytelniania" i wybierz tryb serwera.

Następnie wybierz metodę AAA (Auth. Method) i dozwolonego użytkownika (Allowed user).

Przez L2TP

Następnie wybieramy tę metodę Auth. Method, która ma być używana przez L2TP VPN poprzez

Konfiguracja > VPN > L2TP przez IPSec VPN

mceclip2.png

(Należy pamiętać, że pula adresów IP nie odpowiada topologii narysowanej powyżej, ponieważ jest to tylko przykład konfiguracji tunelu L2TP).

Teraz, gdy L2TP VPN jest skonfigurowany z uwierzytelnianiem, które powinno być przekazywane do RADIUS w witrynie A, musimy utworzyć trasy zasad:

mceclip3.png

Pierwsza trasa polityki będzie przepychać wszystko, co pochodzi z dowolnego źródła, które chce przejść do adresu IP 192.168.10.100, do tunelu do witryny A - co oznacza również próbę uwierzytelnienia z naszej sieci L2TP VPN. Druga trasa polityki wypchnie wszystko, co jest przeznaczone dla podsieci L2TP VPN z powrotem do L2TP VPN.

W drugiej witrynie musimy teraz po prostu uzupełnić to za pomocą odpowiedniej reguły, która wypchnie wszystko z podsieci różniących się od sieci LAN witryny B (jak próba naszej podsieci L2TP VPN) z powrotem do tunelu w kierunku witryny B, wyzwalając naszą trasę polityki, którą ustawiliśmy w tej witrynie.

Postępując zgodnie z tym prostym przewodnikiem, powinieneś być teraz w stanie uwierzytelnić swoich klientów w RADIUS w innej zdalnej lokalizacji VPN.

Konfiguracja przekierowania DNS dla domeny AD (zalecane)

Aby zapewnić prawidłowe rozpoznawanie nazw AD, skonfiguruj przekierowanie DNS oprócz lokalnego wpisu DNS:

  • Przejdź do Configuration → System → DNS → Domain Zone Forwarder, dodaj domenę AD (np. company.local) i ustaw serwer DNS AD jako forwarder.

  • W VPN Connection → Client Settings przypisz serwer DNS AD (lub adres IP sieci LAN zapory, jeśli przekazywanie jest włączone) jako Pierwszy serwer DNS.

  • (Opcjonalnie) Dodaj trasę zasad, jeśli zapytania DNS muszą być wymuszane przez VPN.

Zweryfikuj za pomocą: nslookup dc1.company.local.

Rozwiązywanie problemów i testowanie wyników

Przejdź do

Monitor -> Stan sieci -> Zaloguj użytkowników

Przejdź do

Monitor -> Monitor VPN -> IPSec

Rozwiązywanie problemów

Przejdź do konsoli internetowej zapory lub połącz się z zaporą przez SSH i uruchom następujące polecenie

debug domain-auth test profile-name [nazwa profilu reklamowego] username [nazwa użytkownika] password [hasło]

Zastąp nazwę profilu ad nazwą Active Directory "AD Server Summary" i użyj nazwy użytkownika i hasła uwierzytelniania domeny za pośrednictwem MSCHAP.

Więcej artykułów można znaleźć tutaj:

Sprawdzanie uwierzytelniania użytkownika AD (Active Directory)

Jak dołączyć do domeny Active Directory za pomocą USG/ATP/VPN

Jak wykonać uwierzytelnianie dwuskładnikowe z użytkownikami Active Directory

Artykuły w tej sekcji

Czy ten artykuł był pomocny?
Liczba użytkowników, którzy uważają ten artykuł za przydatny: 2 z 3
Udostępnij

Komentarze

Komentarze: 0

Zaloguj się, aby dodać komentarz.