• Главная
  • Карта сайта
Не найдено

Надійність і масштабованість віддаленого доступу до віддаленого доступу (RADIUS)

РАДИУС or Служба віддаленого підключення по телефонній лінії користувача це мережевий протокол, що забезпечує централізоване управління аутентифікацією, авторизацією і урахуванням користувачів і пристроїв. Він широко використовується Інтернет-провайдерами та підприємствами для контролю доступу до Інтернету, локальних послуг, бездротових мереж через точки доступу WiFi і т. Д.

Протокол RADIUS реалізований на рівні додатків з архітектурою клієнт-сервер, яка може використовувати TCP або UDP як транспортний рівня і обмінюватися даними з призначеною для користувача базою даних, такий як Active Directory, Служба LDAP or Система обліку Linux, Найбільш популярними рішеннями RADIUS є FreeRadius або Microsoft NPS Radius Server.

Протокол обміну повідомленнями заснований на запиті клієнта і відповіді сервера, як показано нижче.

Протокол обміну повідомленнями заснований на запиті клієнта і відповіді сервера, як показано нижче

1. Клієнт відправляє Access-Request на сервер для кожного користувача або пристрою для аутентифікації на порт сервера TCP / UDP 1812 (старі версії сервера використовуватимуть 1 645 для перевірки справжності).
2. Сервер відповідає відповідно до політики Access-Accept якщо аутентифікація дозволена, Access-Reject якщо доступ не дозволений або Access-Challenge якщо серверу потрібна додаткова інформація для визначення доступу (наприклад, друга перевірка: PIN-код, пароль, сертифікат і т. д.)

При бажанні, клієнт і сервер можуть обмінюватися повідомленнями обліку, наприклад, Accounting-Request Accounting-Response для того, щоб підтримувати унікальний ідентифікатор сеансу.

3. Клієнт відправляє Accounting-Request на сервер через порт TCP / UDP +1813 для управління обліковими сесіями (старі версії сервера використовуватимуть 1 646 для перевірки справжності).
4. Сервер відповідає з Accounting-Response повідомлення для підтвердження нового сеансу.

У середовищі RADIUS потрібна додаткова послуга для управління базами даних користувачів, яку важливо враховувати при високій доступності, що буде розглянуто в іншій конкретній статті.

Проблема, якщо служба RADIUS не працює, може привести до того, що користувачі не зможуть отримати доступ до мережі серверів або увійти в додаток, користувачі не зможуть відкрити сеанс на пристрої або не зможуть отримати дозвіл на використання права бізнес-процес. Щоб дозволити подібні ситуації, метою цієї статті є налагодження середовища, показаної нижче.

Щоб дозволити подібні ситуації, метою цієї статті є налагодження середовища, показаної нижче

Zevenet буде ділитися повідомленнями протоколу RADIUS серед всіх серверів RADIUS, будь то на різних або локальних сайтах. У наступних розділах ми пояснюємо конфігурацію середовищ такого типу, розширені перевірки працездатності служб RADIUS і проблеми безпеки цього протоколу.

Природа протоколу RADIUS заснована на пакетах UDP, тому конфігурація надійної середовища RADIUS будується з LSLB ферма з L4xNAT профіль на шарі 4, порти 1812 1813 тип протоколу UDP і кращий ДТА для того, щоб мати прозорість і отримати IP-адресу клієнта на стороні сервера (хоча NAT має працювати відмінно, а також).

в Послуги сталість не потрібно за замовчуванням, якщо не потрібна деяка прив'язка між сервером клієнтського радіусу.

Якщо RADIUS використовується через TCP замість UDP, його можна змінити в полі типу протоколу. Це може бути встановлено також BCE протоколи, що дозволяють одночасно використовувати TCP і UDP з одного і того ж віртуального IP.

