Для чего нужен radius сервер
Перейти к содержимому

Для чего нужен radius сервер

  • автор:

RADIUS — cлужба удаленной аутентификации входящих звонков пользователей

Протокол авторизации RADIUS является ключевой частью большинства биллинговых систем. Для лучшего понимания принципов работы ExpertBilling System советуем вам ознакомиться с данной статьей.Здесь присутствуют элементы документации RFC 2865 и RFC 2866.

Oсновные составные части службы идентификации удаленных пользователей (Remote Authentication Dial-In User Service, RADIUS) описываются двумя RFC от IETF: RFC 2865 под названием Remote Authentication Dial-In User Service (RADIUS) в форме проекта стандарта и RFC 2866 под названием RADIUS Accounting в виде «информационного RFC».

Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Со временем выкристаллизовались и другие области применения этой технологии. К ним относятся серверы виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве своем поддерживают Rаdius, — а также точки доступа беспроводных локальных сетей (Wireless LAN, WLAN), и это далеко не все.

Концепция службы идентификации удаленных пользователей подразумевает, что клиент RADIUS — обычно сервер доступа, сервер VPN или точка доступа беспроводной локальной сети — отсылает серверу RADIUS параметры доступа пользователя (в англоязычной документации они часто называются Credentials, т. е. мандат, куда, к примеру, входят его настройки безопасности и права доступа), а также параметры соответствующего соединения. Для этого клиент использует специальный формат, так называемый RADIUS-Message (сообщение RADIUS). В ответ сервер начинает проверку, в ходе которой он аутентифицирует и авторизует запрос клиента RADIUS, а затем пересылает ему ответ — RADIUS-Message-response. После этого клиент передает на сервер RADIUS учетную информацию.

Сами по себе сообщения RADIUS передаются в форме пакетов UDP. Причем информация об аутентификации направляется на порт UDP с номером 1812. Некоторые серверы доступа используют, однако, порты 1645 (для сообщений об аутентификации) или, соответственно, 1646 (для учета) — выбор должен определять своим решением администратор. В поле данных пакета UDP (так называемая полезная нагрузка) всегда помещается только одно сообщение RADIUS. В соответствии с RFC 2865 и RFC 2866 определены следующие типы сообщений:

  • Access-Request — «запрос доступа». Запрос клиента RADIUS, с которого начинается собственно аутентификация и авторизация попытки доступа в сеть;
  • Access-Accept — «доступ разрешен». С помощью этого ответа на запрос доступа клиенту RADIUS сообщается, что попытка соединения была успешно аутентифицирована и авторизована;
  • Access-Reject — «доступ не разрешен». Этот ответ сервера RADIUS означает, что попытка доступа к сети не удалась. Такое возможно в том случае, если пользовательских данных недостаточно для успешной аутентификации или доступ для пользователя не авторизован;
  • Access-Challenge — «вызов запроса». Сервер RADIUS передает его в ответ на запрос доступа;
  • Accounting-Request — «запрос учета», который клиент RADIUS отсылает для ввода учетной информации после получения разрешения на доступ.

Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из которых содержит ту или иную информацию о попытке доступа: например, имя и пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким образом, главной задачей атрибутов RADIUS является транспортировка информации между клиентами и серверами RADIUS. Атрибуты RADIUS определены в нескольких RFC, а именно: RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869 и RFC 3162.

RADIUS может совместно работать с различными протоколами аутентификации. Наиболее часто используются протокол аутентификации пароля (Password Authentication Protocol, РАР), протокол аутентификации с предварительным согласованием (Challenge Handshake Authentication Protocol, CHAP), а также MS-CHAP (CHAP от Microsoft в первой версии или MS-CHAPv2 — во второй).

Протокол CHAP (Challenge Handshake Authentication Protocol)— это протокол проверки подлинности типа «запрос-ответ», использующий стандартную схему хеширования Message Digest 5 (MD5) для шифрования ответа. Протокол CHAP используется множеством поставщиков серверов и клиентов доступа к сети. Сервер, использующий маршрутизацию и удаленный доступ, поддерживает CHAP таким образом, что выполняется проверка подлинности клиента удаленного доступа, требующего данный протокол. Так как CHAP требует использования обратимо зашифрованного пароля, рекомендуется использовать другой протокол проверки подлинности, например MS-CHAP версии 2.

Операционные системы семейства Windows Server 2003 поддерживают протокол MS-CHAP v2, обеспечивающий взаимную проверку подлинности, создание более надежных начальных ключей шифрования данных для MPPE (Microsoft Point-to-Point Encryption) и разные ключи шифрования для отправки и приема данных. Чтобы свести к минимуму риск раскрытия пароля во время обмена паролями, из протокола исключена поддержка старых методов обмена паролями MS-CHAP.

Поскольку версия MS-CHAP v2 обеспечивает более надежную защиту, чем MS-CHAP, при подключении сначала предлагается использовать именно ее (если она доступна), а затем уже MS-CHAP.

Протокол MS-CHAP v2 поддерживается на компьютерах, работающих под управлением Windows XP, Windows 2000, Windows 98, Windows Millennium Edition и Windows NT 4.0. Компьютеры, работающие под управлением Windows 95, поддерживают MS-CHAP v2 только для подключений VPN, но не для подключений удаленного доступа.

Кроме того, возможно применение RADIUS вместе с PPP, протоколом передачи «точка-точка» (Point-to-Point Protocol). Результаты сеанса аутентификации между сервером доступа и действующим клиентом передаются на сервер RADIUS, который их потом удостоверяет.

Для защиты сообщений клиент и сервер RADIUS обладают «общим секретом» или, проще говоря, ключом. При этом речь, как правило, идет о цепочке символов, имеющейся как на серверах, так и на клиенте RADIUS.


НЕПРАВИЛЬНО СКОНФИГУРИРОВАННЫЙ ОБЩИЙ СЕКРЕТ

Еще одна потенциально слабая точка реализации RADIUS касается «общего секрета» (Shared Secret). Это связано с тем, что очень часто один и тот же «общий секрет» служит для поддержки максимального количества пар «клиент-сервер» в службе RADIUS. К тому же в большинстве случаев криптологически он недостаточно устойчив против атаки с перебором слов по словарю в автономном режиме. Значение поля Response Authenticator и содержимое атрибута Message Authenticator легко вычисляются. Потом эти данные сравниваются с перехваченным сообщением Access-Accept, Access-Reject или Access-Challenge. Таким образом, легко разгадываемый «общий секрет» может быть быстро скомпрометирован.

