О Captive Portal, RADIUS и нескольких NAS
-
Доброго всем времени суток.
Продолжаем тему, начатую здесь http://forum.pfsense.org/index.php/topic,46210.0.html
Общее описание: есть сеть, в которой выходы на разные внешние сегменты организован через свои шлюзы на pfSense. На данный момент остановимся на примре, когда есть 2 внешних сегмента: сеть провайдера и Интернет и сеть партнерской организации (обе сети заведены в серверную на статические адреса). Кроме этого - есть еще один сервер (назовем его - управляющий), выполняющий роль DNS и DHCP (тоже pfSense, родимый)С маршрутами я уже разобрался в предыдущем топике - все бегает замечательно.
Теперь встал вопрос каким образом можно запретить некоторым пользователям ходить в тот или другой сегмент. Естественно, на первый взгляд нет ничего проще - поднять на управляющем сервере RADIUS, на шлюзах запустить Captive Portal'ы с авторизацией из корневого сервера. Сделано и работает - пока пользователь не прошел авторизацию на CP шлюза, обслуживающего данный сегмент, ничего туда не валится.Естественно, не все так радужно - пользователю надо будет авторизовываться дважды, а если шлюзов несколько? Расстреляют.
Сразу оговорюсь - сеть офисная и никакого VPN для авторизации и раздачи маршрутов быть просто не могет.
Я вижу сейчас только два варианта:
1. Заставить CP со всех шлюзов каким-то образом брать информацию об авторизации с корневого сервера (пока сложно представить - возможно какие-то манипуляции со страницами авторизации шлюзов)
2. Сделать свой агент-авторизатор, который просто будет раз в какое-то время долбить страницы портала и "авторизовывать" пользователя (тут возникает вопрос каким образом для авторизатора использовать одну версию страницы входа, а для всех остальных пользователе - другую)
И это только первый вопросВторой вопрос более интересен - каким образом в RADIUS можно определить от какого из NAS'ов пришел запрос авторизации и на этом уровне разрешить/отвергнуть запрос?
В общем - сейчас играюсь с вариантами и с надеждой ду от сообщества направлений в нужную сторону
Заранее - спасибо.
-
на шлюзах запустить Captive Portal'ы
Насколько я понимаю, Captive Portal перехватывает именно (только) http-запросы, нет? Или вам нужно, чтобы именно по http юзеры могли или не могли куда-то попасть? Что насчет других портов/протоколов?
-
Вроде бы CP контролирует все. По HTTP только открывается доступ.
-
на шлюзах запустить Captive Portal'ы
Насколько я понимаю, Captive Portal перехватывает именно (только) http-запросы, нет? Или вам нужно, чтобы именно по http юзеры могли или не могли куда-то попасть? Что насчет других портов/протоколов?
Проверено - CP только авторизует по http/https (тоесть перехватывает запросы и показывает свою страницу авторизации). Пока пользователь не авторизован на CP, у него нет доступа за шлюз по любому из протоколов
-
на шлюзах запустить Captive Portal'ы
Насколько я понимаю, Captive Portal перехватывает именно (только) http-запросы, нет? Или вам нужно, чтобы именно по http юзеры могли или не могли куда-то попасть? Что насчет других портов/протоколов?
Проверено - CP только авторизует по http/https (тоесть перехватывает запросы и показывает свою страницу авторизации). Пока пользователь не авторизован на CP, у него нет доступа за шлюз по любому из протоколов
Понятно. Значит, я просто невнимательно читал про Captive Portal.
-
Ну чтож - разобрался я немного по теме и, на всякий случай, отпишусь здесь о результатах. Вдруг кому поможет
В общем самым простым вариантом оказалось создание своего агента авторизации. Единственное, что я решил поменять - схему работы:
Сервер Radius был вынесен на другую платформу (у меня это FreeBSD), где был поднят свой портал. На этот портал стучится агент, авторизуется. Далее сам портал уже идет на доступные для пользователя шлюзы и авторизует его на их CaptivePortal'ах.В связи с тем, что я не силен в php пришлось ставить Mono и разруливать все это на Asp .NET
Зато интересный опыт получился.