Перейти к содержимому
Калькуляторы

Всем привет, тестируем в сети Accel 1.10.3. IPoE DHCP. В связи с чем появился вопрос - когда клиент авторизуется, и ему выдает адрес с короткой лизой, то больше запросов на RADIUS не приходит, и если заблокировать абонента (начать выдавать Access-Reject) сессия так и продолжает висеть активной.

Есть ли опция, которая позволяет повторять запросы к радиусу, когда от клиента приходит DHCP Request на продление лизы, чтобы в этот момент можно было сменить абоненту адрес?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Немного не понятно, как после Access-Accept вы хотите отдать Access-Reject, авторизация уже прошла. Сбрасывайте сессию POD или используйте soft-terminate=1, данный механизм ответит NAK на продление лизы по истечению session-timeout и accel-ppp вновь обратится к RADIUS для назначения новых сетевых параметров клиенту.

Изменено пользователем Dimka88

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

или используйте soft-terminate=1

Спасибо - это именно то, что было нужно.

 

А не сталкивались с

radius:BUG: rpd not found

?

Происходит при закрытии сессии и accel падает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А не сталкивались с

radius:BUG: rpd not found

?

Происходит при закрытии сессии и accel падает.

Делайте корку, и отправляйте xeb(у) на на почту. Именно по багам, неплохо было бы писать на форуме автора accel-ppp.org

ps:// accel-ppp обновите, кстати.

Изменено пользователем Dimka88

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С последней версией то-же самое. Закрывается сессия и вместо переоткрытия падает accel.

 

Конфиг:

 

[modules]

log_file

ipoe

radius

ippool

shaper

 

[core]

log-error=/var/log/accel-ppp/core.log

thread-count=4

 

[common]

#single-session=replace

#sid-case=upper

#sid-source=seq

 

[ipoe]

verbose=10

username=ifname

#password=username

lease-time=120

renew-time=60

max-lease-time=1200

unit-cache=1000

#l4-redirect-table=4

#l4-redirect-ipset=l4

l4-redirect-on-reject=300

l4-redirect-ip-pool=nomoney

shared=1

ifcfg=1

mode=L2

start=dhcpv4

ip-unnumbered=1

#proxy-arp=0

#nat=0

#proto=100

#relay=10.10.10.10

#attr-dhcp-client-ip=DHCP-Client-IP-Address

#attr-dhcp-router-ip=DHCP-Router-IP-Address

#attr-dhcp-mask=DHCP-Mask

#attr-dhcp-lease-time=DHCP-Lease-Time

#attr-dhcp-opt82=DHCP-Option82

#attr-dhcp-opt82-remote-id=DHCP-Agent-Remote-Id

#attr-dhcp-opt82-circuit-id=DHCP-Agent-Circuit-Id

#attr-l4-redirect=L4-Redirect

#attr-l4-redirect-table=4

#attr-l4-redirect-ipset=l4-redirect

local-net=172.16.0.0/16

#lua-file=/etc/accel-ppp.lua

#offer-delay=0,100:100,200:200,-1:1000

vlan-mon=eth1,10-200

#vlan-timeout=60

vlan-name=%I.%N

#ip-pool=ipoe

idle-timeout=120

session-timeout=120

soft-terminate=1

check-mac-change=1

#calling-sid=mac

interface=re:^eth1.*$

gw-ip-address=172.16.1.1/24

gw-ip-address=172.16.2.1/24

gw-ip-address=172.16.254.1/24

gw-ip-address=172.16.255.1/24

 

 

[dns]

#dns1=172.16.0.1

#dns2=172.16.1.1

 

[radius]

#dictionary=/usr/local/share/accel-ppp/radius/dictionary

nas-identifier=accel-ppp

nas-ip-address=127.0.0.1

#gw-ip-address=192.168.100.1

server=127.0.0.1,testing123,auth-port=1812,acc-port-1813,req-limit=50,fail-timeout=0,max-fail=10,weight=1

dae-server=127.0.0.1:3799,testing123

verbose=10

timeout=3

max-try=3

acct-timeout=0

acct-interim-interval=0

#acct-delay-time=0

#acct-on=0

#attr-tunnel-type=My-Tunnel-Type

 

[client-ip-range]

10.0.0.0/8

 

[ip-pool]

#vendor=Cisco

#attr=Cisco-AVPair

attr=Framed-Pool

gw-ip-address=172.16.1.1/24

gw-ip-address=172.16.2.1/24

gw-ip-address=172.16.254.1/24

gw-ip-address=172.16.255.1/24

172.16.255.2-255,name=nomoney

172.16.254.2-255,name=invalid

172.16.1.2-255,name=grey

