yKpon

несколько IP в режиме или, так сказать список адресов с которых разрешена авторизация, но не одновременно

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

жёсткая привязка по мак это ARP arp -s 192.168.1.2 00:1a:6a:00:00:00 в таком случае у абонента с айпи 192.168.1.2 и мак адресом отличным от 00:1a:6a:00:00:00 доступа к серверу не будет, он не будет даже пинговаться в вашем же примере скрипта проверка по маку учавствует только между обменом (цепочка FORWARD) приведу свой пример, база у меня в MySQL вот часть скрипта OnConnect отвечающая на мак MAC=`/usr/bin/mysql -sN -h$DBHOST -u$DBUSER -p$ROOTDBPASS $DBNAME -e "SELECT Userdata0 FROM users WHERE login = '$login'"` /usr/bin/arping -I eth_local $IP -c 1 -w 0 newMAC=`/usr/sbin/arp -a $IP | cut -f 4 -d " "` /usr/sbin/arp -d $IP /usr/sbin/arp -s $IP $newMAC if [ -z "`/bin/echo $MAC | grep $newMAC`" ]; then /etc/stargazer/sgconf set -s 127.0.0.1 -p 4446 -a $STGADM -w $STGPASS -u $login --ud0 $newMAC fi принцип работы: - берём МАС прописаный в карточке юзера - делаем arping чтобы мак "прорезался" на сервере, так сказать засветился - выделяем этот мак - статиески привязываем его (сначала опустошаем потом привязываем это для тех кому мак не нужно привязывать, команда -s попросту не сработает) - если же мак в базе и реальный мак разные тогда в базу заносится новый, сделано для того кто меняет сетевушку, всё равно кто то левый не сможет достучаться до сервера чтобы это сделать собственно вот, а так ещё раз в сутки по крону отрабатывает скрипт macfix #!/bin/sh source /etc/stargazer/sql.conf # lan0 for ((ip=2;ip<255;ip++)); do /usr/sbin/arp -s 192.168.0.${ip} ${firmmac} done; echo "lan0 done" # lan1 for ((ip=2;ip<31;ip++)); do /usr/sbin/arp -s 192.168.1.${ip} ${firmmac} done; echo "lan1 done" # lan2 for ((ip=2;ip<15;ip++)); do /usr/sbin/arp -s 192.168.2.${ip} ${firmmac} done; echo "lan2 done" LOGINS=`/usr/bin/mysql -sN -h$DBHOST -u$DBUSER -p$ROOTDBPASS $DBNAME -e "SELECT login FROM users"` for login in $LOGINS do IP=`/usr/bin/mysql -sN -h$DBHOST -u$DBUSER -p$ROOTDBPASS $DBNAME -e "SELECT IP FROM users WHERE login = '$login'"` MAC=`/usr/bin/mysql -sN -h$DBHOST -u$DBUSER -p$ROOTDBPASS $DBNAME -e "SELECT Userdata0 FROM users WHERE login = '$login'"` LOCKED=`/usr/bin/mysql -sN -h$DBHOST -u$DBUSER -p$ROOTDBPASS $DBNAME -e "SELECT Down FROM users WHERE login = '$login'"` if [ $LOCKED = 0 ]; then /usr/sbin/arp -d $IP /usr/sbin/arp -s $IP $MAC fi done lan4 done" echo "arp table fixed"

чтобы промерять по маку есть 2 варианта: 1. ip адреса жёстко привязаны к маку по ARP тогда проверка при авторизации не нужна, просто никто другой не сможет подключиться 2. ip не привязаны, но при авторизации проверяется MAC сетевой я у себя еспользую 1-ый вариант, если у вас 2-ой случай, то можно просто их сравнивать, узнать текущий мак можно через arp -a $IP | cut -f 4 -d " " или нужно именно разрешить форвард по мак? ещё не понятно зачем 2 раза одно и то же /sbin/iptables -A FORWARD -s $IP -j ACCEPT /sbin/iptables -A FORWARD -d $IP -j ACCEPT это же и есть filter