Нарешті, налаштуйте серверні частини без налаштованих портів (так як він буде використовувати порт призначення клієнтського з'єднання) і протестуйте з'єднання. Як тільки віртуальна служба RADIUS буде успішно налаштована, ми можемо встановити розширену перевірку працездатності для цієї служби.

Попередня перевірка включена в Zevenet з ім'ям check_radius в папці за умовчанням / USR / місцеві / zenloadbalancer / додаток / libexec /.

Довідка цієї команди може бути перерахована:

root @ zevenet5 # / usr / local / zenloadbalancer / app / libexec / check_radius --help Tests to see if a RADIUS server is accepting connections. Usage: check_radius -H host -F config_file -u username -p password [-P port] [-t timeout] [-r retries] [-e expect] [-n nas-id] [-N nas-ip-addr ] Options: -h, --help Print detailed help screen -V, --version Print version information --extra-opts = [section] [@ file] Read options from an ini file. See https://www.monitoring-plugins.org/doc/extra-opts.html for usage and examples. -H, --hostname = ADDRESS Host name, IP Address, or unix socket (must be an absolute path) -P, --port = INTEGER Port number (default: 1645) -u, --username = STRING The user to authenticate -p, --password = STRING Password for autentication (SECURITY RISK) -n, --nas-id = STRING NAS identifier -N, --nas-ip-address = STRING NAS IP Address -F, --filename = STRING Configuration file -e, --expect = STRING Response string to expect from the server -r, --retries = INTEGER Number of times to retry a failed connection -t, --timeout = INTEGER Seconds before connection times out (default: 10) This plugin tests a RADIUS server to see if it is accepting connections. The server to test must be specified in the invocation, as well as a user name and password. A configuration file may also be present. The format of the configuration file is described in the radiusclient library sources. The password option presents a substantial security issue because the password can possibly be determined by careful watching of the command line in a process listing. This risk is exacerbated because the plugin will typically be executed at regular predictable intervals. Please be sure that the password used does not allow access to sensitive system resources.

По-перше, давайте перевіримо, чи працює він правильно, виконавши наступну зразкову команду (будь ласка, використовуйте ваші власні параметри конфігурації клієнта радіуса з Zevenet):

root @ zevenet5 # cd / usr / local / zenloadbalancer / app / libexec / root @ zevenet5 # ./check_radius -H <RADIUS_SERVER_IP> -P <RADIUS_SERVER_PORT> -u <DUMMY_USER_NAME> -p <DUMMY_USER_PASSWD> -F <RADIUS_CLIENT_CONFIG_FILE>

Тест буде проводитися з пристрою Zevenet на один певний сервер RADIUS з фіктивною перевіркою користувача і, необов'язково, файл конфігурації клієнта для конкретних параметрів клієнта. Давайте перевіримо команду, а потім, коли ми отримаємо OK з сервера і тому FAILURE коли він вимкнений, ми можемо налаштувати розширену перевірку працездатності в Послуги розділ нашого щойно створеного віртуального сервісу.

Не забудьте використовувати ВЕДУЧИЙ токен при налаштуванні розширених перевірок працездатності в Zevenet, як описано нижче.

check_radius -H HOST -P 1812 -u johndoe -p johnspass -F /etc/radius_client.cfg

Дивіться нижче Послуги Конфігурація розділу.

Дивіться нижче Послуги Конфігурація розділу

Протокол RADIUS традиційно використовує алгоритми MD5 для перевірки справжності кожного пакета і перевірки цілісності через UDP. Оскільки ці два не забезпечують ніякого безпечного шифрування і захисту, було вивчено кілька підходів.

Розгортання RADIUS пройшли IPsec or Internet Protocol Security були широко розгорнуті, але є деякі труднощі з цією опцією, так як прикладний рівень не знає про політиків безпеки, так як він неявно присутній на мережевому рівні. Щоб використовувати цей підхід з Zevenet, потрібна деяка ручна настройка, оскільки вона ще не інтегрована.

Специфікація DTLS or Безпека дейтаграми на транспортному рівні дозволяє забезпечувати шифрування, відстежувати і контролювати політики безпеки такого трафіку.

Іншим варіантом буде RADIUS більш TLS це забезпечує можливості TCP надійності і упорядкованого транспортного рівня.

Для такого роду підходів IANA створив офіційну запис для RadSec (RADIUS Безпека) використовувати UDP 2083 порт для RADIUS / TLS Реалізації.

Іншим варіантом буде поліпшення рівня дайджесту і авторизації за допомогою EAP (Розширюваний протокол аутентифікації), який не використовується на рівні встановлення каналу, але на етапі аутентифікації з'єднання, уникаючи використання слабких дайджестів MD5.

Крім того, за допомогою Zevenet служби RADIUS можуть бути захищені модулем IPDS від шкідливих пакетів і хостів, DoS-атак, спроб перебору і багато чого іншого.

Якщо кілька серверів RADIUS розгорнуті на різних сайтах, було б цікаво перенаправити клієнтське з'єднання на сайт, який управляє їх даними аутентифікації, авторизації та обліку. В даний час Zevenet не підтримує можливості проксі-сервера RADIUS, але скоро планується його включення. З нетерпінням чекаємо останніх розробок!

Насолоджуйтесь своїми високодоступних і масштабованими послугами доступу до мережі!

Документація відповідно до умов GNU Free Documentation License.

Провайдеры:
  • 08.09.2015

    Batyevka.NET предоставляет услуги доступа к сети Интернет на территории Соломенского района г. Киева.Наша миссия —... 
    Читать полностью

  • 08.09.2015
    IPNET

    Компания IPNET — это крупнейший оператор и технологический лидер на рынке телекоммуникаций Киева. Мы предоставляем... 
    Читать полностью

  • 08.09.2015
    Boryspil.Net

    Интернет-провайдер «Boryspil.net» начал свою работу в 2008 году и на данный момент является одним из крупнейших поставщиков... 
    Читать полностью

  • 08.09.2015
    4OKNET

    Наша компания работает в сфере телекоммуникационных услуг, а именно — предоставлении доступа в сеть интернет.Уже... 
    Читать полностью

  • 08.09.2015
    Телегруп

    ДП «Телегруп-Украина» – IT-компания с 15-летним опытом работы на рынке телекоммуникационных услуг, а также официальный... 
    Читать полностью

  • 08.09.2015
    Софтлинк

    Высокая скоростьМы являемся участником Украинского центра обмена трафиком (UA — IX) с включением 10 Гбит / сек... 
    Читать полностью