172.16.2.2-255,name=white

 

[log]

log-file=/var/log/accel-ppp/accel-ppp.log

log-emerg=/var/log/accel-ppp/emerg.log

log-fail-file=/var/log/accel-ppp/auth-fail.log

log-debug=/dev/stdout

#syslog=accel-pppd,daemon

#log-tcp=127.0.0.1:3000

copy=1

#color=1

#per-user-dir=per_user

#per-session-dir=per_session

#per-session=1

level=3

 

[shaper]

#attr=Filter-Id

#down-burst-factor=0.1

#up-burst-factor=1.0

#latency=50

#mpu=0

#mtu=0

#r2q=10

#quantum=1500

#moderate-quantum=1

#cburst=1534

#ifb=ifb0

up-limiter=police

down-limiter=tbf

#leaf-qdisc=sfq perturb 10

#leaf-qdisc=fq_codel [limit PACKETS] [flows NUMBER] [target TIME] [interval TIME] [quantum BYTES] [[no]ecn]

#rate-multiplier=1

#fwmark=1

verbose=1

 

[cli]

verbose=1

telnet=127.0.0.1:2000

tcp=127.0.0.1:2001

#password=123

 

 

 

 

Лог:

 

[2016-09-11 12:31:45]: msg: accel-ppp version 1.11.0

[2016-09-11 12:32:40]: info: ipoe0: send [RADIUS(1) Access-Request id=1 <User-Name "eth1.20"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port 422> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "3a:39:63:61:37:39"> <Called-Station-Id "eth1.20"> <User-Password >]

[2016-09-11 12:32:40]: info: ipoe0: recv [RADIUS(1) Access-Accept id=1 <Session-Timeout 120> <Framed-Pool "grey">]

[2016-09-11 12:32:40]: info: ipoe0: eth1.20: authentication succeeded

[2016-09-11 12:32:50]: info: ipoe0: ipoe: session finished

[2016-09-11 12:33:16]: info: ipoe0: send [RADIUS(1) Access-Request id=1 <User-Name "eth1.20"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port 422> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "3a:39:63:61:37:39"> <Called-Station-Id "eth1.20"> <User-Password >]

[2016-09-11 12:33:16]: info: ipoe0: recv [RADIUS(1) Access-Accept id=1 <Session-Timeout 120> <Framed-Pool "grey">]

[2016-09-11 12:33:16]: info: ipoe0: eth1.20: authentication succeeded

[2016-09-11 12:33:16]: info: ipoe0: send [RADIUS(1) Accounting-Request id=1 <User-Name "eth1.20"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port 422> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "3a:39:63:61:37:39"> <Called-Station-Id "eth1.20"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "defecdef8cb3aecf"> <Acct-Session-Time 0> <Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Input-Packets 0> <Acct-Output-Packets 0> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 172.16.1.3>]

[2016-09-11 12:33:16]: info: ipoe0: recv [RADIUS(1) Accounting-Response id=1]

[2016-09-11 12:33:16]: info: ipoe0: ipoe: session started

[2016-09-11 12:35:16]: msg: ipoe0: session timeout

[2016-09-11 12:35:52]: info: ipoe0: send [RADIUS(1) Accounting-Request id=1 <User-Name "eth1.20"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port 422> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "3a:39:63:61:37:39"> <Called-Station-Id "eth1.20"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "defecdef8cb3aecf"> <Acct-Session-Time 120> <Acct-Input-Octets 984> <Acct-Output-Octets 1412> <Acct-Input-Packets 3> <Acct-Output-Packets 11> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 172.16.1.3> <Acct-Terminate-Cause Session-Timeout>]

[2016-09-11 12:35:52]: info: ipoe0: ipoe: session finished

[2016-09-11 12:35:52]: info: recv [RADIUS(1) Accounting-Response id=1]

[2016-09-11 12:35:52]: info: ipoe0: send [RADIUS(1) Access-Request id=1 <User-Name "eth1.20"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port 422> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "3a:39:63:61:37:39"> <Called-Station-Id "eth1.20"> <User-Password >]

[2016-09-11 12:35:52]: info: ipoe0: recv [RADIUS(1) Access-Accept id=1 <Session-Timeout 120> <Framed-Pool "grey">]

[2016-09-11 12:35:52]: info: ipoe0: eth1.20: authentication succeeded

[2016-09-11 12:35:52]: info: ipoe0: send [RADIUS(1) Accounting-Request id=1 <User-Name "eth1.20"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port 422> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "3a:39:63:61:37:39"> <Called-Station-Id "eth1.20"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "defecdef8cb3aed0"> <Acct-Session-Time 0> <Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Input-Packets 0> <Acct-Output-Packets 0> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 172.16.1.4>]

