VPN - Конфигуриране на сървър на Active Directory [AD] чрез VPN тунел

Имате още въпроси? Подаване на заявка

Важно известие:
Уважаеми клиенти, моля, имайте предвид, че използваме машинен превод, за да предоставяме статии на вашия местен език. Възможно е не всички текстове да бъдат преведени точно. Ако има въпроси или несъответствия относно точността на информацията в преведената версия, моля, прегледайте оригиналната статия тук: Оригинална версия

Тази статия предоставя подробен преглед на това как да конфигурирате сървър на Active Directory (AD) чрез L2TP VPN тунел, като използвате метода за удостоверяване USG FLEX/ATP VPN. Освен това представените тук насоки са приложими за IPsec IKEv2 и IKEv1 VPN конфигурации.

VPN тунелите са критичен компонент при създаването на мрежи, които по своята същност са експанзивни, като например глобални корпоративни мрежи или основни обекти, свързани с дъщерни локации.

Основна характеристика на корпоративните мрежи е процесът на удостоверяване на потребителите пред сървър, като по този начин се демонстрира надеждност и се получава достъп до вътрешни ресурси. Този урок има за цел да ви предостави необходимите инструменти за конфигуриране на удостоверяване към сървър за удостоверяване чрез VPN тунел.
mceclip2.png

Две защитни стени са свързани чрез Site-to-Site VPN, а на главния сайт A има RADIUS-сървър в рамките на локалната мрежа. На обект Б може да има няколко клиента, които искат да се удостоверят пред RADIUS сървъра на обект А. На обект Б има или местни клиенти, които се нуждаят от връзка с RADIUS сървъра на обект А, или L2TP VPN клиенти, които се нуждаят от удостоверяване пред RADIUS на обект А.

Тук трябва да направим важно разграничение между VPN клиента и локалния клиент на сайт Б - докато е много вероятно клиентът от сайт Б да може да се удостовери без проблем към RADIUS на сайт А, L2TP VPN клиентите най-вероятно няма да могат да го направят. Защо е така?

Site-to-Site VPN мрежите се настройват с местна политика и отдалечена политика. Тези политики определят кои мрежови маршрути се създават при създаването на тунел, т.е. на кои мрежи е позволено да "разговарят помежду си". В този случай приемаме, че маршрутизирането между 192.168.10.0/24 и 192.168.20.0/24 е наред. На L2TP VPN, която по своята същност трябва да бъде различна подмрежа от локалните подмрежи на Сайт Б, не е позволено да комуникира към Сайт А, защото той не е включен в местната или отдалечената политика.

Това е, ако не добавяме допълнителни маршрути към политиката. С помощта на този вид маршрути можем да принудим всеки опит за удостоверяване, идващ от L2TP VPN, към дестинация на Сайт А. Първо, трябва да определим, че удостоверяванията на Сайт Б се насочват към RADIUS на Сайт А.

Конфигуриране на AAA сървъра

Конфигурация > Обект > AAA сървър

и настройте обект за удостоверяване към IP адрес 192.168.10.100:

mceclip0.png

Тествайте AD удостоверяването си

Конфигурация -> Обект -> Сървър AAA

Уверете се, че сте запазили конфигурацията си, преди да тествате валидирането на конфигурацията.

Добър резултат Лош резултат

Конфигуриране на Auth. Метод

Сега този AAA Server-Object трябва да се комбинира с метод за удостоверяване, който на свой ред се задава като основно удостоверяване за нашата VPN. Първо, отидете в менюто

Конфигурация > Обект > Auth. Method

и добавете новосъздадения AAA сървър към метода по подразбиране Auth. Method:

mceclip1.png

Направете така, че защитната стена да се присъедини към AD сървъра

След това USG трябва да се присъедини към AD домейна с името на домейна на AD сървъра

Отидете в Конфигурация -> Система -> Име на хост

Realm (Област) е името на домейна на рекламния сървър, а NetBIOS името е домейнът.

За да насочим защитната стена към AD сървъра, трябва да създадем DNS запис, за да намерим успешно AD сървъра чрез IP адреса на AD сървъра:

Конфигуриране на VPN

Чрез IKEv2

Конфигурация -> VPN -> IPSec VPN -> VPN шлюз - Добавяне/редактиране

Щракнете върху "Show Advanced Settings" (Показване на разширени настройки) и включете "Extended Authentication Protocol" (Разширен протокол за удостоверяване) и изберете "Server mode" (Режим на сървъра).

След това изберете метода AAA (Auth. Method) и Allowed user

Чрез L2TP

След това избираме този Auth. Method, за да се използва чрез L2TP VPN чрез

Конфигурация > VPN > L2TP през IPSec VPN

mceclip2.png

(Моля, обърнете внимание, че резервът от IP адреси не съответства на топологията, нарисувана по-горе, тъй като това е само пример за това как да настроите L2TP-тунела)

Сега, след като L2TP VPN е конфигуриран с удостоверяване, което трябва да се препрати към RADIUS на обект А, трябва да създадем маршрути на политиката:

mceclip3.png

Първият маршрут на политиката ще вкарва всичко, което идва от какъвто и да е източник и иска да се придвижи към IP адреса 192.168.10.100, в тунела към сайт А - което означава и опит за удостоверяване от нашата L2TP VPN. Вторият маршрут на политиката ще изтласква всичко, предназначено за подмрежата на L2TP VPN, обратно към L2TP VPN.

На другия сайт сега просто трябва да допълним това чрез съответното правило, което ще изтласка всичко от подмрежи, различни от локалната мрежа на сайта B (като опита на нашата подмрежа L2TP VPN), обратно в тунела към сайта B, задействайки нашия маршрут на политиката, който сме задали на този сайт.

Следвайки това просто ръководство, вече трябва да можете да удостоверявате клиентите си към RADIUS на друго отдалечено място на VPN.

Конфигуриране на DNS пренасочване за AD домейн (препоръчително)

За да осигурите правилно разрешаване на имената на AD, конфигурирайте DNS пренасочване в допълнение към локалния DNS запис:

  • Отидете в Configuration → System → DNS → Domain Zone Forwarder, добавете вашия AD домейн (напр. company.local) и задайте AD DNS сървъра като forwarder.

  • В VPN Connection (VPN връзка) → Client Settings (Настройки на клиента) задайте AD DNS сървъра (или LAN IP адреса на защитната стена, ако е разрешено препращането) като First DNS Server (Първи DNS сървър).

  • (По избор) Добавете маршрут на политиката, ако DNS заявките трябва да бъдат прокарани през VPN мрежата.

Проверете с: nslookup dc1.company.local.

Отстраняване на неизправности и проверка на резултата

Навигирайте до

Монитор -> Състояние на мрежата -> Потребители за вход

Навигирайте до

Монитор -> Монитор на VPN -> IPSec

Отстраняване на неизправности

Отидете в уеб конзолата на защитната стена или се свържете с нея чрез SSH и изпълнете тази команда

debug domain-auth test profile-name [ad profile name] username [username] password [password]

Заменете името на профила ad с името на Active Directory "AD Server Summary" и използвайте потребителското име и паролата за удостоверяване на домейна чрез MSCHAP.

Още статии можете да намерите тук:

AD (активна директория) проверка на автентичността на потребителя

Как да се присъедините към домейна на Active Directory с USG/ATP/VPN

Как да извършим двуфакторно удостоверяване на автентичността на потребители на Active Directory

Статии в този раздел

Беше ли полезна тази статия?
2 от 3 считат материала за полезен
Споделяне

Коментари

0 коментара

Влезте в услугата, за да оставите коментар.