Сложившаяся ситуация усугубляется также некоторыми вариантами реализации RADIUS — довольно часто длина «общего секрета» не может превышать определенной величины, или же набор символов, из которых образуется ключевое слово, ограничен. В качестве примера приведем распространенную установку на использование только тех символов из набора ASCII, которые находятся непосредственно на клавиатуре — то есть лишь 94 из доступных 256 символов ASCII.

Важно знать, что в случае, если выбор ограничен только возможностями клавиатуры, последовательность символов должна состоять как минимум из 22 знаков и при этом содержать примерно в одинаковой пропорции строчные и прописные буквы, цифры и специальные символы. Если же «общий секрет» может быть задан в виде строки из шестнадцатеричных чисел, следует задавать не менее 32 цифр.

RFC 2865 предписывает использование 16 символов в «общем ключе». Однако для достижения энтропии (в теории информации энтропия отражает количество информации в последовательности символов) равной 128 бит каждый отдельный символ должен иметь энтропию 8 бит. В случае же, когда выбор символов ограничен имеющимися на клавиатуре, энтропия 8-битного символа уменьшается до 5,8 бит. Поэтому, чтобы добиться уровня энтропии в 128 бит, необходимо 22 символа. В среде Windows 2000 максимально возможная длина «общего секрета» может быть равна 64 символам (из имеющихся на клавиатуре).

Качественно улучшить результаты позволяет использование программ для генерирования «общего секрета», поскольку при этом обычно получаются лучшие, по сравнению с ручным вводом, значения энтропии. Кроме того, пара «клиент-сервер», использующая RADIUS, всегда должна быть защищена одним и тем же «общим секретом».


ПРИМЕНЕНИЕ RADIUS

Соблюдение некоторых принципов при вводе RADIUS в эксплуатацию поможет свести различные риски к минимуму. При этом следует использовать алгоритм шифрования Triple DES. Такой метод описан также в документе RFC 3162. Путем шифрования всего сообщения RADIUS защищаются особо чувствительные его части — такие, как поле удостоверения запроса в сообщении запроса доступа — и атрибуты RADIUS (к примеру, пароль пользователя или атрибуты ключа МРРЕ). Тому, кто предпримет попытку проникновения в систему, понадобится сначала расшифровать защищенное с помощью ESP сообщение RADIUS, и лишь после этого он сможет анализировать его содержимое. Чтобы предотвратить атаки на сервер RADIUS извне, рекомендуется установить программное обеспечение для аутентификации с использованием сертификатов. Помимо этого, возможны и другие варианты защиты.

  • Используемый «общий секрет» должен иметь длину не менее 32 шестнадцатеричных символов или, соответственно, 22 символов клавиатуры;
  • Для всех сообщений с запросом доступа обязательны атрибуты удостоверения сообщения. Для клиента RADIUS это означает, что атрибут удостоверения сообщения нужен и для всех сообщений запроса доступа. Это правило требуется соблюдать также в случае сервера RADIUS;
  • С криптографической точки зрения непременным условием является качественное удостоверение запроса.

Нижеперечисленные советы помогут в реализации дополнительной защиты аутентификации:

Следует пользоваться ЕАР или схемами типа ЕАР с поддержкой сильных методов аутентификации. Хороший пример подобного метода — ЕАР-TLS. Он требует обмена сертификатами между клиентом, пытающимся получить доступ, и сервером RADIUS. Все сообщения ЕАР должны иметь атрибуты удостоверения сообщения для защиты сообщений запроса доступа.

Желательно выбирать методы аутентификации, рассчитанные на двустороннюю аутентификацию. При таком подходе противоположные конечные точки соединения аутентифицируют свои системы. Если с какой-либо стороны аутентификация пройдет неудачно, то в установлении соединения будет отказано. Примерами подобных методов служат ЕАР-TLS и MS-CHAPv2. Так, в случае ЕАР-TLS сервер RADIUS проводит проверку пользовательского сертификата клиента, пытающегося получить доступ, а клиент в свою очередь — сертификата сервера RADIUS.

Если аутентификация производится посредством РАР, то эту опцию следует отключить. При аутентификации с помощью однократных паролей или токенов происходит откат к PAP. Но поскольку IEEE 802.1x не поддерживает РАР, в подобных случаях чаще всего пользуются соединениями РРР.


РАСШИРЕННЫЙ ПРОТОКОЛ АУТЕНТИФИКАЦИИ

Расширенный протокол аутентификации (Extensible Authentication Protocol, EAP) изначально задумывался как дополнение к РРР для поддержки различных механизмов аутентификации доступа к сети. Протоколы аутентификации для РРР, например CHAP, MS-CHAP и MS-CHAPv2, определяют механизм аутентификации во время фазы установления соединения. На этом этапе необходимо применять согласованный протокол аутентификации, с целью «верификации» соединения. В данном случае речь идет о заранее определенной последовательности сообщений, причем они должны отсылаться в соответствии с заданной схемой, а точнее, в указанной очередности.

При использовании EAP в процессе установления соединения в рамках РРРспециальный механизм аутентификации не определяется. Лишь на этапе аутентификации участники взаимодействуют по специальной схеме аутентификации EAP, обозначаемой также как «схема типа EAP». ЕАР позволяет осуществлять обмен сообщениями между клиентом, запрашивающим доступ, и аутентифицирующим сервером (в его роли часто выступает сервер RADIUS). При этом обмен сообщениями может варьироваться с учетом особенностей различных соединений; он состоит собственно из запросов, в которых требуется предоставление информации об аутентификации, а также из соответствующих ответов. Длительность и конкретные детали сеанса аутентификации зависят от заданной схемы EAP.

В архитектурном плане ЕАР задумывался таким образом, чтобы аутентификацию можно было выполнять с помощью подключенных модулей с обеих сторон соединения: от клиента и от сервера. Если библиотечный файл ЕАР установить на обоих концах, то в любой момент можно применить новую схему аутентификации. Тем самым ЕАР предоставляет гибкую среду для внедрения безопасных методов аутентификации. ЕАР удобен при таких видах аутентификации, как токены (Generic Token Card), однократные пароли (One Time Password), запрос/ответ (MD5-Challenge) или защита на транспортном уровне (Transport Level Security). Кроме того, эта концепция открыта для применения лучших технологий аутентификации в будущем. Однако ЕАР используется не только вместе с РРР. Он, помимо всего, поддерживается на канальном уровне стандарта IEEE 802.