[2016-09-11 12:35:52]: info: ipoe0: recv [RADIUS(1) Accounting-Response id=1]

[2016-09-11 12:35:52]: info: ipoe0: ipoe: session started

[2016-09-11 12:37:52]: msg: ipoe0: session timeout

[2016-09-11 12:38:36]: info: ipoe0: send [RADIUS(1) Accounting-Request id=1 <User-Name "eth1.20"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port 422> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "3a:39:63:61:37:39"> <Called-Station-Id "eth1.20"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "defecdef8cb3aed0"> <Acct-Session-Time 120> <Acct-Input-Octets 984> <Acct-Output-Octets 1412> <Acct-Input-Packets 3> <Acct-Output-Packets 11> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 172.16.1.4> <Acct-Terminate-Cause Session-Timeout>]

[2016-09-11 12:38:36]: info: ipoe0: ipoe: session finished

[2016-09-11 12:38:36]: info: recv [RADIUS(1) Accounting-Response id=1]

 

 

Иногда не с первого раза падает.

получил core dump сейчас напишу на форуме проекта.

Изменено пользователем SABRE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добавил

gw-ip-address=172.16.1.1/24
gw-ip-address=172.16.2.1/24
gw-ip-address=172.16.254.1/24
gw-ip-address=172.16.255.1/24

В секцию radius - падения прекратились, только не совсем понятно зачем одни и те же веши писать одновременно в три секции.

 

Update: не прекратились.

Изменено пользователем SABRE

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Update: не прекратились.

Поискал по ветке, мне помогло в секции радиус установка req-limit=100. Если accel-ppp был собран с дебагом, думаю xeb сможет найти багу.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добавил

gw-ip-address=172.16.1.1/24
gw-ip-address=172.16.2.1/24
gw-ip-address=172.16.254.1/24
gw-ip-address=172.16.255.1/24

В секцию radius - падения прекратились, только не совсем понятно зачем одни и те же веши писать одновременно в три секции.

 

Update: не прекратились.

 

А вы с Git'a собирали?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет, качал релиз.

 

Лучше с Git'a там в основном все поправки для IPoE

Изменено пользователем arhead

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

req-limit=100

пробовал поменять - падает стабильно по завершении сессии.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может кто подскажет как в accelppp сделать так, чтобы при аутентификации pptp, он слал нормальный уникальный NAS-port. А то в какой-то версии это штука поломалась. В 1.10.3 и 1.11.0 там просто убрали, посылку этих пакетов, но в 1.7.3 она точно работало. А то у нас в BGBilling радиус сервер идентифицирует сессии по атрибуту NAS-Port. Самое то главное что ipoe работает нормально, а pptp нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может кто подскажет как в accelppp сделать так, чтобы при аутентификации pptp, он слал нормальный уникальный NAS-port. А то в какой-то версии это штука поломалась. В 1.10.3 и 1.11.0 там просто убрали, посылку этих пакетов, но в 1.7.3 она точно работало. А то у нас в BGBilling радиус сервер идентифицирует сессии по атрибуту NAS-Port. Самое то главное что ipoe работает нормально, а pptp нет.

Эта штука не поломалась. То есть, это не бага, а фича. Дело в том, что новый аксель создает пользовательский интерфейс после того как прошла успешная авторизация. Другими словами, когда шлется access-request, то на этом этапе еще нет номера порта, поэтому шлется <NAS-Port 4294967295> <NAS-Port-Id ""> Делается, это для того, чтобы не создавать лишнюю нагрузку на ядро при ненужном создании/удалении интерфейсов для юзеров, у которых закрытые лицевые счета.

Получить номер порта можно из Accounting-Request. Там уже есть правильная информация: <NAS-Port 1189> <NAS-Port-Id "ppp1189">

Так что если у вас биллинг завязан на этом атрибуте именно в аксесс реквесте, то придется понижать версию до 1.9.0

Ну или пинайте биллинг, пусть берут из акаунтинга.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

один из абонент(белый ip+ pppoe) был участником ddos атаки(tcp(3К сессий) +udp (500k-1.5M сессий)) .Сработал fastnetmon по pps(2000) и flow(1000) и я его временно отключил.

как бы подрезать кол сессий на интерфейсе абонента ? также как на https://habrahabr.ru/post/209298/

 

