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

Клиенты RADIUS

Сервер сетевого доступа (NAS) — это устройство, которое предоставляет некоторый уровень доступа к более крупной сети. NAS, использующий инфраструктуру RADIUS, также является клиентом RADIUS, отправляя запросы на подключение и учетные сообщения на сервер RADIUS для проверки подлинности, авторизации и учета.

Клиентские компьютеры, такие как ноутбуки и другие компьютеры под управлением клиентских операционных систем, не являются клиентами RADIUS. Клиенты RADIUS — это серверы доступа к сети , такие как беспроводные точки доступа, коммутаторы проверки подлинности 802.1X, серверы виртуальной частной сети (VPN) и серверы с телефонным подключением, так как они используют протокол RADIUS для взаимодействия с серверами RADIUS, такими как серверы NPS.

Чтобы развернуть NPS в качестве сервера RADIUS или прокси-сервера RADIUS, необходимо настроить клиенты RADIUS в NPS.

Примеры клиента RADIUS

Примерами серверов доступа к сети являются:

• Серверы сетевого доступа, обеспечивающие подключение удаленного доступа к сети организации или Интернету. Примером является компьютер под управлением операционной системы Windows Server 2016 и службы удаленного доступа, которая предоставляет либо традиционные службы удаленного доступа по телефону или виртуальной частной сети (VPN) в интрасети организации.
• Точки беспроводного доступа, обеспечивающие доступ физического уровня к сети организации с помощью беспроводных технологий передачи и приема.
• Коммутаторы, обеспечивающие доступ физического уровня к сети организации, используя традиционные технологии локальной сети, такие как Ethernet.
• Прокси-серверы RADIUS, которые перенаправляют запросы на подключение к серверам RADIUS, которые являются членами удаленной группы серверов RADIUS, настроенной на прокси-сервере RADIUS.

Сообщения RADIUS Access-Request

Клиенты RADIUS либо создают сообщения RADIUS Access-Request и перенаправляют их на прокси-сервер RADIUS или СЕРВЕР RADIUS, либо перенаправляют сообщения access-request на сервер RADIUS, полученный от другого клиента RADIUS, но не создали себя.

Клиенты RADIUS не обрабатывают сообщения Access-Request, выполняя проверку подлинности, авторизацию и учет. Только серверы RADIUS выполняют эти функции.

Однако NPS можно настроить как прокси-сервер RADIUS, так и сервер RADIUS одновременно, чтобы он обрабатывал некоторые сообщения Access-Request и пересылал другие сообщения.

NPS в качестве клиента RADIUS

NPS выступает в качестве клиента RADIUS при настройке его в качестве прокси-сервера RADIUS для пересылки сообщений Access-Request на другие серверы RADIUS для обработки. При использовании NPS в качестве прокси-сервера RADIUS необходимо выполнить следующие общие действия по настройке:

1. Серверы доступа к сети, такие как точки беспроводного доступа и VPN-серверы, настраиваются с IP-адресом прокси-сервера NPS в качестве назначенного сервера RADIUS или проверки подлинности сервера. Это позволяет серверам доступа к сети, которые создают сообщения Access-Request на основе информации, полученной от клиентов доступа, для пересылки сообщений в прокси-сервер NPS.
2. Прокси-сервер NPS настраивается путем добавления каждого сервера доступа к сети в качестве клиента RADIUS. Этот шаг конфигурации позволяет прокси-серверу NPS получать сообщения от серверов доступа к сети и взаимодействовать с ними во время проверки подлинности. Кроме того, политики запросов на подключение на прокси-сервере NPS настраиваются для указания сообщений Access-Request для пересылки на один или несколько серверов RADIUS. Эти политики также настраиваются с удаленной группой серверов RADIUS, которая сообщает NPS, где отправлять сообщения, полученные от серверов доступа к сети.
3. NPS или другие серверы RADIUS, которые являются членами удаленной группы серверов RADIUS на прокси-сервере NPS, настроены для получения сообщений от прокси-сервера NPS. Это достигается путем настройки прокси-сервера NPS в качестве клиента RADIUS.

Свойства клиента RADIUS

При добавлении клиента RADIUS в конфигурацию NPS через консоль NPS или с помощью команд netsh для команд NPS или Windows PowerShell вы настраиваете NPS для получения сообщений RADIUS Access-Request от сервера доступа к сети или прокси-сервера RADIUS.

При настройке клиента RADIUS в NPS можно указать следующие свойства:

имя клиента;

Понятное имя клиента RADIUS, что упрощает идентификацию при использовании оснастки NPS или команд netsh для NPS.

IP-адрес

Адрес протокола Интернета версии 4 (IPv4) или DNS-имя клиента RADIUS.