К примеру, службу RRAS операционной системы Windows 2000 можно настроить таким образом, что система с каждым сообщением запроса доступа станет отправлять атрибут удостоверение сообщения (Message-Authenticator). При этом в соответствующем диалоговом окне необходимо выбрать в свойствах опцию always use digital signatures («всегда использовать цифровую подпись»). Служба аутентификации в Internet (Internet Authentication Service, IAS) настраивается со стороны Windows 2000 так, чтобы при получении любого сообщения запроса доступа проверялось наличие атрибута Message-Authenticator. Администратор должен установить соответствующий флажок в свойствах клиента RADIUS, чтобы клиент постоянно пересылал в запросе атрибут подписи.

Если по каким-либо причинам такой вариант невозможен, в этом случае остается один выход: Windows 2000 обладает механизмом «учета и блокировки аутентификации». Благодаря ему клиент не может превысить заданное количество попыток аутентификации за установленное время. Если же это происходит, система сразу прервет с ним связь.

RADIUS — немного о Mikrotik, NPS и не только

Цель данной статьи — объяснить логику работы радиуса в примерах, избавить от боязни и иллюзии сложности использования.

Changelog

24.01.2021 — Добавлено про Wifi +Vlan
21.10.2021 — Добавлено про ipsec eap

Определение, назначение, общие сведения

RADIUS — это протокол, для авторизации, аутентификации и учёта (AAA).

Позволяет повысить безопасность сети и централизованно управлять доступами.

Сервер RADIUS может иметь свою базу данных с учетными данными (например файлы или mysql) или работать в паре с другим сервером, например Active Directory.

Кроме AAA позволяет передать некоторые дополнительные данные (настройки) клиенту прошедшему аутентификацию, в том числе vendor-specific attributes (VSA). У Mikrotik такие тоже есть, позже пройдемся по самым интересным.

Существуют много популярных приложений радиус сервера, самый популярные: freeRADIUS и Служба NPS (Network Policy Server) Windows Server. Более подробно мы рассмотрим второй вариант.

Компоненты кейса
  • Суппликант — устройство которое намерено пройти процедуру авторизации и аутентификации.
  • Аутентификатор — устройство к которому подключается суппликант, которое получает у суппликанта данные авторизации и которое проверяет их на RADIUS сервере. NB! Является клиентом для радиус-сервера.
  • RADIUS сервер (он же радиус сервер, он же сервер аутентификации).

Настройка

Установку роли описывать не буду, существует 100500 статей в картинках, например: тыц

  1. Добавление радиус клиента на радиус-сервере. Нам нужно заполнить «понятное имя», IP адрес и придумать пароль (а.к.а. «секрет»), который понадиобится при настройке аутентификатора (mikrotik в нашем случае)

Политики запросов на подключение и Стетевые политики очень похожи при настройке, и нужно понимать разницу между ними. Первые нужны для того что бы при определенных условиях определить сервер на котором будет проходить проверка аутентификации клиента (к примеру локально или на другом удаленном радиус сервере) а так же для некоторых манипуляций с атрибутами. Вторые же позволяют определить набор условий по которым возможно обозначить разрешить или отклонить запроос клиента на подключение.

Политики имеют порядок и обрабатываются по нему одна за другой. Если подключение не соответствует условиям политики, то проверяется следущая и так далее. К примеру, это поможет разделить правила обработки для проводных\беспроводных и впн клиентов.

  1. Добавление политики запросов на подключение
  2. Добавление сетевой политики
Некоторые типовые кейсы применения радиус сервера :
  1. централизованная аутентификация на устройствах поддерживающих aaa
  2. аутентификация для vpn (pptp\l2tp)
  3. аутентификация в wifi
  4. аутентификация устройств при подключении к порту rj45 — dot802.1x

Итак подробнее, + некоторые плюшки. Для всех наших пунктов нам нужно настроить радиус клиента в mikrotik

/radius add address=10.10.11.100 comment="PVE AD" secret=STRONG_SECRET_PASSWORD service=ppp,logi n,hotspot,wireless,dhcp,ipsec,dot1x timeout=600ms 

address — Адрес радиус сервера secret — пароль, который мы совсем недавно настраивали для радиус клиента service — сервисы в mikrotik, которые могут использовать радиус для аутентификации.

Отдельно стоит отметить пункт timeout=600ms , если вы используете радиус через медленные каналы с большими задержками, стоит увеличить это значение.

Теперь можно начинать настраивать интересные вещи.

1. настроим вход на микротик

/user aaa set accounting=yes default-group=read use-radius=yes 

Стоит уделить внимание параметру default-group он означает группу по умолчанию, в которая применится к пользователю.

Теперь настроим NPS:

Но… это слишком просто и не интересно, давайте преставим немного мифическую, но более интересную ситуацию. Предположим мы хотим разным уровням техподдержки, выдать разный уровень доступа на устройство. Или , предположим, в рамках одной компании разделить cетевиков c полным доступом и джунов, котоые могут только смотреть параметры.

Обратимся к Wiki mikrotik, мы можем заметить RADIUS атрибут, который позволяет определить доступы какой группы применятся к пользователю который аутентифицируется на устройстве через RADIUS. *Mikrotik-Group — Router local user group name (defines in /user group) for local users; HotSpot default profile for HotSpot users; PPP default profile name for PPP users. * воспользовавшись промт’ом мы понимаем что этот атрибут позволяет задать нам имя встроенной группы при авторизации , или задать имя профиля при аутентификации в сервисы vpn или hostspot. этот атрибут мы буем использовать и позже. что бы отделить мух от котлет при авторизации для впн мы будем использовать дополнительные условия, но это позже.

итак, как мы этого добьемся … мы можем создать в System -> users -> group две группы со специфичными параметрами доступа, а можем и воспользоваться уже существующими, к примеру full и read .

Но все это ничего без второй части, нам необходимо настроить NPS. Давайте создадим в остнастке Пользователи и компьютеры Две группы пользователей admins-network и admins-junior . И два пользователя net-junior и net-admin , добавим их в соответствующие группы.

Политику запроса на подключение мы уже создали, перейдем к сетевым политикам. в Оснастке NPS создадим две политики mikrotik-login-junior и mikrotik-admin-network , в условиях первой зададим :

А вот так будет выглядеть настройка необходимого нам атрибута, из которого микротик определит в какую группу поместить подключенного пользователя.

Сразу попробуем авторизоваться и видим что попали в нужную группу read

В методах проверки подлинности указываем :

Политика mikrotik-admin-network будет отличаться тем что в условиях выберем группу admins-network а значение отрибута MIKROTIK_GROUP зададим как full Результат ожидаемый, мы залогинились в микротик под полными правами:

/user active print detail Flags: R - RADIUS, M - by-romon 0 R when=jan/05/2021 10:36:52 name="net-admin" address=10.10.15.7 via=winbox group=full 1 R when=jan/05/2021 10:37:04 name="net-admin" address=10.10.15.7 via=telnet group=full 
Перейдем к впн, и к стразу более интересному сценарию.