в стедующий раз постараюсь запечатлить по поводу поста http://local.com.ua/forum/topic/25760-purestg2/page__view__findpost__p__219609 понял что запись изменений в базу зависит от параметра StatWritePeriod в конфиге биллинга

да, повисало в одном месте vpnroot отличается лишь тем что его ip находится в 0 подсети в который живут те кто авторизуется через inetaccess ip-up и OnConnect одни на всех подвисание заключается в пропадании пинга, в монитор выплюнув какой то текст (надо было сфоткать) и никаких телодвижений в том числе с клавиатуры, Alt+SysRQ+REISUB не пробовал, честно говоря первый раз слышу, REISUB это чё за кнопка? точно помню оба раза зависал сразу после авторизации vpnroot

есть подозрение что связка с purestg2 вешает систему, было 2 раза подряд с интервалом где то месяц, сразу после успешной авторизации одной из учёток (а именно служебная vpnroot) система встаёт колом, kernel panic не наблюдается но опять же это моё предположение последняя запись в stargazer.log 2011-05-30 14:14:29 -- purestg2: request(socket=19): type=4, login=vpnroot 2011-05-30 14:14:29 -- purestg2: reply: type=4, login=vpnroot, result=1 последний syslog связанный именно с этой авторизацией May 30 14:14:25 skyprox pptpd[2521]: CTRL: Client 192.168.0.99 control connection started May 30 14:14:26 skyprox pptpd[2521]: CTRL: Starting call (launching pppd, opening GRE) May 30 14:14:26 skyprox pppd[2522]: Plugin purestg2.so loaded. May 30 14:14:26 skyprox pppd[2522]: Stargazer (purestg2 2.2) auth plugin initialized. May 30 14:14:26 skyprox pptp[2522]: Plugin pptp.so loaded. May 30 14:14:26 skyprox pptp[2522]: PPTP plugin version 0.8.5 compiled for pppd-2.4.4, linux-2.6.26 May 30 14:14:26 skyprox pptp[2522]: purestg2: Pap check is allowed. May 30 14:14:26 skyprox pptp[2522]: pppd 2.4.4 started by root, uid 0 May 30 14:14:26 skyprox pptp[2522]: purestg2: Connected to stargazer via /var/run/purestg2.sock. May 30 14:14:26 skyprox pptp[2522]: purestg2: ifunit set to 9. May 30 14:14:26 skyprox pptp[2522]: Using interface ppp9 May 30 14:14:26 skyprox pptp[2522]: Connect: ppp9 <--> pptp (192.168.0.99) May 30 14:14:26 skyprox pptp[2522]: purestg2: Chap check is allowed. May 30 14:14:26 skyprox pptp[2522]: purestg2: Pap check is allowed. May 30 14:14:26 skyprox pptp[2522]: purestg2: Chap check is allowed. May 30 14:14:29 skyprox pptpd[2521]: CTRL: Ignored a SET LINK INFO packet with real ACCMs! May 30 14:14:29 skyprox pptp[2522]: purestg2: CHAP started. May 30 14:14:29 skyprox pptp[2522]: purestg2: Got passwd for user vpnroot. May 30 14:14:29 skyprox pptp[2522]: purestg2: IP choose started. messages May 30 14:14:26 skyprox pppd[2522]: Plugin purestg2.so loaded. May 30 14:14:26 skyprox pppd[2522]: Stargazer (purestg2 2.2) auth plugin initialized.

это же логично, OnConnect добавляет правило, а OnDisconnect очищает все одинаковые правила созданные OnConnect, это если следовать примеру настроек этих скриптов

жёстко назначить, либо авторизатор, либо впн

del

