Wapr-Old

Решил таки выложить обновлённую версию скрипта, но посмотрев на объём :-0 , решил ограничиться заголовком и ссылкой. #!/bin/sh #Этот скрипт вызывается в момент, когда пользователь #успешно прошел авторизацию в биллинге. Задача скрипта - перестроить #файрволлы так, чтобы пользователь получил доступ в интернет # ©2003-2008 Wapr Old. Ver 3.3 (04.2008) #0. Умолчания: До запуска биллинга должна быть создана цепочка BILL # с последним правилом -j DROP и в неё должны отправляться все пакеты # для которых необходимо управление доступом. (как минимум из FORWARD) # и запрос на прокси. # например так: # iptables -A FORWARD -i $WAN -o $LAN -j BILL # iptables -A FORWARD -i $LAN -o $WAN -j BILL # iptables -A INPUT -p tcp --dport 3128 -i $LAN -j BILL # где WAN/LAN - имена сетевых интерфейсов [ethX|pppX] #1. Скрипт проверяет наличие персональной юзерской цепочки по шаблону # BILL_${LOGIN} и если её нет, создает её. [bILL_Vasya] #2. В неё при создании добавляются в нужном порядке разрешающие # и запрещающие правила для всех необходимых адресов и критериев # ограничения скорости с возвратом пакетов через -j ACCEPT # Стоит учесть, что сюда попали пакеты ТОЛЬКО данного юзера, поэтому # IP юзера можно уже не учитывать #3. В цепочку BILL добавляется вызов юзерской цепочки для всех # входящих и исходящих пакетов данного юзера # iptables -I BILL -s $IP -j BILL_${LOGIN} # iptables -I BILL -d $IP -j BILL_${LOGIN} #4. Для отключения юзера надо удалить только 2 правила в цепочке BILL, # а его цепочка остается на будущее. (to do) #5. Допускается форвард до 15 портов по TCP и UDP отдельно. Список берется # либо из поля Userdata0, либо из файла в каталоге "/home/$LOGIN/portforward.txt" # формат записи: tcp=port1,port2... udp=port1,port2... # эквиваленные разделители: "="==":" ","==";" \n==\s==\t # Последняя строка файла не должна содержать правил и может быть пустой или # с комментарием, но она должна быть. # Пример создаваемого правила: # iptables -t nat -A PREROUTING_$LOGIN -i ppp+ -p tcp -m multiport \ # --dport 1234,5678,18273 -j DNAT --to-destination $IP # В случае попытки захвата занятого порта юзеру выдаётся предупреждение, а порт # исключается из запроса. #6. Если имя в биллинге не совпадает с именем на сервере, для поиска юзерского # файла допускается подмена из поля Userdata0: username=имя_на_сервере #7. Можно заблокировать порты назначения каждому юзеру записями в Userdata0 # rejecttcp=port1,port2... и rejectudp=port1,port2... # Блокирующие записи вносятся в персональную юзерскую цепочку и не мешают остальным # юзерам. Также нет ограничений на количество портов. # пример блокирующего правила: # iptables -A BILL_$LOGIN -p TCP --dport 25 -j REJECT #8. При анализе имени тарифа выделяются фрагменты "anlim-" и "abon-" для создания # особых правил для данных типов тарифов. # Также выделяется последние цифры от знака "-" до конца для получения тарифной скорости # в Kbit/sec по маске AnyTarifName-X, где X произвольное число. # Если числа нет или оно равно нулю - скорость не ограничена. # Т.е. название тарифа строится по формату: AnyTariffName[abon-][anlim-][-speed] дальше код. его много. 1 пуд. чтоб не засорять тут, скачать можно там.

И вообще, есть прекрасная книга от О'Релли, называется "Юзинь самба" Там всё настолько разжёвано и по шагам расписано, что даже я понял, настроил и всё работает уже который год. :tongue:

Не "всех", а "у всех". Почувствуйте разницу (с) -

Дать доступ и обеспечить видимость ресурса - это две большие разницы. Первую задачу решает smbd, вторую nmbd. Делаешь самбу мастербраузером в локалке, у всех юзверей прописываешь wins и с этого моменты сетевое окружение работает как часы. # Domain Logon Services domain master = yes preferred master = yes local master = yes domain logons = no os level = 255 # WINS & DNS service wins support = yes ...

Правильно говорит пословица: обещанного 3 года ждут. Только Вы EvgeniyS чуть поторопились, до 3х лет ещё неделя осталась

Маска это всегда удобнее, чем остальные предложенные варианты. А насчёт ошибок... ну так это при любой системе можно ляпов наделать, было бы желание

ftp-data 20/tcp File Transfer [Default Data] ftp-data 20/udp File Transfer [Default Data] ftp 21/tcp File Transfer [Control] ftp 21/udp File Transfer [Control]

на ID надеяться нельзя, т.к. это дело не было ни разу специфицировано. Видимо сугубо внутренняя служебная переменная. Запуска OnDisconnect-OnConnect при смене тарифа мне добиться от авторов не удалось Скоро выложу ещё более продвинутую версию с DNAT

Наверное лучше будет так разрешить $IPTABLES -t nat -A POSTROUTING -i $iface_lan -o $iface_wan -j SNAT --to-source $ip_wan Или хочется для каждого юзера отдельно писать такое правило? А смысл? Набери route -n и посмотри дефолт гейтвей, я не вижу, где это прописывается. Да и не только дефолт... А вообще посмотри сюда http://local.com.ua/forum/index.php?showtopic=2020