Клиент-поставщик

Поставщик клиента RADIUS. В противном случае можно использовать стандартное значение RADIUS для client-Vendor.

Общий секрет

Текстовая строка, используемая в качестве пароля между клиентами RADIUS, серверами RADIUS и прокси-серверами RADIUS. При использовании атрибута Message Authenticator общий секрет также используется в качестве ключа для шифрования сообщений RADIUS. Эта строка должна быть настроена на клиенте RADIUS и в оснастке NPS.

Атрибут Authenticator message

Описано в RFC 2869, «Расширения RADIUS», хэш хэша сообщения 5 (MD5) всего сообщения RADIUS. Если присутствует атрибут RADIUS Message Authenticator, он проверяется. Если проверка завершается ошибкой, сообщение RADIUS не карта. Если для параметров клиента требуется атрибут Authenticator Message Authenticator и он отсутствует, сообщение RADIUS отключено карта. Рекомендуется использовать атрибут Message Authenticator.

Атрибут Message Authenticator является обязательным и включен по умолчанию при использовании проверки подлинности EAP.

Дополнительные сведения о NPS см. в разделе «Сервер политики сети» (NPS).

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 сер­вер.

Новости

• Alcatel-Lucent OXE. Получение CDR через TCP в Tariscope
• Импорт кодов и тарифов в Tariscope
• Изменена стоимость поддержки Tariscope 3.5.х
• Tariscope та Active Directory
• С Рождеством Христовым и Новым Годом!

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

Что такое RADIUS сервер

(IT инженерам не читать! А то уши в трубочку завернутся )

Насколько я понял, после бесконечных попыток пояснить мне, тупому Славику, любимыми: Гуглом и Яндексом , что ЭТО есть такое, я пришел к выводу, что RADIUS сервер (Remote Authentication in Dial-In User Service) — это есть программа работающая с некой базой данных пользователей, где, в этой базе, сидят такие данные, как логин, пароль, тариф и прочие атрибуты пользователя (абонента). Эта программа получает данные пользователя( логин и пароль) от от NAS (Network Access Server), коим могут быть такие вещи, как:

1. Точка Wi Fi доступа
2 . VPN сервер (в моем случае это был некий L2TP сервер)
3 . IP АТС
4 . . и прочее железо, которое в дальнейшем так и будем называть — «железка».

и затем смотрит по своей базе, можно ли этому пользователю давать добро на подключение к «железке» ( NAS- у ), или нет.

Так как RADIUS сервер практически вряд ли сможет работать с БАЗОЙ пользователей сам по себе, то его еще называют буфер ом (интерфейс ом ) между некой Б иллинговой программой и «железкой» ( NAS -ом) провайдера. Хотя такая терминология больше путает, чем что-то разъясняет.

«Железки» ( NAS- ы) провайдера, по сути своей, являются подчиненными, или «клиентами» RADIUS сервера. Они, по научному говоря, являются «сетевыми серверами доступа» — NAS (Network Access Server), которые передают через себя данные пользователя (абонента) — логин, пароль, объем трафика, время подключения RADIUS серверу, а RADIUS сервер смотрит в БАЗУ данных пользователей и уже затем решает, «перекрыть кислород» пользователю на основе этих полученных от «железок» данных, или нет. В моем личном случае в качестве NAS выступал отдельно взятый компьютер под Linux, на котором был запущен L2TP сервер (VPN сервер). Этот L2TP сервер переправлял данные пользователя, (его логин, пароль, количество трафика, время подключения), RADIUS серверу, а тот, посмотрев базе пользователей, может абонент работать в интернете дальше или нет, принимал свое решение. С соответствии с этим решением L2TP сервер, который организовывал клиенту VPN-подключение, либо отключал абонента, либо разрешал ему работать дальше. Так же можно и нужно представить себе для понимания такую, всегда неизменную, связку трех разных служб:
1. VPN-сервер (PPTP, L2TP, PPP, IPIP, IPSec) он же NAS, или наша любая другая «железка» провайдера.
2. RADIUS сервера (буфер, интерфейс между NAS-ом и Биллингом).
3. Биллинг (от любой фирмы изготовителя).
Далее все то же самое, только несколько иными словами.