а если читать нужно веб мордой? разрешать в sudoers доступ к ipset или iptables очень не корректно если база пользователей на *SQL я бы сделал дополнительное поле Online в базе users и менял бы его 0/1 и 1/0 при включении/отключении скриптами OnConnect/OnDisconnet

у меня те кто авторизуются через авторизатор и те что через впн находятся в разных подсетях, онконнектом это и обрабатываю

да что же вам мешает добавить дополнительные поля в таблицу tariffs со скоростями ночью/днём/вечером/утром? с порогами лимита и прочей ересью какую только можно придумать, к тому же веб морда вами уже написана, управляйте с помощью неё полями базы которые не использует стг какой то бред пионерский развели ей богу.

у меня есть сетка безлимитных тарифов с разделением скорости день/ночь и без особых костылей, главный костыль это шедулер который запускается 2 раза в день при переходе день/ночь и ночь/день

поля можно добавлять свои, стг их обрабатывать по просту не будет

золотые слова! ПЫ. у меня в базе users добалено несколько полей которые не обрабатывает стг, их обрабатывают стороннние скрипты, а администрирую через веб ,а не конфигуратор Zero_real, вы управляете юзерами через только через конфигуратор и хотите чтобы об обрабатывал абсолютно всё что связано с пользователями и выжать из него максимум? да он просто повесит биллинг если им досить с разных сторон будете, зачем к примеру ему обрабатывать то что никак не связано с интернетом? бред, подумайте в сторону написания своих скриптов, и других фич. прислушайтесь что говорит nightfly "...не запрещает безконечно долго и успешно масштабироваться по горизонтали не ограничивая себя какой-то там заданной топологией и местоположением сети.", а ведь не зря говорит, нужно не в штыки лезть, а хотя бы вникнуть в его слова nightfly +1

да действительно, перезапись произходит при изменении любого параметра но если подумать, изменение userdata3 (в моём случае) это и есть изменение одного из параметров, но скорее всего дело в том что меняет не конфигуратор

HeidiSQL - это виндовый GUI клиент к MySQL почему тогда он скидывает адрес предыдущего соединения? секция purestg сейчас работает без дебага, так что до следующего запуска ждём

stg работает не в дебаге, так что в логах инфы по существу никакой, заметил вот что опишу подробно: юзер цепляется и через некоторое время отклчюается, открываю конфигуратор, смотрим карточку клиента, там опция ipparamsave успешно отображена цепляемся к базе напрямую (у меня HeidiSQL), а там это поле пустое... добавляю в учётку ещё один адрес с которого можно цепляться, цепляюсь успешно, отключаюсь, опять смотрю базу а там ip адрес от предыдущего коннекта как будто стг забывает записать в базу и держит в себе, а потом путает

заметил не всегда происходит запись ipparamsave

Zero_real, объясни пожалуйста для чего нужно это делать в конфигураторе? скрипты биллинга (включая шейпер и прочие плюшки) можно настроить так чтобы туда никогда не лазить, они будут обратывать нужные вам поля конфигурации юзера/тарифов, остаётся лишь добавлять, удалять, править тарифы или пользователей, а всё остальное они будут до вас доделывать, а вот другое дело если "лень" или "не умею" тогда поручите это тому кто с *nix-ами на ты.

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

заметил такой баг: ставим юзеру через виндовый конфигуратор кредит с таймаутом например 8 мая затем смотрим с КК и видим creditExpire=2011-05-07 проверяем виндовым конфигуратором там синим подсвечивается 8 число если же таймаут кредита ставить через КК тогда всё в порядке, и там и там отображается одно и то же число

Алексей подскажи что означает purestg2: ERROR: checkUserTimeouts failed? сыпется каждую секунду в логи стг, а то собрал машинку для тестов

у меня в веб кабинете пользователя при отрицательном балансе появляется кнопка "обещаный платёж" сроком действия на 5 дней, но даётся только 1 раз в месяц, очень удобно если не получилось своевременно оплатить