Предположим мы хотим отделить админов, от остальных работников. Выдадим админам профиль с подсетью которая будет иметь доступ к management vlan и не только, и выдадим отстальным сотрудникам профиль с подсетью которая будет иметь ограниченый доступ только к 1c, RDP, etc.. . Предположим, мы используюем для впн l2tp\ipsec Для этого создадим в микротик два профиля в PPP -> profile

/ip pool add name=pool_l2tp_admin ranges=10.10.21.10-10.10.21.250 /ip pool add name=pool_l2tp_users ranges=10.10.22.10-10.10.22.250 /ppp profile add dns-server=10.10.21.1 local-address=10.10.21.1 name=l2tp-vpn-admin remote-address=pool_l2tp_admin use-compression=no use-encryption=yes /ppp profile add dns-server=10.10.22.1 local-address=10.10.22.1 name=l2tp-vpn-users remote-address=pool_l2tp_users use-compression=no use-encryption=yes

В настройки правил форейвола для ограничения доступа подсетей я пожалуй не буду углубляться, подразумевается что вы понимаете как из одной подсети запретить доступ к ресурсу и как разрешить. (с) предпологается, что вы немного сетевик. Касательно примера подсети 10.10.21.0/24 необходимо разрешить форвард в подсети серверов и management а подсети 10.10.22.0/24 необходимо разрешить только доступк корпоративным сервисам, но не к сетям управления.

Настроим NPS. В остнастке Пользователи и компьютеры создадим 2 группы пользователей vpn-admins и vpn-users , знакомого нам net-admin включим в 1ю группу, а net-buh во вторую. Политика запросов на подключение у нас будет использоваться та же. А политики сети созадим. В Условиях важно не только задать группу пользователей, но и тип порта NAS

Знакомым нам образом добавим атрибут указывающий какой профиль микротика использовать.

Методы проверки подлинности используем как и в прошлый раз. В настройках Сервера VPN рекомендуется указать точно такой же тип.

На вскидку полезными так же могут отказаться атрибуты : Mikrotik-Rate-Limit — для ограничения скорости vpn клиентов

Настроим тестовое поключение и увидим что получили IP из пула для сетевых администраторов.

Теперь настроим политику для обычных пользователей:

Результат — пользователь получил ip из нужной подсети

Wifi и Dot1x

Прежде чем перети к самому вкусному, хочется сделать выбор как мы будем проходить авторизацию, можно выбрать по логину и паролю, компьютеру, использовать mac адрес как логин и пароль.. и наконец пойти самым сложным интересным путем, использовать сертификаты. В качестве предварительной подготовки нам необходимо:

  • настроить службу центра сертификации Windows тыц, актуально и для следующего пункта
  • настроить GPO для распространения CA сертификата домена тыц
  • GPO автоматического получения сертификата компьютера docs.microsoft
  • GPO включение службы dot1X (проводная автонастройка) и создать Политики проводных сетей (802.3) для выбора способа проверки подлинности тыц
  • GPO Автоматическое подключение к Wifi до логина пользователя тыц

Данные пункты не маленькие что бы включать их в эту статью, но достаточно освещены в статьях интернета.

wifi

Настройку WiFi каждый настраивает как ему удобно. Я к примеру, предпочитаю CapsMan, даже если это будет единственная AP в сети. В любом случае нас интересует только Security Profile/Security Cfg.

Создадим политику сети: В условиях выберем Тип порта NAS = Беспроводная — IEEE 802.11

А в методах проверки подлинности следующее.

Если вы используете CapsMan + Bridge Vlan Filtering и хотите что бы при подключении пользователи попадали в указанный вами VLAN — нужно указать атрибут: Mikrotik-Wireless-VLANID.

Как понять что все получилось или что то идет не так )? — все просто в первую очередь идем в логи. Видим событие с подробной информацией кто куда и когда ходил и согласно какой политике получил разрешение или отказ в доступе.

Какие радиус атрибуты могут быть нам полезны:

  • Framed-Pool — можем для отдельных групп пользователей использовать свой ip пул и выполнять какие то манипуляции на основе этого в форейволе
  • Filter-Id — применять какое то правило форейвола сразу к клиенту
  • Mikrotik-Wireless-VLANID — указать в какой vlan должен попасть клиент (Возможно, однажды, по заявкам пользователей я дополню статью примером с ипользованием vlan в wifi) …
  • устанавливать лимиты по обьему или/и скорости трафика
  • и многие другие параметры из вики, либо их комбинации с условиями сетевой политики, смотря сколько у вас фантазии 🙂

dot1x

Зачем нужен dot1X и как его настроить.. очень много интересных слов можно было бы тут написать, но все сказано до нас. Например на канале одного прекрасного тренера или wiki

Половина смысла с саркальной точки зрения в dot1x в том, что в случае успешной проверки подлинности наше устройство попадет в влан указанный нами в микротике или в влан который мы поличим в качестве атрибута у радиуса. Если проверка подлинности пройдет с отказом или ответ не будет получен от радиуса (например в случае его недоступности), то порт перейдет в изолироованный режим (будет заблокирован любой трафик на порту) или в случае если указан Reject VLAN ID то попадет в влан, для которого мы настроили(я надеюсь все таки настроили) максимально безопасные правила форейвола для чужеродных устройств .

Начнем с микротика:

Настроим политики сети: В условиях необходимо отобрать проводные клиенты

В настройках атрибутами выдадим рабочий влан

К примеру вот так выглядит отказ в авторизации:

А вот так успешное подключение:

IPSEC

С недавнего времени стало популярно настраивать vpn через ipsec ikev2, но многих пугает морока с клиентскими сертификатами. В этом плане использовать учетные данные из AD гораздо удобнее.

Для начала включим в настроках добавленного радиус клиента что он будет использоваться для ipsec

Дефолтные конфиги в ipsec не принято трогать. поэтому будем создавать свои.

Создадим «группу конфигов»

/ip ipsec policy group add name=ipsec

Настроим Profile (фаза 1)

/ip ipsec profile add dh-group=modp1024 enc-algorithm=aes-192,3des name=ipsec

Создадим пир для входящих подключений

/ip ipsec peer add exchange-mode=ike2 name=ipsec passive=yes profile=ipsec send-initial-contact=no

Создадим настройки proposals (фаза 2)

/ip ipsec proposal add name=ipsec

Добавим пулл ip адресов которые будут выдаваться клиентам

/ip pool add name=pool1 ranges=10.20.0.10-10.20.0.250

Добавим Mod config, из которого клиенты получают префиксы подсетей за впн и dns