Итак! Еще раз. Для чего же нужен RADIUS сервер и что это есть такое.
RADIUS сервер используется ТОЛЬКО И В ОСНОВНОМ для того, чтобы работать с БАЗОЙ данных пользователей и их валидност ю . То есть каждому пользователю из Биллинговой программы заранее прописываются те или иные привилегии по использованию той или иной «железки» провайдера. Логин, пароль, т ариф, скорость, время, (когда можно, когда нельзя) и так далее. И затем, RADIUS сервер, на основе этих данных из базы данных, выносит свой приговор пользователю, посылая этот приговор «железке» провайдера (NAS -у). И «железка», в моем случае это отдельный комп с установленным на него L2TP сервером ( VPN сервером) вырубает пользователя или разрешает ему работать дальше. Авторизует его или отказывает в авторизации. Если эти привилегии пользователя учитывать не нужно, и в мире давно наступил коммунизм, то RADIUS сервер можно смело засунуть в топку и забыть про него, как про страшный сон. Я это сказал к тому, что по своей сути, RADIUS сервер — это мешающее провайдеру и пользователю, устройство. Так же как и Биллинг. Вполне достаточно иметь только VPN -сервер (к примеру, L2TP сервер) со своей личной базой пользователей, где будут только логины и пароли пользователей. И все.

Важное замечание — для чего еще может быть полезен RADIUS сервер . Естественно, как очень важный момент, получается, что при использовании RADIUS сервер а не нужно каждой «железке» ( NAS -у) провайдера, хранить в себе личную базу пользователей , их пароли , атрибуты и прочее , а можно и нужно хранить эту базу пользователей только в одном месте, на RADIUS сервере. Там эту базу провайдер будет админить через Биллинговую программу и ВСЕ «железки» ( NAS -ы) провайдера , сразу будут об этом узнавать. Хвала, RADIUS серверу, что не нужно будет бегать к каждой » железке » в отдельности . Х оть это и вполне возможно при наличии и у админа здорового тела, времени и желания заниматься такой фигней.

Дык , вот ! К аждая «железка» (NAS) провайдера, с которой общается пользователь ОБЯЗАНА знать IP-адрес RADIUS сервера и имеет в себе соответствующее поле, куда этот адрес можно прописать. Выходит, что КАЖДАЯ такая «железка» ( NAS ) умеет общаться не только с пользователем -клиентом , но и с RADIUS сервером, куда она, эта «железка», как шпион, как «стукач ка «, по тихому, по подлому, передает данные о том, что творит пользователь с ней родной, с бедной «железкой». Как долго подключен к ней пользователь, какой трафик прогнал через нее и прочее. Ну, и как было сказано выше, эта подлая «железка», получив от пользователя его имя и пароль, сначала спросит разрешение на аутентификацию пользователя у своего «начальства», то есть у RADIUS сервера, и уже затем даст пользователю добро на подключение к себе , или пошлет куда подальше . Так же RADIUS сервер , на основе своей, постоянно изменяющейся базы данных, может запросто сказать своей подчиненной «железке», что мол все, баста, лимит трафика или времени, клиент исчерпал. Отключай его, на фиг! И «железка» ( NAS ), подчинившись приказу RADIUS сервер а, безропотно выполнит это т приказ.

В инете, в многочисленных описаниях, очень часто звучит терминология подобного вида:
«Клиент авторизуется на RADIUS сервере» .
И именно эта дебильная фраза сбивала с толку бедного тупого Славика и не давала ему понять сущности, что есть такое RADIUS сервер. На кол таких писателей, блин. Дык , вот, такая терминология в корне НЕВЕРНА . Клиент авторизуется ТОЛЬКО на «железке» (на VPN сервере, на NAS -е) провайдера. И именно к ней он и стучится с мольбой получить доступ в интернет. А вот сама подлая «железка» ( NAS) , вместо того, чтобы сразу подключить к себе пользователя, ломится к RADIUS серверу за разрешением и сообщает ему о том, что некий клиент к ней авторизуется. RADIUS сервер , с высоты свой НЕОПРАВДАННОЙ значимости, смотрит у себя по БАЗЕ , есть ли такой пользователь или нет, (что там записано за этим пользователем, какие грехи числятся), и говорит «железке» (NAS -у) , что такой пользователь есть и ему можно дать добро или нужно послать на фиг. И затем уже «железка» ( NAS ) дает добро своему пользователю (или посылает его на фиг). Если RADIUS сервер не установлен и не существует в природе , то «железка»(NAS) сама в праве принять решение, авторизовать клиента или нет. То есть, в ней самой может существовать база пользователей для авторизации и она самостоятельно сможет решить, п родолжать сессию пользователя или послать его.. . Посему правильно будет звучать такая фраза:
«Клиент авторизуется на » железке » (на NAS -е) провайдера» . Именно к «железке» провайдера обращается клиент. НАПРЯМУЮ. А дальше уже подлая «железка» решает, в зависимости, от того, что прописано в ее настройках, обращаться за разрешение к своему хозяину — RADIUS серверу, или нет. А бедный Славик всегда думал иначе. Думал, что обращение идет всегда и исключительно на RADIUS сервер и уже затем, он пропускает клиента дальше, к «железкам», к сервисам провайдера. И потому непонятны были всегда эти картинки с «прямоугольничками» на разных сайтах с мануалами, где RADIUS сервер всегда стоит в сторонке. Как бы самый последний крайний «прямоугольничек». Типа, — «я тут совсем не при делах и знать ничего не знаю». А оно вон, оказывается, как обстоят дела! Вон, оказывается, кто тут на самом деле Главный говнюк!