Всё это хорошо, но где правила, пускающие клиента в инет? (и потом, я мож не совсем копенгаген в iptables, но для маскарада я бы указал конкретный входной и выходной интерфейсы, а не все подряд адреса)

Если уж делать такое, то в цикл надо обязательно влепить команду записи в лог, т.к. срабатываение этого цикла однозначно свидетельствует об ошибке в настройке системы.

Ну почему? Мы тут обсуждали это дело, но к чему это приведёт, мне неведомо...

В общем случае - никак. Если я не подключаюсь, у меня может быть любой IP, в том числе тот, которого вообще нет в биллинге. Даже если есть, при наличии клиентов с несколькими разрешёнными IP, поиск по базе может не дать однозначного соответствия. И только если все клиенты имеют строго по одному IP, возможен поиск по базе. (но тогда это тривиальный парсинг файлов /var/stargazer/users/*/conf, или вопрос не об этом?)

Что есть неактуальное сообщение? Сообщение которому больше чем N дней? Если так, то сделать можно. Не совсем так, это сообщение, в котором просрочен срок его отправки клиенту, а не просто Н-ное количество дней. Срок должен содержаться в виде структуры данных в служебных полях самого сообщения чтоб можно было при отправке задать например: это сообщение действительно ближайшие (X часов|сутки|неделю|и т.п.), потом уже неактуально и отправлять его клиенту не надо, или - это сообщение клиент получит в любом случае, как бы поздно он не подключился.

Например у юзера нет денег... упс... опередили

Может он имел в виду ширину канала после зажатия шейпером? ...впрочем всё равно это к биллингу не относится.

Я не утверждал, что данный конкретный варнинг приведёт к потере денег, я хотел этим сказать, что варнинг для того и придуман, чтобы указать на места возможных ошибок логики и плевать на них как минимум неразумно.

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

Для этого у администратора есть почта (ИМХО). А вот передача хотя-бы одного текстового параметра при авторизации действительно вещь стоящая. Ничего с ним не делать, просто транслировать в OnConnect, а там пусть скрипт разбирается.

Уже было. Ждём-с...

Ну если посмотреть, что я писал ранее, можно заметить, что я упоминал и красивое решение Т.е. дополнить профайл именем и в списке выводить именно его. Красивей не бывает :tongue:

Это тянет на future request, но в примерно такой формулировке: Ввести в сервер понятие "событие" (если его там ещё нет) и сделать вызов скрипта например OnEvent с передачей ему параметров события. А под событием в частности понимать достижение отдельно установленного(ых) порога(ов) трафика по каждому из направлений. Возможно ещё какие-то критерии, которые сервером проверяются, но сейчас не выводятся наружу.

В логах биллинга? Не дай Бог!

Странно это всё... сейчас посмотрел прошлогодние логи, когда мою сетку подобные вирусы мучали, отмечалось до 20000 запросов в 10-минутный интервал и свыше 100000 за сутки, но ничего не падало и жалоб на тормоза не припоминаю. Правда лог юзера при этом достигает 10Мб :rrr: Может Ваш сервер перегружен посторонней работой или неаккуратно сконфигурирован? -> 23.50.00 - 00.00.00 2.69.92.90 0 0 96 0.000000 2.82.82.154 0 0 48 0.000000 4.79.62.232 0 0 96 0.000000 4.146.131.48 0 0 144 0.000000 6.162.246.112 0 0 48 0.000000 7.159.227.223 0 0 96 0.000000 7.162.85.167 0 0 96 0.000000 7.200.219.199 0 0 96 0.000000 9.248.18.211 0 0 144 0.000000 10.3.30.199 0 0 96 0.000000 10.5.2.39 0 0 96 0.000000 10.8.240.147 0 0 48 0.000000 10.10.238.98 0 0 144 0.000000 10.13.2.28 0 0 144 0.000000 10.16.30.246 0 0 48 0.000000 10.16.128.103 0 0 48 0.000000 10.18.75.197 0 0 96 0.000000 10.18.107.68 0 0 48 0.000000 10.19.113.222 0 0 48 0.000000 10.25.47.56 0 0 96 0.000000 10.27.15.133 0 0 48 0.000000 10.31.139.148 0 0 144 0.000000 Похоже? Можно например и так: ... usersconf="/var/stargazer/users/$LOGIN/conf" ... # Парсинг поля Userdata0 - Получить нужную переменную из строки Run=off или Run=<имя скрипта> U0=`cat "$usersconf" | grep "Userdata0="`; Userdata0=( ${U0#Userdata0=} ) for element in ${Userdata0[@]}; do if [ ${element:0:3} == "Run" ]; then Run=${element##*=}; continue; fi #... поиск других переменных done if [ "$Run" == "off" ]; then # завершение OnConnect exit elif [ -x "$Run" ]; then # запуск указанного скрипта вместо OnConnect $Run $1 $2 $3 $4 exit fi # Нормальное выполнение OnConnect ...

Всё упирается в "направления", описанные в файле rules. Сумеете написать набор адресов, привязанный например к DIR1 и покрывающий все подсети на eth1 - можно будет и тариф сделать с подсчётом только DIR1. Аналогично и для остальных интерфейсов. А вот привязаться непосредственно к устройству к сожалению нельзя. (ver 2.xx)