/ip ipsec mode-config add address-pool=pool1 name=ipsec split-include=0.0.0.0/0,10.20.0.0/16

Создадим шаблонную политику шифрования трафика

/ip ipsec policy add group=ipsec proposal=ipsec template=yes

Настроим аутентификацию vpn клиентов
Важный момент. нам все таки прийдется использовать сертификат.
Данный сертификат используется только для шифрования трафика между клиентом и впн сервером, и его нужно указать обязательно иначе будет появляться ошибка EAP neeeds certificate if EAP-only is not used .

Если планируете подключаться из windows машин в домене, то можете импортировать сертификат из своего CA и разлить его политикой на ноутбуки\компьютеры.
Если нет своего CA то можно сгенерировать сертификат на микротике. но тогда прийдется опять таки его импортировать на клиентах вручную или через GPO.
И на мой взгляд самый удобный способ, воспользоваться сертификатом letsecrypt, кстати в ros7 есть команда для автоматического получения сертификата.
Или приобрести коммерческий сертификат. У меня в примере Letsencrypt, обратите внимание что необходимо добавить так же все промежуточные сертификаты.

/ip ipsec identity add auth-method=eap-radius certificate=lefull,lefull_1,lefull_2 generate-policy=port-strict mode-config=ipsec peer=ipsec policy-template-group=ipsec

Добавляем политику на NPS сервере

В методах проверки подлинности разрешаем аутентификацию по паролю используюя ms-chap v2

После этого можно подключаться клиентом, все должно работать )
Если желательно расписать как настраивать клиента на mikrotik дайте знать )

Диагностика

Не всегда наши настройки сразу работают так как надо, иногда что то идет не так, и очень хочется понять что именно. Для того что бы понять в чем причина у нас есть :

  • логи mikrotik Идем в system logging add topics=radius,debug action=memory disabled=no и пробуем что то делать, в log print появятся записи связанные с радиусом. — логи Службы
  • политики сети и доступа я уже приводил пример, еще раз — искать здесь, и читать внимательно сообщения
  • возможны проблемы из за windows брандмауера починить можно
Get-NetFirewallRule -DisplayGroup "Сервер политики сети" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any 

или для англоязычной версии:

Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any 
  • radclient из пакета freeradius-utils. Позволяет из командной строки проверить некоторые типы авторизации, к примеру подключение к vpn
echo "User-Name = USER,User-Password=PASSWORD,NAS-Port-Type=Virtual" | radclient -s 10.10.11.100:1812 auth SHARE_NPS_SECRET -x
Sent Access-Request Id 177 from 0.0.0.0:42354 to 10.10.11.100:1812 length 56 User-Name = "USER" User-Password = "PASSWORD" NAS-Port-Type = Virtual Framed-Protocol = PPP Cleartext-Password = "PASSWORD" Received Access-Accept Id 177 from 10.10.11.100:1812 to 10.10.15.7:42354 length 94 Mikrotik-Group = "pptp-nps" Framed-Protocol = PPP Service-Type = Framed-User summary: Accepted : 1 Rejected : 0 Lost : 0 Passed filter : 1 Failed filter : 0 

Выводы

RADIUS в сетевой среде очень полезен в плане безопасности и удобен в плане централизованного управления. Настраивать не так уж и сложно, главное читать, понимать документацию и логи.

Если какой то из пунктов непонятен, пишите. попробую показать или помочь разобраться.

Если в статье нашли ошибки, неточности или знаете как сделать лучше тоже пишите.

Благодарности:

Спасибо @aslancherkesov за злого редактора и свежий взгляд на буквы.

RADIUS сервер

RADIUS (Remote Authentication in Dial-In User Service) — протокол для реализации протокола AAA (аутентификации (Authentication), авторизации (Authorization) и сбора сведений об использованных ресурсах (Accounting)), разработанный для передачи сведений между сервером и клиентским оборудованием. Используется, например, при аутентификации пользователей WI-FI, Раздел VPN: Что это такое VPN, в прошлом, dialup-подключений, и других подобных случаях. Описан в стандартах RFC 2865 и RFC 2866.

Протокол RADIUS согласно стандарту:

Базируется на UDP протоколе.

iptables -A INPUT -p udp -m multiport --dport 1812,1813 -j ACCEPT

Без состояний (stateless)

Предоставляет более 50 пар атрибут/значение с возможностью создавать специфичные для производителя пары

Существует несколько реализация RADIUS серверов, ниже некоторые из них

Internet Authentication Service (IAS) встроенный в Windows Server.
FreeRADIUS. Сборка под Windows: FreeRADIUS.net

Инсталляция FreeRADIUS

Для чего нужен radius сервер

Наз­ва­ние RA­DI­US яв­ля­ет­ся абб­ре­ви­ату­рой от Re­mote Aut­henti­cati­on Di­al In User Ser­vi­ce и предс­тав­ля­ет со­бой се­тевой про­токол, обес­пе­чива­ющий цент­ра­лизо­ван­ную Аутен­ти­фика­цию (Aut­henti­cati­on), Ав­то­риза­цию (Aut­ho­riza­ti­on) и Учет ис­поль­зу­емых се­тевых ре­сур­сов (Ac­co­un­ting). В анг­ло­языч­ной ли­тера­туре для этих трех функ­ций (Aut­henti­cati­on, Aut­ho­riza­ti­on, Ac­co­un­ting) ис­поль­зу­ет­ся абб­ре­ви­ату­ра ААА.

Под Аутен­ти­фика­ци­ей по­нима­ет­ся про­цесс, поз­во­ля­ющий иден­ти­фици­ровать поль­зо­вате­ля по его дан­ным, нап­ри­мер, по ло­гину (имя поль­зо­вате­ля, но­мер те­лефо­на и т. д.) и па­ролю.

Ав­то­риза­ция — про­цесс, в те­чение ко­торо­го оп­ре­деля­ют­ся пол­но­мочия иден­ти­фици­рован­но­го поль­зо­вате­ля на дос­туп к оп­ре­делён­ным се­тевым ре­сур­сам.

Тер­мин Учет ис­поль­зо­ван­ных се­тевых ре­сур­сов уже сам по се­бе дос­та­точ­но ин­форма­тивен. Пер­вичны­ми дан­ны­ми, ко­торые пе­реда­ют­ся по про­токо­лу RA­DI­US, яв­ля­ют­ся объемы вхо­дяще­го и ис­хо­дяще­го тра­фиков при пе­реда­че дан­ных, и дли­тель­ность раз­го­вора и наб­ранный но­мер при ис­поль­зо­вании IP те­лефо­нии. Кро­ме оп­ре­делен­ных в про­токо­ле стан­дарт­ных ат­ри­бутов (па­рамет­ров), про­токол пре­дус­матри­ва­ет воз­можность ис­поль­зо­вания про­из­во­дите­лем обо­рудо­вания (вен­до­ром) собс­твен­ных ат­ри­бутов. В анг­ло­языч­ной ли­тера­туре они на­зыва­ют­ся Ven­dor Spe­cific Att­ri­butes или VSA.

