Нужна помощь с авторизацией.
Нужна помощь с авторизацией.
Вобщем то был прецендент, после чего заудмался о контроле VPN подключения - необходимо привязать или к маку или к ипнику с которых можно устанавливать подключения, а лучше и то и то. Вобщем то FreeBSD 6.2 release и mpd5 на борту. Какие будут предложения?
Локальные ip храню в allowed_cid со времён 5.1.10-хх.
freeradius делает sql запрос вида:
authorize_check_query = "SELECT ig.ip_group_id, ig.uname, 'Password', ig.upass, '==' \
from iptraffic_service_links il, ip_groups ig, service_links sl, accounts a \
where ig.uname='%{SQL-User-Name}' \
and ig.ip_group_id=il.ip_group_id \
and sl.account_id=a.id \
and a.is_deleted=0 \
and sl.id=il.id \
and ig.is_deleted=0 \
and il.is_deleted=0 \
and sl.is_deleted=0 \
and (a.is_blocked=0 \
AND (INSTR(ig.allowed_cid, '%{Calling-Station-Id}') > 0)"
Имхо, при необходимости не проблема переделать с использованием флагов VPN/не VPN.
Для pppoe маки не проверяю, руки не дошли, а маки лежат в отдельной табличке, обновляемой скриптами автоматически их вяжущими на оборудовании. Просто при наличии слова pppoe в allowed_cid, запрещаю логин по pptp. Но pppoe клиентов у меня десятка полтора на несколько тысяч pptp.
freeradius делает sql запрос вида:
authorize_check_query = "SELECT ig.ip_group_id, ig.uname, 'Password', ig.upass, '==' \
from iptraffic_service_links il, ip_groups ig, service_links sl, accounts a \
where ig.uname='%{SQL-User-Name}' \
and ig.ip_group_id=il.ip_group_id \
and sl.account_id=a.id \
and a.is_deleted=0 \
and sl.id=il.id \
and ig.is_deleted=0 \
and il.is_deleted=0 \
and sl.is_deleted=0 \
and (a.is_blocked=0 \
AND (INSTR(ig.allowed_cid, '%{Calling-Station-Id}') > 0)"
Имхо, при необходимости не проблема переделать с использованием флагов VPN/не VPN.
Для pppoe маки не проверяю, руки не дошли, а маки лежат в отдельной табличке, обновляемой скриптами автоматически их вяжущими на оборудовании. Просто при наличии слова pppoe в allowed_cid, запрещаю логин по pptp. Но pppoe клиентов у меня десятка полтора на несколько тысяч pptp.
Re: Нужна помощь с авторизацией.
А чем "Разрешённые CID" не устраивают ? для pppoe использовать MAC для VPN - IP.hammer писал(а): после чего заудмался о контроле VPN подключения -
P.S.
Уже много раз говорилось что MPD 5 не живёт нормально под нагрузкой на FreeBSD ниже 6.3, более того если SMP система, то под серьёзной нагрузкой могут возникнуть проблемы и с MPD4.4.
Да это то все понятно... а про регулярки - вижу - тока каким ментальным путем я должен был догадаться что их там можно использовать (хотя возможно просто в доке не все уловил... )? А вот ещё один вопрос, который меня давно мучает - как в ОДНОЙ сети могут ли соссуществавать нескольок PPPoE шлюзов и если да, то по каким ID их можно делить и перенаправлять подключение. Там помоему есть метка provider, но как её правильно пользоваться? Вот собсвенно эта затея у меня была и для этого надо было конфиги freeradius, хотя ещё пару дней и уже сам допишу что надо было ( не поленился - самому разобраться всегда полезнее, хотя и НЕ отказываюсь от готовых конфигов -) ). Просто есть затея, как нить распределять динамически абонентов на шлюзы, ещё на стадии подключения при авторизации, в зависимости, для начала от полученных параметров из базы - в дальнейшем хочу ещё и от нагрузки на шлюз, или каких либо сторонних динамических параметров. С одной стороны довольно амбициозная задача, но что то подобное я на форуме chris а читал, помоему Magnum писал про авторизацию абонетов на разныз портах кошки, ну и соотвесвенно на каждом порту свои или vlan или шейпер или ещё что душе угодно. Только вот щас хочу седлать это все для PC 3 шлюзов.
ЗЫ Ну и конечно же вебморду для управления этот системой на Perl.
ЗЫ Ну и конечно же вебморду для управления этот системой на Perl.
Интересная затея. По идее PPPoE клиент, прежде чем прицепиться к шлюзу, посылает особый широковещательный запрос, суть которого "а кто тут собственно PPPoE сервер?" Сервер отвечает - ну я мол, имя службы такое-то. Так вот, смысл задачи - управлять ответом кучки серверов по схеме round-robin для начала. Что кроме как перелопачиванием исходников PPPoE сервера не реализовать. То есть здесь должно быть так - пришел запрос, все его увидели, но ответил только один из всех. В обычной ситуации ответят все. И чей пакет первым долетит до клиента, с тем он и соединится. Что не есть хорошо.
Можно ли рулить ответами серверов PPPoE с помощью какого-либо железа, на основании MAC адреса сервера - не знаю. Можно соорудить управляемый бридж, реализующий такую схему. Но это дорогая затея, к тому же этот бридж будет закрывать весь кластер и на него надо будет сводить весь трафик сетки и он просто помрет от нагрузки.
В случае с PPTP задачка немного упрощается. Но опять же полного контроля за распределением нагрузки не получишь. Здесь можно сделать так. Поднимаем CARP на интерфейсах, которые слушают сервера. Один IP - несколько MAC. По ARP ответы идут по схеме round-robin. Далее имеем плавное распределение подключений на все машинки. Есть правда один нехороший момент. Если клиент потеряет ARP запись, у него обвалится сессия. И это в общем-то тоже излечимо, если задействовать DNS и там прописать кучку адресов на одно общее имя. В этом случае тоже будет реализован round-robin, но оно не будет таким шатким, как в случае с CARP.
Кроме того, DNS позволяет разрулить нагрузку на PPTP шлюзы с учетом топологии сети, причем даже двумя способами, чего в случае с PPPoE не сделаешь по определению.
Можно подойти и с другой стороны. Вы работали с животными? знаете конечно, что для того, чтобы собачка не кусалась, ее надо в изолятор посадить, хотя бы временно. И вовсе не обязательно лишать животное зубов или жизни. Так и здесь. Можно сделать некую надстройку, блокирующую ответы по PPPoE так, чтобы отвечал только один сервер из кучки. Эта программка бежит на всех серверах и ее экземпляры могут держать друг с другом связь через обычный TCP или UDP без централизации, то есть каждый из кучи поднимает линки со всеми остальными и по ним обменивается информацией. Либо можно использовать широковещательный обмен, но тогда лучше всю эту кучку посадить параллельно внутрь отдельного VLAN, так сказать, во избежание. Эта программка может блокировать ответ конкретного сервера в зависимости от его нагруженности, или принимая во внимание какие-то еще моменты.
Но на высоконагруженных NAS кластерах не стоит делать ничего, кроме round-robin. Смысла не вижу. Поправьте, если не прав.
Можно ли рулить ответами серверов PPPoE с помощью какого-либо железа, на основании MAC адреса сервера - не знаю. Можно соорудить управляемый бридж, реализующий такую схему. Но это дорогая затея, к тому же этот бридж будет закрывать весь кластер и на него надо будет сводить весь трафик сетки и он просто помрет от нагрузки.
В случае с PPTP задачка немного упрощается. Но опять же полного контроля за распределением нагрузки не получишь. Здесь можно сделать так. Поднимаем CARP на интерфейсах, которые слушают сервера. Один IP - несколько MAC. По ARP ответы идут по схеме round-robin. Далее имеем плавное распределение подключений на все машинки. Есть правда один нехороший момент. Если клиент потеряет ARP запись, у него обвалится сессия. И это в общем-то тоже излечимо, если задействовать DNS и там прописать кучку адресов на одно общее имя. В этом случае тоже будет реализован round-robin, но оно не будет таким шатким, как в случае с CARP.
Кроме того, DNS позволяет разрулить нагрузку на PPTP шлюзы с учетом топологии сети, причем даже двумя способами, чего в случае с PPPoE не сделаешь по определению.
Можно подойти и с другой стороны. Вы работали с животными? знаете конечно, что для того, чтобы собачка не кусалась, ее надо в изолятор посадить, хотя бы временно. И вовсе не обязательно лишать животное зубов или жизни. Так и здесь. Можно сделать некую надстройку, блокирующую ответы по PPPoE так, чтобы отвечал только один сервер из кучки. Эта программка бежит на всех серверах и ее экземпляры могут держать друг с другом связь через обычный TCP или UDP без централизации, то есть каждый из кучи поднимает линки со всеми остальными и по ним обменивается информацией. Либо можно использовать широковещательный обмен, но тогда лучше всю эту кучку посадить параллельно внутрь отдельного VLAN, так сказать, во избежание. Эта программка может блокировать ответ конкретного сервера в зависимости от его нагруженности, или принимая во внимание какие-то еще моменты.
Но на высоконагруженных NAS кластерах не стоит делать ничего, кроме round-robin. Смысла не вижу. Поправьте, если не прав.
Вобщем из всего этого выношу 2 варианта
1 -PPTP: Либо мы скрываем весь кластер за одним доменным именем - все клиенты авторизируются по доменному имени - и в зависимости от определнных настроек и параметров возвращает абоненту необходимый ипник уже непосредсвенно шлюза.
2 - PPPoE - пишем на С демон, который децентрализованный - слушает сокет когда придет какой то пакет и блкирует ARP ответ сервера и генерит пакет, на нужные сервера с указаними их блокировки - это похоже уже на работу микроядерной ОС
- в свое время RMS оччень много времени положил на отлатду и дебаг таких вещей - так что я что то, глядя на опыт написания таких приложений другими людьми, пожалуй в связи с его сложностю воздержусь от подобных начинаний.
А вот c DNS вариант более адекватный, к тому же я делал так уже рулежку коннектов на рспределенные ftp сервера, которые зеркалировались по rsync, но там параметр выбора маршрута служил ip источника -> смотрим совпадение с к-либо зоной -> выдаем ипник. Тут я думаю будет посложнее, потому что параметром выборки будут служить сторонние динамические параметры шлюзов - ещё не понятно как их передавать DNS серверу и даже если и придумается что то какова будет инертность всей системы.
1 -PPTP: Либо мы скрываем весь кластер за одним доменным именем - все клиенты авторизируются по доменному имени - и в зависимости от определнных настроек и параметров возвращает абоненту необходимый ипник уже непосредсвенно шлюза.
2 - PPPoE - пишем на С демон, который децентрализованный - слушает сокет когда придет какой то пакет и блкирует ARP ответ сервера и генерит пакет, на нужные сервера с указаними их блокировки - это похоже уже на работу микроядерной ОС
- в свое время RMS оччень много времени положил на отлатду и дебаг таких вещей - так что я что то, глядя на опыт написания таких приложений другими людьми, пожалуй в связи с его сложностю воздержусь от подобных начинаний.А вот c DNS вариант более адекватный, к тому же я делал так уже рулежку коннектов на рспределенные ftp сервера, которые зеркалировались по rsync, но там параметр выбора маршрута служил ip источника -> смотрим совпадение с к-либо зоной -> выдаем ипник. Тут я думаю будет посложнее, потому что параметром выборки будут служить сторонние динамические параметры шлюзов - ещё не понятно как их передавать DNS серверу и даже если и придумается что то какова будет инертность всей системы.
PPPoE сервера можно делать несколько в сети.
если сервера абсолютно одинаковы - то теретически - в определенный момент они сами друг друга сбалансируют - ну то есть тупо на пальцах -клиент зацепится на тот - который быстрее ему ответит. а быстрее ответит - или менее загруженный сервер или тот, от которого по сети быстрее пакетик долетит.
а есть и нормальное решение - драйвер ras-pppoe
отобразит список серверов в сети - и спросит соединение с каким из них нужно создать.
если сервера абсолютно одинаковы - то теретически - в определенный момент они сами друг друга сбалансируют - ну то есть тупо на пальцах -клиент зацепится на тот - который быстрее ему ответит. а быстрее ответит - или менее загруженный сервер или тот, от которого по сети быстрее пакетик долетит.
а есть и нормальное решение - драйвер ras-pppoe
отобразит список серверов в сети - и спросит соединение с каким из них нужно создать.
У DNS есть dynamic updates, а для снижения инертности лучше использовать короткоживущие записи, схема строится в два либо три слоя в зависимости от количества самих кластеров. В случае с серверами обновлений Microsoft используется именно такая схема, там имя сервера имеет несколько короткоживущих CNAME записей, каждая из которых ссылается на свое имя, а у этого имени в свою очередь может быть еще и своя кучка IP адресов. Но если кластер один, то можно обойтись без CNAME и использовать A записи с небольшим TTL и ими уже рулить.
Выбирайте, что для вас лучше. Схема, которую представил weris, полегче в реализации и тоже может неплохо работать, хотя там есть зависимость от общей загруженности сетки.
Выбирайте, что для вас лучше. Схема, которую представил weris, полегче в реализации и тоже может неплохо работать, хотя там есть зависимость от общей загруженности сетки.