Jump to content
Калькуляторы

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

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

Share this post


Link to post
Share on other sites

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

Edited by Dimka88

Share this post


Link to post
Share on other sites

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

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

 

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

radius:BUG: rpd not found

?

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

Share this post


Link to post
Share on other sites

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

radius:BUG: rpd not found

?

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

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

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

Edited by Dimka88

Share this post


Link to post
Share on other sites

С последней версией то-же самое. Закрывается сессия и вместо переоткрытия падает 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 сейчас напишу на форуме проекта.

Edited by SABRE

Share this post


Link to post
Share on other sites

Добавил

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: не прекратились.

Edited by SABRE

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Добавил

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 собирали?

Share this post


Link to post
Share on other sites

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

 

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

Edited by arhead

Share this post


Link to post
Share on other sites

req-limit=100

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Может кто подскажет как в 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

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

Share this post


Link to post
Share on other sites

один из абонент(белый 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;
               }
           }
       }
   }

Edited by yazero

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

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

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

Share this post


Link to post
Share on other sites

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

...

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

народ какие правила пишите на брасах в 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 и .т.п.

Edited by yazero

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

-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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

2kayot

2nuclearcat

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

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

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

Edited by yazero

Share this post


Link to post
Share on other sites

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

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

Edited by hsvt

Share this post


Link to post
Share on other sites

hsvt

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now