Про­токол RA­DI­US был раз­ра­ботан ком­па­ни­ей Li­ving­ston En­terp­ri­ses (конк­рет­но Кар­лом Риг­ней/Carl Rig­ney) для уда­лен­но­го ком­му­тиру­емо­го дос­ту­па че­рез се­тевые сер­ве­ра дос­ту­па (Net­work Ac­cess Ser­ver — NAS) этой ком­па­нии се­рии Port­Mas­ter к се­ти in­ternet. Поз­же, в 1997, про­токол RA­DI­US был опуб­ли­кован как RFC 2058 иRFC 2059. Те­кущие вер­сии RFC 2865 (Re­mote Aut­henti­cati­on Di­al In User Ser­vi­ce (RA­DI­US)) и RFC 2866 (RA­DI­US Ac­co­un­ting). Иног­да вмес­то по­нятия «се­тевой сер­вер дос­ту­па» ис­поль­зу­ет­ся дру­гой: «уда­лен­ный сер­вер дос­ту­па» (Re­mote Ac­cess Ser­ver – RAS).

В нас­то­ящее вре­мя про­токол RA­DI­US ис­поль­зу­ет­ся для дос­ту­па к вир­ту­аль­ным част­ным се­тям (VPN), точ­кам бесп­ро­вод­но­го (Wi-Fi) дос­ту­па, Et­hernet ком­му­тато­рам, DSL и дру­гим ти­пам се­тево­го дос­ту­па. Бла­года­ря отк­ры­тос­ти, прос­то­те внед­ре­ния, пос­то­ян­но­му усо­вер­шенс­тво­ванию, про­токол RA­DI­US сей­час яв­ля­ет­ся фак­ти­чес­ки стан­дартом для уда­лен­ной аутен­ти­фика­ции.

Аутен­ти­фика­ция и ав­то­риза­ция

Для вы­яс­не­ния ра­боты RA­DI­US про­токо­ла расс­мот­рим ри­сунок, при­веден­ный ни­же.

Но­ут­бу­ки и IP те­лефон, предс­тав­ля­ют уст­рой­ства поль­зо­вате­ля, с ко­торых не­об­хо­димо вы­пол­нить аутен­ти­фика­ции и ав­то­риза­ции на се­тевых сер­ве­рах дос­ту­па (NAS):

  • точ­ке Wi-Fi дос­ту­па,
  • марш­ру­тиза­торе,
  • VPN сер­ве­ре и
  • IP АТС.

На ри­сун­ке по­каза­ны не все воз­можные ва­ри­ан­ты NAS. Су­щест­ву­ют и дру­гие се­тевые уст­рой­ства дос­ту­па.

RA­DI­US про­токол ре­али­зовы­ва­ет­ся в ви­де ин­терфей­са меж­ду NAS, ко­торый выс­ту­па­ет как RA­DI­US кли­ент, и RA­DI­US сер­ве­ром – прог­рамм­ным обес­пе­чени­ем, ко­торое мо­жет быть ус­та­нов­ле­но на компьюте­ре (сер­ве­ре) или ка­ком-то спе­ци­али­зиро­ван­ном уст­рой­стве. Та­ким об­ра­зом, RA­DI­US сер­вер, как пра­вило, не вза­имо­дей­ству­ет нап­ря­мую с уст­рой­ством поль­зо­вате­ля, а толь­ко че­рез се­тевой сер­вер дос­ту­па.

Поль­зо­ватель по­сыла­ет зап­рос на се­тевой сер­вер дос­ту­па для по­луче­ния дос­ту­па к оп­ре­делен­но­му се­тево­му ре­сур­су, ис­поль­зуя сер­ти­фикат дос­ту­па. Сер­ти­фикат по­сыла­ет­ся на се­тевой сер­вер дос­ту­па че­рез се­тевой про­токол ка­наль­но­го уров­ня (Link La­yer), нап­ри­мер, Po­int-to-Po­int Pro­tocol (PPP) в слу­чае вы­пол­не­ния ком­му­тиру­емо­го дос­ту­па, Di­gital Subs­cri­ber Li­ne (DLS) – в слу­чае ис­поль­зо­вания со­от­ветс­тву­ющих мо­демов и т.п. NAS пос­ле это­го, в свою оче­редь, по­сыла­ет со­об­ще­ние зап­ро­са дос­ту­па на RA­DI­US сер­вер, так на­зыва­емый RA­DI­US Ac­cess Re­qu­est. Этот зап­рос вклю­ча­ет сер­ти­фика­ты дос­ту­па, ко­торые обыч­но предс­тав­ле­ны в ви­де име­ни поль­зо­вате­ля и па­роля или сер­ти­фика­та бе­зопас­ности, по­лучен­ных от поль­зо­вате­ля. Кро­ме это­го зап­рос мо­жет со­дер­жать до­пол­ни­тель­ные па­рамет­ры, та­кие как се­тевой ад­рес уст­рой­ства поль­зо­вате­ля, его те­лефон­ный но­мер, ин­форма­цию о фи­зичес­ком ад­ре­се, с ко­торо­го поль­зо­ватель вза­имо­дей­ству­ет с NAS.

RA­DI­US сер­вер про­веря­ет эту ин­форма­цию на кор­рект­ность, ис­поль­зуя та­кие схе­мы аутен­ти­фика­ции, как PAP, CHAP, EAP и т.п.
Крат­ко опи­шем эти про­токо­лы.
PAP (Pass­word Aut­henti­cati­on Pro­tocol) (RFC1334)– прос­той аутен­ти­фика­ци­он­ный про­токол, ко­торый ис­поль­зу­ет­ся для аутен­ти­фика­ции поль­зо­вате­ля по от­но­шению к се­тево­му сер­ве­ру дос­ту­па (NAS). РАР ис­поль­зу­ет­ся РРР про­токо­лом. Прак­ти­чес­ки все сер­ве­ра дос­ту­па под­держи­ва­ют РАР. РАР пе­реда­ет не­зашиф­ро­ван­ный па­роль че­рез сеть и, сле­дова­тель­но, яв­ля­ет­ся не­защи­щен­ным про­токо­лом. По­это­му РАР, обыч­но, ис­поль­зу­ет­ся в том слу­чае, ког­да сер­вер не под­держи­ва­ет за­щищен­ные про­токо­лы, та­кие как СНАР, ЕАР и т.п.