В контексте программ » RADIUS сервера» и некого «Биллинга», можно сказать еще следующее: «БАЗА пользователей» — общая для этих обеих служб. Формат ее может какой угодно. Даже может быть в формате базы » Ms SQL » Главное, чтобы и RADIUS сервер и Биллинговая программа, могли работать с этой базой и понимать ее. RADIUS сервер, основываясь на данных из этой БАЗЫ, дает команду NAS серверу, вырубить того или иного пользователя, или разрешить ему работать дальше. Так же RADIUS сервер пишет в базу статистические данные пользователя, сколько он спалил трафика, как долго уже продолжается его интернет-сессия и так далее.. А Биллинговая программа может считать деньги абонентов по этой базе в реальном времени и так же дает возможность управлять этой базой данных, внося различные атрибуты пользователя. Дает возможность добавлять нового пользователя или удалять его. Так же вносит на счет абонента нулевой денежный остаток, если абонент вовремя не пополнил свой счет. А RADIUS сервер, видя «нолик» у пользователя, даст команду «железке» (NAS -у), отключить пользователя .

Немного практики для понимания. Чисто теоретически, допустим, имеем мы три компа: NAS, RADIUS сервер и Биллинг. База стоит на компе c RADIUS сервер ом . Комп с Биллингом включаем, подцепляемся к Базе, вносим туда новых пользователей, их тарифы и прочее. И вырубаем комп с Биллингом на фиг! !! Комп с RADIUS сервер ом будет замечательно работать и дальше. Будет работать основываясь на созданной с помощью Биллинга базе. Биллинг RADIUS сервер у НЕ НУЖЕН . Биллинг нужен, лишь для того, чтобы потом, в дальнейшем, когда база пользователей уже заполнена, в реальном времени, начать уменьшать денежный баланс у абонентов. Но если этого делать не нужно и наступил коммунизм, то Биллинг можно запросто выключить. Повторюсь, RADIUS сервер начнет работать сам по себе, без Биллинга, основываясь лишь на ранее созданной БАЗЕ. Допустим, в базе данных сказано, что некий Вася Пупки, имеет право работать в интернете бесплатно, с нулевым балансом, но только в ночное время и только с определенной скоростью. Все! Начиная с этого момента, RADIUS сервер начнет работать сам по себе, разрешая Васе Пупки подключаться только ночью и только на определенной скорости. И э т а запись в БАЗЕ есть неизменная и вечная запись для этого пользователя. Отсюда вопрос. Зачем нам в этом случае нужен комп с Биллингом? Все верно. Не нужен. Комп с Б илллингом нужен лишь для того, чтобы что-то изменить в атрибутах и тарифе этого гипотетического Васи Пупкина. Только для этого.

Делаем выводы из всего выше сказанного:

RADIUS сервер (вместе с Биллингом) — ЭТО МЕРЗОКОЕ ЗЛО , которое не то, что помогает, оно жутко мешает. .. Тормозит работу, и клиента, и провайдера. И для само й телематики провайдера это ЗЛО на фиг не нужно. RADIUS сервер приходит ь ся терпеть лишь потому, что пока еще не наступил коммунизм. И только поэтому. И если всякие там DHCP серверы, DNS серверы, WWW , FTP , WINS нужны и являются помощниками провайдера и клиента, то RADIUS сервер нужно в будущем гнать поганой метлой. Чтобы и духу его не было в телематике провайдера. И все бы так и было, но есть одно большое НО . Если вы внимательно читали этот опус, я обмолвился об одной вещи, но внимание на ней сильно не акцентировал. Дык вот, повторюсь еще раз п ро то, что я писал выше . Представим себе ситуацию, когда NAS- ов у провайдера очень много. И что нам делать в этом случае? На каждом NAS -е заводить свою личную базу пользователей с их логинам и паролями?! Нет, конечно! БАЗА должна быть одна. С ней должен работать наш RADIUS сервер, а все NAS- ы провайдера должны обращаться к этому R ADIUS серверу. Только в этом случае, админу не придется бегать между разными «железками» ( NAS -ами), чтобы подправлять там тариф, логин и пароль у одного и того же Васи Пупкина.

Отзыв об этой Эпопее можете оставить в моей Гостевой книге. 🙂

Последнее обновление странички

Дата: 12 ноября 2013 г.

Время: 11:30