Описание RADIUS Proxy на базе FreeRADIUS и установка [Документация VAS Experts]
Документация VAS Experts Документация VAS Experts-mobile
in

Настройки

  • Показать страницу
  • История страницы
  • Экспорт в PDF
  • Свернуть / развернуть всё
  • Ссылки сюда
  • Показать страницу
  • История страницы
  • Экспорт в PDF
  • Свернуть / развернуть всё
  • Ссылки сюда

    • Различия

    Показаны различия между двумя версиями страницы.

    Ссылка на это сравнение

    Предыдущая версия справа и слеваПредыдущая версия
    Следующая версия    		Предыдущая версия
    dpi:dpi_components:freeradius:balancing_proxy [2024/12/17 11:35] – [Назначение] atereschenkodpi:dpi_components:freeradius:balancing_proxy [2025/12/19 08:59] (текущий) – [Шаг 2. Добавление словаря vasexperts] atereschenko
    Строка 1: Строка 1:
     {{indexmenu_n>1}} {{indexmenu_n>1}}
    -======Настройка FreeRADIUS как балансирующего прокси======+======Описание RADIUS Proxy на базе FreeRADIUS и установка======
     =====Назначение===== =====Назначение=====
    -Пакет FreeRadius настроен как балансирующий proxy-сервер, который распределяет запросы от многих клиентов на одну точку доступа к нескольким серверам.+В СКАТ BRAS Control Plane реализован через fastPCRF, который имеет возможность работы с RADIUS только в режиме active-standby (fail-over) с группой RADIUS серверов — работа только с одним активным RADIUS-сервером из группы и переключение на следующий активный в случае недоступности текущего.\\ 
     +Для реализации сценариев балансировки (Load-Sharing) и распределения по группе RADIUS серверов используется компонент RADIUS Proxy — пакет FreeRADIUS. При этом для fastPCRF сохраняется единая точка входа — сервер FreeRADIUS, который выступает как proxy-сервер (он балансирует и распределяет по условиям запросы между известными ему другими операторскими RADIUS-серверами). Proxy-сервер запоминает на каком RADIUS-сервере был авторизован абонент и далее направляет аккаунтинг и повторные авторизации на этот же сервер.
      
    -Когда клиент проходит аутентификацию на RADIUS сервере оператора, на сервере происходит проверка соответствия имени пользователя и пароля данным из базы данных пользователей. Если данные совпадают, то клиент проходит авторизацию. Однако при большом количестве пользователей процесс авторизации может занимать длительное время.+=====Варианты режимов балансировки=====
      
    -Для решения этой проблемы предлагается использовать параллельные серверы и балансировку нагрузки между ними в зависимости от загруженности каждого сервера. При этом для fastPCRF сохраняется единая точка входа — сервер FreeRADIUS, который выступает как proxy-сервер (он только балансирует запросы между известными ему другими операторскими RADIUS-серверами). Proxy-сервер запоминает, что если он авторизовал пользователя A на сервере B, то запрос будет направлен преимущественно на этот же сервер B.+  - **''fail-over''** — запрос отправляется на первый живой домашний сервер в списке. Т.е. если первый домашний сервер отмечен как "мертвый", то выбирается второй и т.д.\\ \\ 
     +  - **''load-balance''** — выбирается наименее загруженный домашний сервер, где "наименьшая загруженность" определяется путем определения количества запросов, отправленных на этот домашний сервер, и вычитанием количества ответов, полученных от этого домашнего сервера.\\ \\ Если существует два или более сервера с одинаково низкой нагрузкой, то один из них выбирается случайным образом. Такая конфигурация наиболее похожа на старый ''round-robin'', хотя это не совсем так.\\ \\ Обратите внимание, что балансировка нагрузки не очень хорошо работает с EAP, поскольку EAP требует, чтобы пакеты для EAP-взаимодействия отправлялись на один и тот же домашний сервер. Метод балансировки нагрузки не сохраняет состояние между пакетами, что означает, что EAP-пакеты для одного и того же разговора могут быть отправлены на разные домашние серверы. Это не позволит EAP работать.\\ \\ Для методов аутентификации, отличных от EAP, и для учетных пакетов мы рекомендуем использовать ''load-balance''. Это позволит обеспечить максимальную доступность вашей сети.\\ \\ 
     +  - **''client-balance''** — домашний сервер выбирается путем хэширования IP-адреса источника пакета. Если этот домашний сервер не работает, то используется следующий по списку, как и в случае при ''fail-over''.\\ \\ Невозможно предсказать, какой IP-адрес источника будет сопоставлен к какому домашнему серверу.\\ \\ Эта конфигурация наиболее полезна для выполнения простой балансировки нагрузки для сеансов EAP, поскольку сеанс EAP будет всегда будет отправляться на один и тот же домашний сервер.\\ \\ 
     +  - **''client-port-balance''** — выбор домашнего сервера осуществляется путем хэширования IP-адреса и порта источника пакета. Если этот домашний сервер не работает, то используется следующий по списку используется, как и в случае с "fail-over".\\ \\ Этот метод обеспечивает несколько лучшую балансировку нагрузки для сессий EAP, чем "client-balance". Однако это также означает, что пакеты аутентификации и учета для одного и того же сеанса МОГУТ отправляться на разные домашние серверы.\\ \\ 
     +  - **''keyed-balance''** — выбор домашнего сервера осуществляется путем хэширования (FNV) содержимого атрибута Load-Balance-Key из элементов управления. Затем запрос отправляется на домашний сервер выбранный пользователем:<code bash>server = (hash % num_servers_in_pool)</code>Если в элементах управления отсутствует Load-Balance-Key, метод балансировки нагрузки идентичен "load-balance".\\ \\ Для большинства не-EAP методов аутентификации атрибут User-Name является хорошим ключом. Политика "unlang" может быть использована для копирования User-Name в атрибут Load-Balance-Key атрибут. Этот метод может не работать для сессий EAP, поскольку имя пользователя вне туннеля TLS часто является статическим статичным, например, "anonymous@realm".
      
     +=====Установка=====
      
     +====Шаг 1. Установка FreeRADIUS====
     +Установить основные пакеты для FreeRADIUS:
     +<code bash>sudo yum install freeradius freeradius-utils freeradius-mysql</code>
      
    -=====Настройка балансировки запросов клиентов между серверами===== +====Шаг 2. Добавление словаря vasexperts==== 
    -**Шаг 1.** Добавление прокси в список клиентов серверов+В директорию ''/usr/share/freeradius/'' добавить словарь и после включить его в файле ''dictionary''. Если он уже добавлен, рекомендуется перезаписать его, так как не все новые атрибуты могут быть определены в изначальной версии: 
     +<code bash>cp /usr/share/dpi/dictionary.vasexperts /usr/share/freeradius/</code>
      
    -В конфигурационном файле ''clients.conf'' на стороне **Radius-сервера** определить прокси как клиента: +<note tip>Важно отметить, что ''freeradius'' – это название пакета, а ''radiusd'' – это имя службы (демона), управляющего им. Директория, где находится конфигурация FreeRADIUS до версии 3, называется ''/etc/raddb/'' \\ 
    -<code bash>client client1 { +''/usr/share/dpi/dictionary.vasexperts'' - этот файл находится на сервере, где установлен fastDPI.  
    -    ipv4addr = 10.10.10.61 +</note>
    -    secret = testing123 +
    -}</code> +
    - +
    -**Шаг 2.** Добавление клиента в список клиентов прокси +
    - +
    -В конфигурационном файле ''clients.conf'' на стороне **прокси** определить клиента: +
    -<code bash>client client1 { +
    -    ipv4addr = 10.10.10.60 +
    -    secret = testing123 +
    -}</code> +
    - +
    -**Шаг 3.** Добавление серверов и параметров балансировки в конфигурацию прокси +
    - +
    -В файле ''proxy.conf'' конфигурации прокси: +
    -  - Продублировать секцию ''home_server localhost {}'' соответственно числу серверов; +
    -  - Переименовать каждую новую секцию и настроить параметр ''ipv4addr = адрес_сервера'':<code bash>home_server server1 { +
    -    ipv4addr = 10.10.10.62 +
    -} +
    -home_server server2 { +
    -    ipv4addr = 10.10.10.63 +
    -}</code> +
    -  - Отредактировать раздел ''home_server_pool my_auth_failover {}'' +
    -    - Изменить режим балансировки — изменить параметр ''type = fail-over'' на ''type = load-balance'' (описание режимов балансировки в разделе [[dpi:dpi_components:freeradius:balancing_proxy#варианты_режимов_балансировки|Варианты режимов балансировки]]) +
    -    - Закомментировать строчку ''home_server = localhost'' +
    -    - Для каждого сервера добавить строки ''home_server = имя_секции'' из пункта 2  +
    - +
    -<code bash> +
    -home_server_pool my_auth_failover { +
    -    type = load-balance +
    -    //home_server = localhost +
    -    home_server = server1 +
    -    home_server = server2 +
    -} +
    -</code> +
    - +
    -<note>Опционально: для повышения быстродействия можно отключить лишние модули проверки в каталоге ''mods-enabled'' (там находятся символические ссылки на конфигурации модулей, которые "должны быть загружены").</note> +
    - +
    -=====Варианты режимов балансировки===== +
    - +
    -  - **''fail-over''** — запрос отправляется на первый живой домашнему серверу в списке. Т.е. если первый домашний сервер отмечен как "мертвый", то выбирается второй и т.д.\\ \\ +
    -  - **''load-balance''** — выбирается наименее загруженный домашний сервер, где "наименьшая загруженность" определяется путем определения количества запросов, отправленных на этот домашний сервер, и вычитанием количество ответов, полученных от этого домашнего сервера.\\ \\ Если существует два или более сервера с одинаково низкой нагрузкой, то один из них выбирается случайным образом. Такая конфигурация наиболее похожа на старый "round-robin", хотя это не совсем так.\\ \\ Обратите внимание, что балансировка нагрузки не очень хорошо работает с EAP, поскольку EAP требует, чтобы пакеты для EAP-взаимодействия отправляться на один и тот же домашний сервер. Метод балансировки нагрузки Не сохраняет состояние между пакетами, что означает, что EAP-пакеты для одного и того же разговора могут быть отправлены на разные домашние серверы. Это не позволит EAP работать.\\ \\ Для методов аутентификации, отличных от EAP, и для учетных пакетов мы рекомендуем использовать "load-balance". Это позволит обеспечить максимальную доступность вашей сети.\\ \\ +
    -  - **''client-balance''** — домашний сервер выбирается путем хэширования IP-адреса источника пакета. Если этот домашний сервер не работает, то используется следующий по списку, как и в случае при "fail-over".\\ \\ Невозможно предсказать, какой IP-адрес источника будет сопоставлен к какому домашнему серверу.\\ \\ Эта конфигурация наиболее полезна для выполнения простой балансировки нагрузки балансировки нагрузки для сеансов EAP, поскольку сеанс EAP будет всегда будет отправляться на один и тот же домашний сервер.\\ \\ +
    -  - **''client-port-balance''** — выбор домашнего сервера осуществляется путем хэширования IP-адреса и порта источника пакета. Если этот домашний сервер не работает, то используется следующий по списку используется, как и в случае с "fail-over".\\ \\ Этот метод обеспечивает несколько лучшую балансировку нагрузки для сессий EAP, чем "client-balance". Однако это также означает, что пакеты аутентификации и учета для одного и того же сеанса МОГУТ отправляться на разные домашние серверы.\\ \\ +
    -  - **''keyed-balance''** — выбор домашнего сервера осуществляется путем хэширования (FNV) содержимого атрибута Load-Balance-Key из элементов управления. Затем запрос отправляется на домашний сервер выбранный пользователем:<code bash>server = (hash % num_servers_in_pool)</code>Если в элементах управления отсутствует Load-Balance-Key, метод балансировки нагрузки идентичен "load-balance".\\ \\ Для большинства не-EAP методов аутентификации атрибут User-Name является хорошим ключом. Политика "unlang" может быть использована для копирования User-Name в атрибут Load-Balance-Key атрибут. Этот метод может не работать для сессий EAP, поскольку имя пользователя вне туннеля TLS часто является статическим статичным, например, "anonymous@realm".+