CHAP (англ. Chal­lenge Hand­sha­ke Aut­henti­cati­on Pro­tocol) (RFC 1994) — ши­роко расп­рос­тра­нён­ный ал­го­ритм про­вер­ки под­линнос­ти, пре­дус­матри­ва­ющий пе­реда­чу не са­мого па­роля поль­зо­вате­ля, а кос­венных све­дений о нём. При ис­поль­зо­вании CHAP сер­вер уда­лен­но­го дос­ту­па отп­рав­ля­ет кли­ен­ту стро­ку зап­ро­са. На ос­но­ве этой стро­ки и па­роля поль­зо­вате­ля кли­ент вы­чис­ля­ет хеш-код MD5 (Mes­sa­ge Di­gest-5) и пе­реда­ет его сер­ве­ру. Хеш-функ­ция яв­ля­ет­ся ал­го­рит­мом од­носто­рон­не­го (не­об­ра­тимо­го) шиф­ро­вания, пос­коль­ку зна­чение хеш-функ­ции для бло­ка дан­ных вы­чис­лить лег­ко, а оп­ре­делить ис­ходный блок по хеш-ко­ду с ма­тема­тичес­кой точ­ки зре­ния не­воз­можно за при­ем­ле­мое вре­мя. (По хе­широ­ванию су­щест­ву­ет мно­го ли­тера­туры, нап­ри­мер, мож­но про­честь: Хе­широ­вание). Сер­вер, ко­торо­му дос­ту­пен па­роль поль­зо­вате­ля, вы­пол­ня­ет те же са­мые вы­чис­ле­ния и срав­ни­ва­ет ре­зуль­тат с хеш-ко­дом, по­лучен­ным от кли­ен­та. В слу­чае сов­па­дения учёт­ные дан­ные кли­ен­та уда­лён­но­го дос­ту­па счи­та­ют­ся под­линны­ми.
MD5 (Mes­sa­ge-Di­gest al­go­rithm 5) (RFC 1321) — ши­роко ис­поль­зу­емая крип­тогра­фичес­кая функ­ция с 128 би­товым хе­шем. Най­ден ряд уяз­ви­мос­тей в ал­го­рит­ме MD5, в си­лу че­го в США де­пар­та­мент U. S. De­part­ment of Ho­meland Se­curi­ty не ре­комен­ду­ет ис­поль­зо­вание MD5 в бу­дущем, и для боль­шинс­тва пра­витель­ствен­ных при­ложе­ний c 2010 го­да США тре­бу­ет­ся пе­рей­ти на се­мей­ство ал­го­рит­ма SHA-2.

Про­токол EAP (Ex­tensib­le Aut­henti­cati­on Pro­tocol) (RFC 3748) поз­во­ля­ет про­верять под­линность при подк­лю­чени­ях уда­лен­но­го дос­ту­па с по­мощью раз­личных ме­ханиз­мов про­вер­ки под­линнос­ти. Точ­ная схе­ма про­вер­ки под­линнос­ти сог­ла­совы­ва­ет­ся кли­ен­том уда­лен­но­го дос­ту­па и сер­ве­ром, вы­пол­ня­ющим про­вер­ку под­линнос­ти (им мо­жет быть сер­вер уда­лен­но­го дос­ту­па или RA­DI­US сер­вер). По умол­ча­нию в марш­ру­тиза­цию и уда­лен­ный дос­туп вклю­чена под­держ­ка про­токо­лов EAP-TLS и MD5-Chal­lenge (MD5-за­дача). Подк­лю­чение дру­гих мо­дулей ЕАР к сер­ве­ру, ис­поль­зу­юще­му марш­ру­тиза­цию и уда­лен­ный дос­туп, обес­пе­чива­ет под­держ­ку дру­гих ме­тодов ЕАР.
Про­токол EAP поз­во­ля­ет вес­ти сво­бод­ный ди­алог меж­ду кли­ен­том уда­лен­но­го дос­ту­па и сис­те­мой про­вер­ки под­линнос­ти. Та­кой ди­алог сос­то­ит из зап­ро­сов сис­те­мы про­вер­ки под­линнос­ти на не­об­хо­димую ей ин­форма­цию и от­ве­тов кли­ен­та уда­лен­но­го дос­ту­па. Нап­ри­мер, ког­да про­токол EAP ис­поль­зу­ет­ся с ге­нера­тора­ми ко­дов дос­ту­па, сер­вер, вы­пол­ня­ющий про­вер­ку под­линнос­ти, мо­жет от­дель­но зап­ра­шивать у кли­ен­та уда­лен­но­го дос­ту­па имя поль­зо­вате­ля, иден­ти­фика­тор и код дос­ту­па. Пос­ле от­ве­та на каж­дый та­кой зап­рос кли­ент уда­лен­но­го дос­ту­па про­ходит оп­ре­делен­ный уро­вень про­вер­ки под­линнос­ти. Ког­да на все зап­ро­сы бу­дут по­луче­ны удов­летво­ритель­ные от­ве­ты, про­вер­ка под­линнос­ти кли­ен­та уда­лен­но­го дос­ту­па ус­пешно за­вер­ша­ет­ся.
Схе­мы про­вер­ки под­линнос­ти, ис­поль­зу­ющие про­токол EAP, на­зыва­ют­ся ти­пами EAP. Для ус­пешной про­вер­ки под­линнос­ти кли­ент уда­лен­но­го дос­ту­па и сер­вер, вы­пол­ня­ющий про­вер­ку под­линнос­ти, долж­ны под­держи­вать один и тот же тип EAP.