> show configuration services ids    
rule nat_max_flows {
   match-direction input;
   term t10 {
       from {
           applications all_udp;
       }
       then {
           session-limit {
               by-source {
                   maximum 400;
               }
           }
       }
   }

Изменено пользователем yazero

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А не проще ли заставить абонента почистить комп?

Не хочет? - систематический блекхол на транзите и редирект на информационную страницу.

И так не хочет? - объяснить что его устройство наносит ущерб телекомуникационной сети и это уголовно наказуемо

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Работали мои IPOE BRASы под accel, с vlan per user и QinQ на серверах HP, и были там бортовые броадкомовские сетевки.

Народ эти сетевки хаял на форумах, но они работали, кушать не просили.

 

Однажды в голову пришла идея поменять их на классику - intel ET, воткнул сразу про запас пару 4ех портовых карточек на 82580.

В итоге - на бортовом броадкоме очереди работали для QinQ трафика(хоть и кривовато сами по себе там очереди сделаны), а на интеле - фиг, все в одну очередь падает.

У кого-то подобная конструкция работает? Была тут тема про 82599 и такое же поведение с qinq, но неужели обычные IGB-сетевки так же работают?

IGB собрал последний 5.3.5.3 сайта интела.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

echo ffffff >/sys/class/net/eth0/queues/rx-0/rps_cpus

...

echo ffffff >/sys/class/net/eth0/queues/rx-7/rps_cpus

Где-то так, подстраивайте под ваше количество процов/ядер и очередей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С RPS все зашуршало как надо, спасибо что напомнили.

Хваленая интеловская разбивка по очередям для qinq трафика не работает принципиально что ли?

Нашел в этой теме, уже жаловался народ. Значит не судьба.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

народ какие правила пишите на брасах в forward ?

у себя только

$IPT -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
#3K  для TCP  
$IPT -A FORWARD -s 10.1.1.0/24 -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m connlimit --connlimit-above 3000 --connlimit-mask 32 -j TARPIT
#dhcp
$IPT -A FORWARD -p udp -m udp --dport 67:68 -j DROP
#netbios
$IPT -A FORWARD -p tcp -m tcp --dport 137:139 -j DROP
#troyan
$IPT -A FORWARD -p tcp -m tcp --dport 31337 -j DROP
#windows remote access
$IPT -A FORWARD -p tcp -m tcp --dport 512:514 -j DROP
#windows remote access
$IPT -A FORWARD -p udp -m udp --dport 512:514 -j DROP
#sunrpc
$IPT -A FORWARD -p tcp -m tcp --dport 111 -j DROP
#sunrpc
$IPT -A FORWARD -p udp -m udp --dport 111 -j DROP
#systat
$IPT -A FORWARD -p tcp -m tcp --dport 11 -j DROP
#tftp
$IPT -A FORWARD -p udp -m udp --dport 67:68 -j DROP
#tftp
$IPT -A FORWARD -p tcp -m tcp --dport 67:68 -j DROP
#snmp
$IPT -A FORWARD -p udp -m udp --dport 161:162 -j DROP
#snmptrap
$IPT -A FORWARD -p tcp -m tcp --dport 161:162 -j DROP
#ms-windows-ds
$IPT -A FORWARD -p udp -m udp --dport 445 -j DROP
#ms-windows-ds
$IPT -A FORWARD -p tcp -m tcp --dport 445 -j DROP

на коммутаторах эти правила тоже есть - 445,137,139 и .т.п.

Изменено пользователем yazero

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что-то мне подсказывает, что ваши правила уместятся намного компактнее в ipset bitmap:port

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня подобные правила "для защиты физиков" прописаны так

-A FORWARD -p tcp -m multiport --destination-port 21,22,23,25,53,67,69,80,135,136,137,139,161,445,3128,3389,8080 -j DROP
-A FORWARD -p udp -m multiport --destination-port 53,67,69,135,136,137,139,161 -j DROP

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите, если в конфиге bras указаны два радиус сервера и в ходе сессии абонента отказывает тот, который дал для него access-accept, то аккаунтинг в interim-update будет отсылаться на второй радиус? Или это касается только стартов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2kayot

2nuclearcat

ок перепишу правила, а что то еще прописываете ?

как боритесь с syn_flood и udp_flood от абонента, может быть unicast_storm на порту коммутатора ?

или conntrack отключен на accel-ppp ?

Изменено пользователем yazero

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так что выходит если физик белый адрес берёт он не может использовать у себя 21,22,23,3389,80 и прочее (Ну понятное дело, что это всё вредить может) ? Я фильтрую только DNS flood через

-A FORWARD -d X.X.X.X/32 -p tcp -m tcp --dport 53 -j DROP

Изменено пользователем hsvt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

hsvt

У меня всем белые адреса выдаются, соотвественно в сторону абонента все потенциально опасное блокируется. За небольшую сумму эти блокировки отключаются, обычно юрикам нужно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.