Те­перь вер­немся к RA­DI­US сер­ве­ру, ко­торый про­веря­ет ин­форма­цию, по­лучен­ную от NAS. Сер­вер про­веря­ет иден­тичность поль­зо­вате­ля, а так­же кор­рект­ность до­пол­ни­тель­ной ин­форма­ции, ко­торая мо­жет со­дер­жать­ся в зап­ро­се: се­тевой ад­рес уст­рой­ства поль­зо­вате­ля, те­лефон­ный но­мер, сос­то­яние сче­та, его при­виле­гии при дос­ту­пе к зап­ра­шива­емо­му се­тево­му ре­сур­су.
По ре­зуль­та­там про­вер­ки RA­DI­US сер­вер по­сыла­ет NAS один из трех ти­пов отк­ли­ков:

  • Ac­cess-Re­ject по­казы­ва­ет, что дан­ный поль­зо­ватель­ский зап­рос не­вер­ный. При же­лании сер­вер мо­жет вклю­чить текс­то­вое со­об­ще­ние в Ac­cess-Re­ject, ко­торое мо­жет быть пе­реда­но кли­ен­том поль­зо­вате­лю. Ни­какие дру­гие ат­ри­буты (кро­ме Pro­xy-Sta­te) не раз­ре­шены в Ac­cess-Re­ject.
  • Ac­cess-Chal­lenge. Зап­рос до­пол­ни­тель­ной ин­форма­ции от поль­зо­вате­ля, нап­ри­мер, вто­рой па­роль, пин-код, но­мер кар­ты и т.п. Этот отк­лик так­же ис­поль­зу­ет­ся для бо­лее пол­но­го аутен­ти­фика­ци­он­но­го ди­ало­га, где за­щит­ный тун­нель вы­пол­ня­ет­ся меж­ду уст­рой­ством поль­зо­вате­ля и RA­DI­US сер­ве­ром, так что сер­ти­фика­ты дос­ту­па скры­ва­ют­ся от NAS.
  • Ac­cess Ac­cept. Поль­зо­вате­лю раз­ре­шен дос­туп. Пос­коль­ку поль­зо­ватель аутен­ти­фици­рован, то RA­DI­US сер­вер про­веря­ет ав­то­риза­цию на ис­поль­зо­вание зап­ро­шен­ных поль­зо­вате­лем ре­сур­сов. Нап­ри­мер, поль­зо­вате­лю мо­жет быть дос­туп че­рез бесп­ро­вод­ную сеть, но зап­ре­щен дос­туп к VPN се­ти.

Та­ким об­ра­зом, ра­бота RA­DI­US про­токо­ла мо­жет в об­щем слу­чае быть предс­тав­ле­на, как по­каза­но на таб­ли­це ни­же.

Сер­вер дос­ту­па Нап­равле­ние RA­DI­US сер­вер
Ac­cess-Re­qu­est: NAS-Iden­ti­fi­er, NAS-Port, User-Na­me, User-Pass­word (па­роль мо­жет быть про­иг­но­риро­ван)
Ac­cess-Chal­lenge: Sta­te (0 или 1) и Rep­ly-Mes­sa­ge (Нап­ри­мер: «Chal­lenge 12345678, en­ter your res­ponse at the prompt»)
Ac­cess-Re­qu­est: с но­вым ID, NAS-Iden­ti­fi­er, NAS-Port, User-Na­me, User-Pass­word (па­роль крип­тогра­фиру­ет­ся). Sta­te (тот же, что и в Ac­cess-Chal­lenge)
Ac­cess-Chal­lenge: Sta­te (0 или 1) и Rep­ly-Mes­sa­ge (Нап­ри­мер: «Chal­lenge 12345678, en­ter your res­ponse at the prompt»)

Учет ис­поль­зо­ван­ных се­тевых ре­сур­сов

Пос­ле то­го, как NAS раз­ре­шил поль­зо­вате­лю дос­туп, NAS по­сыла­ет RA­DI­US сер­ве­ру со­об­ще­ние о на­чале уче­та се­тево­го дос­ту­па – па­кет Ac­co­un­ting Re­qu­est, ко­торый со­дер­жит ат­ри­бут Acct-Sta­tus-Ty­pe со зна­чени­ем «start». Это со­об­ще­ние обыч­но со­дер­жит иден­ти­фика­тор поль­зо­вате­ля, его се­тевой ад­рес, порт подк­лю­чения и уни­каль­ный иден­ти­фика­тор сес­сии.

NAS мо­жет пе­ри­оди­чес­ки по­сылать RA­DI­US сер­ве­ру па­кет Ac­co­un­ting Re­qu­est, со­дер­жа­щий ат­ри­бут Acct-Sta­tus-Ty­pe со зна­чени­ем «in­te­rim-up­da­te». По­доб­ная ин­форма­ция пред­назна­чена для об­новле­ния ста­туса поль­зо­вате­ля во вре­мя ак­тивной сес­сии. Обыч­но по­доб­ная ин­форма­ция соп­ро­вож­да­ет­ся ин­форма­ци­ей о те­кущей да­те и про­дол­жи­тель­нос­ти сес­сии.

Пос­ле прек­ра­щения поль­зо­вате­лем дос­ту­па к се­ти NAS по­сыла­ет RA­DI­US сер­ве­ру пос­ледний па­кет Ac­co­un­ting Re­qu­est, ко­торый со­дер­жит ат­ри­бут Acct-Sta­tus-Ty­peсо зна­чени­ем «stop». Так­же пе­реда­ет­ся ин­форма­ция о вре­мени сес­сии, ко­личест­ве пе­редан­ных па­кетов, ко­личест­ве пе­редан­ных бай­тов, при­чине окон­ча­ния со­еди­нения и дру­гая ин­форма­ция, свя­зан­ная с се­тевым дос­ту­пом.

Обыч­но, RA­DI­US кли­ент по­сыла­ет па­кет Ac­co­un­ting Re­qu­est с воз­можным пов­то­ром че­рез не­кото­рый ин­тервал вре­мени, по­ка не по­лучит в от­вет от RA­DI­US сер­ве­ра подт­вер­жде­ние при­ема – па­кет Ac­co­un­ting-Res­ponse.

Ос­новная цель этих дан­ных – ис­поль­зо­вание их для выс­тавле­ния сче­тов, од­на­ко, они мо­гут ис­поль­зо­вать­ся так­же для по­луче­ния ста­тис­ти­ки по пре­дос­тавля­емым ус­лу­гам и для об­ще­го се­тево­го мо­нито­рин­га.

Обыч­но, для аутен­ти­фика­ции и ав­то­риза­ции RA­DI­US сер­ве­ром ис­поль­зу­ет­ся 1812 UDP порт, а для уче­та ус­луг — 1813 UDP порт. Од­на­ко, в ря­де слу­ча­ев мо­гут ис­поль­зо­вать­ся и дру­гие пор­ты. В част­нос­ти, уст­рой­ства Cis­co Sys­tems по умол­ча­нию ис­поль­зу­ют 1645 и 1646 пор­ты со­от­ветс­твен­но.

В нас­то­ящее вре­мя су­щест­ву­ет це­лый ряд ре­али­заций RA­DI­US сер­ве­ров раз­личны­ми фир­ма­ми. Мы ре­комен­ду­ем ис­поль­зо­вать Soft­PI RA­DI­US сер­вер.

Новости

  • Импорт кодов и тарифов в Tariscope
  • Изменена стоимость поддержки Tariscope 3.5.х
  • Tariscope та Active Directory
  • С Рождеством Христовым и Новым Годом!
  • Новая версия Tariscope 4.6.3

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *