[NiTr0]

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

Эм... Крон, http вместо радиуса, скрипты... Резать в iptables.

Мы так локалку должникам режем. Роутер смотрит присутствующие подсети на интерфейсах, для каждой из подсетей формирует свою цепочку в иптейблсе, с финалом в виде редиректа на цепочку запрета, и шлет запрос статуса подсети к скрипту биллинга. Биллинг выплевывает список адресов со статусом (0 - блокировать, 1 - разрешать), скрипт парсит результат и для активных адресов в табличку заносит правила с -j RETURN.

 

Делалось в 2008-м, незаметно работает для большого кол-ва абонов на старых машинах (сокет 775) хоть и трафика там практически нет; сейчас бы заюзал ipset - но переделывать нафиг надо.

[wtyd]

Подобный самопал тоже есть, реализован на ipset, управляет как ни странно pptp серверами с accel-pptp :-). Но мне не нравятся там некоторые "жёсткие" моменты, переделывать уже ломает, вот и решил готовых решений поискать.

[m9ic]

Здравствуйте. Пытаюсь заставить работать accel в кач-ве ipoe bras.

Сейчас в ядре стоит cisco 3550,на ней настроен ip unnumbered и relay на dhcp (он же биллинг, который по карточке абонента генерит конфиг для dhcp), opt.82 вставляют коммутаторы доступа (vlan на дом). Получается ip прибиты к порту, вне зависимости от того, онлайн ли клиент.

Хочется выдавать ip через радиус, только тем, кому это нужно. Выдаем белые ip.

Собрал accel-ppp version a79b3fb7c894cd5a8eddac5679a986722390ff59

кусок конфига:

 

 

[ipoe]
gw-ip-address=77.35.xx.1/22 --это адрес, который висит на лупбеке 3550
verbose=5
username=lua:username
password=username
lease-time=600
max-lease-time=3600
#unit-cache=1000
#l4-redirect-table=4
#l4-redirect-ipset=l4
#l4-redirect-on-reject=300
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-l4-redirect=L4-Redirect
#local-net=192.168.0.0/16
lua-file=/etc/accel-ppp.lua
#offer-delay=0,100:100,200:200,-1:1000
#vlan-mon=eth0,10-200
#vlan-timeout=60
#vlan-name=%I.%N
#ip-pool=ipoe
interface=eth1


[dns]
dns1=172.16.0.11
dns2=172.16.0.12

[radius]
dictionary=/usr/local/share/accel-ppp/radius/dictionary
nas-identifier=test
nas-ip-address=172.16.0.21
server=172.16.0.10,123456,auth-port=1812,acct-port=1813,req-limit=0,fail-time=0,weight=1
dae-server=172.16.0.21:3799,123456
verbose=5
#timeout=3
#max-try=3
#acct-timeout=120
#acct-delay-time=0
#acct-on=0
#attr-tunnel-type=My-Tunnel-Type

 

 

подключаю тестового клиента:

вывод accel-ppp.log

 

 

[2014-07-13 18:33:51]:   msg: accel-ppp version a79b3fb7c894cd5a8eddac5679a986722390ff59
[2014-07-13 18:33:55]:  info: ipoe0: send [RADIUS(1) Access-Request id=1 <User-Name "48.46.53.50-51"> <NAS-Identifier "test"> <NAS-IP-Address 172.16.0.21> <NAS-Port 4438> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "00:0f:02:68:61:88"> <Called-Station-Id "eth1"> <User-Password >]
[2014-07-13 18:33:55]:  info: ipoe0: recv [RADIUS(1) Access-Accept id=1 <Acct-Interim-Interval 300> <Framed-IP-Address 77.35.xx.99>]
[2014-07-13 18:33:55]:  info: ipoe0: 48.46.53.50-51: authentication succeeded
[2014-07-13 18:34:05]:  info: ipoe0: ipoe: session finished
[2014-07-13 18:34:09]:  info: ipoe0: send [RADIUS(1) Access-Request id=1 <User-Name "48.46.53.50-51"> <NAS-Identifier "test"> <NAS-IP-Address 172.16.0.21> <NAS-Port 4439> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "00:0f:02:68:61:88"> <Called-Station-Id "eth1"> <User-Password >]
[2014-07-13 18:34:10]:  warn: radius:dm_coa: RA validation failed
[2014-07-13 18:34:12]:  info: ipoe0: send [RADIUS(1) Access-Request id=1 <User-Name "48.46.53.50-51"> <NAS-Identifier "test"> <NAS-IP-Address 172.16.0.21> <NAS-Port 4439> <NAS-Port-Id "ipoe0"> <NAS-Port-Type Ethernet> <Calling-Station-Id "00:0f:02:68:61:88"> <Called-Station-Id "eth1"> <User-Password >]
[2014-07-13 18:34:12]:  info: ipoe0: recv [RADIUS(1) Access-Reject id=1 <Reply-Message "
You are already logged in - access denied

 

 

В общем оно и понятно, до клиента не долетает ответ dhcp, он опять шлет request.

tcpdump с accel'я

 

 

tcpdump -n -i eth1 -s 0 -v -vv port 67
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
17:43:06.852510 IP (tos 0x0, ttl 255, id 53622, offset 0, flags [none], proto UDP (17), length 358)
   77.35.xx.1.67 > 172.16.0.21.67: [udp sum ok] BOOTP/DHCP, Request from 00:0f:02:68:61:88, length 330, hops 1, xid 0x8b10de06, secs 5082, Flags [none] (0x0000)
         Gateway-IP 77.35.xx.1
         Client-Ethernet-Address 00:0f:02:68:61:88
         Vendor-rfc1048 Extensions
           Magic Cookie 0x63825363
           DHCP-Message Option 53, length 1: Discover
           Client-ID Option 61, length 7: ether 00:0f:02:68:61:88
           Parameter-Request Option 55, length 12:
             Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
             Domain-Name, MTU, BR, Static-Route
             NTP, Netbios-Name-Server, Classless-Static-Route, Classless-Static-Route-Microsoft
           Vendor-Class Option 60, length 12: "udhcp 1.21.0"
           Hostname Option 12, length 9: "Wive-RTNL"
           Agent-Information Option 82, length 36:
             Circuit-ID SubOption 1, length 19: Vlan800/Ethernet1/3
             Remote-ID SubOption 2, length 13: 172.16.200.52
           END Option 255, length 0
17:43:06.920122 IP (tos 0x0, ttl 64, id 9321, offset 0, flags [DF], proto UDP (17), length 306)
   172.16.0.21.67 > 77.35.xx.1.68: [bad udp cksum 0x6e79 -> 0x80ec!] BOOTP/DHCP, Reply, length 278, hops 1, xid 0x8b10de06, secs 5082, Flags [none] (0x0000)
         Your-IP 77.35.xx.99
         Server-IP 77.35.xx.1
         Gateway-IP 77.35.xx.1
         Client-Ethernet-Address 00:0f:02:68:61:88
         Vendor-rfc1048 Extensions
           Magic Cookie 0x63825363
           DHCP-Message Option 53, length 1: Offer
           Server-ID Option 54, length 4: 77.35.xx.1
           Lease-Time Option 51, length 4: 600
           Default-Gateway Option 3, length 4: 77.35.xx.1
           Subnet-Mask Option 1, length 4: 255.255.252.0
           Domain-Name-Server Option 6, length 8: 172.16.0.11,172.16.0.12
           END Option 255, length 0

 

 

debug с cisco 3550

 

 

Jul 13 06:45:20.578: DHCPD: incoming interface name is Vlan800
Jul 13 06:45:20.578: DHCPD: bad circuit id length (19 bytes)
Jul 13 06:45:20.578: DHCPD: Looking up binding using address 77.35.xx.1
Jul 13 06:45:20.578: DHCPD: setting giaddr to 77.35.xx.1.n
Jul 13 06:45:20.578: DHCPD: leaving relay information in tact.
Jul 13 06:45:20.578: DHCPD: BOOTREQUEST from 0100.0f02.6861.88 forwarded to 172.16.0.21.o m

 

 

interface Vlan800
ip unnumbered Loopback2  -- 77.35.xx.1/22
ip helper-address 172.16.0.21

Больше всего смущает

172.16.0.21.67 > 77.35.xx.1.68: [bad udp cksum 0x6e79 -> 0x80ec!]

Если подключаю коммутатор во вторую сетевуху accel'я все замечательно работает

Есть какие-нибудь предположения, почему так происходит?

Изменено 13 июля, 2014 пользователем m9ic

[NiTr0]

Есть какие-нибудь предположения, почему так происходит?

Может, потому что вы пытаетесь l3-connected клиентов с непонятной целью заставить работать как l2-connected?

 

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

 

Выкиньте кошку, выдавайте радиусом адреса всем - кому белые, кому серые, и будет счастье....

[m9ic]

Накой вам промежуточная кошка?

Оставить на ней локальный трафик.

Ну или зачем пытаться выдавать адреса радиусом, если у вас подсети и так прибиты к сегментам жестко?

У меня один лупбек, на него повешена /22 сеть, если выдавать через радиус, то адресов с большим запасом, а если генерить конфиг для dhcp на каждого пользователя, то нет. Тут где-то в соседней теме читал, что не обязательно вещать подсеть на лупбек и в таком случае можно выдавать любые адреса.

Выкиньте кошку, выдавайте радиусом адреса всем - кому белые, кому серые, и будет счастье....

Слишком глобальные перемены, относительно недавно все переделали.

Может, потому что вы пытаетесь l3-connected клиентов с непонятной целью заставить работать как l2-connected?

Думаю так и есть :)

Но есть ли шанс, что схема взлетит?

Клиент отправляет discover - коммутатор доступа вставляет opt.82 - cisco 3550 релеит запрос на accel - accel спрашивает у радиуса и отвечает клиенту - циска создает на себе маршрут - клиент получает адреса.

[xeb]

l3-connected схема с dhcp не реализована

[wtyd]

Думаю так и есть :)

Но есть ли шанс, что схема взлетит?

Клиент отправляет discover - коммутатор доступа вставляет opt.82 - cisco 3550 релеит запрос на accel - accel спрашивает у радиуса и отвечает клиенту - циска создает на себе маршрут - клиент получает адреса.

 

Я не знаю на счёт именно вашей кошки, но по идее кошки давно это умеют без accel: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_dhcp/configuration/15-s/dhcp-15-s-book/dhcp-serv-rad-proxy.html#GUID-7729657D-4890-4B86-BE3D-47FB1B95CDB7

 

Сам не пробовал, но читал :-). Как вариант: если l3-connected схема с dhcp не реализована, то может быть функционал с раздачей dhcp через радиус возложить на цыску и радиус, а контроль доступа сделать через accel-ppp ipoe l3-connected, но по юникаст пакету (если реализовано, я этого тоже не знаю и не пробовал :-)).

[NiTr0]

Оставить на ней локальный трафик.

Его настолько много, что о нем стоит беспокоиться?

 

а если генерить конфиг для dhcp на каждого пользователя, то нет.

А нафига генерить какой-то там конфиг? Религия не позволяет нормальный дхцп сервер, который с БД работает, заюзать?

 

cisco 3550 релеит запрос на accel - accel спрашивает у радиуса и отвечает клиенту - циска создает на себе маршрут

аксель отвечает не рилею в этой схеме, т.к. с рилеями не работает; куда идет пакет - хз (надо смотреть дампы/код), но точно не рилеится нормально.

 

если l3-connected схема с dhcp не реализована, то может быть функционал с раздачей dhcp через радиус возложить на цыску и радиус, а контроль доступа сделать через accel-ppp ipoe l3-connected

Зачем плодить сущности, если контроль доступа можно реализовать через дхцп выдачей серых адресов гостевого пула?

[m9ic]

l3-connected схема с dhcp не реализована

Есть планы на реализацию?

[m9ic]

Его настолько много, что о нем стоит беспокоиться?

Мбит 300 в худшем случае. Поставить тазик, притянуть в нему vlan'ы и не заморачиваться?

А нафига генерить какой-то там конфиг? Религия не позволяет нормальный дхцп сервер, который с БД работает, заюзать?

Но для этого в базе так же должны быть прибиты адреса к пользователям, так какая тогда разница (ну кроме того, что каждый раз при смене конфига дергать дхцп - не комильфо)? Как без радиуса узнать, что адрес уже свободен?

Зачем плодить сущности, если контроль доступа можно реализовать через дхцп выдачей серых адресов гостевого пула?

Мы должникам навешиваем шейпер 128 кбит и отправляем смску.

[NiTr0]

Мбит 300 в худшем случае. Поставить тазик, притянуть в нему vlan'ы и не заморачиваться?

Угу.

 

Но для этого в базе так же должны быть прибиты адреса к пользователям, так какая тогда разница (ну кроме того, что каждый раз при смене конфига дергать дхцп - не комильфо)? Как без радиуса узнать, что адрес уже свободен?

Говорю же - дхцп сервер, работающий не с файлами а с БД. Ничего дергать не надо. Обычное управление лизами. Есть тута дхцп сервер на перле, там вроде как управление изами надо самому дописать (ну и с биллингом увязать) - но ничего сложного нет.

 

Мы должникам навешиваем шейпер 128 кбит и отправляем смску.

А можно заворачивать в серый пул, который собссно и шейпится по 128к...

[Abram]

DHCP нынче проще написать прямо во FreeRADIUS-е. Он на себя берёт все низкоуровневые задачи, остаётся написать только логику.

[NiTr0]

DHCP нынче проще написать прямо во FreeRADIUS-е. Он на себя берёт все низкоуровневые задачи, остаётся написать только логику.

Ну какбы на перле он уже написан, работает стабильно, нагрузка небольшая - только работу с базой реализовать под имеющуюся БД... И фрирадиус вроде как не сильно облегчает задачу по сравнению даже с перловыми библиотеками...

[Abram]

DHCP нынче проще написать прямо во FreeRADIUS-е. Он на себя берёт все низкоуровневые задачи, остаётся написать только логику.

Ну какбы на перле он уже написан, работает стабильно, нагрузка небольшая - только работу с базой реализовать под имеющуюся БД... И фрирадиус вроде как не сильно облегчает задачу по сравнению даже с перловыми библиотеками...

У меня тоже на перле написан. Внутри FreeRADIUS проще.

[Victor Safronov]

А вот у меня назрел очень неожиданный фичереквест. Почти все наши VPN-щики подключаются по PPTP/L2TP, как им бог на душу положит. При этом есть некоторое количество клиентов, для которых настроены IPIP-туннели. Проблема в том, что у нас нет какого-то механизма устанавливать шейпинг на эти туннели по информации из биллинга. Даже если вешать правила при загрузке системы своими костылями, то нет возможности штатно менять скорость по временным интервалам, например. Поэтому возникает соблазн запихнуть управление этими туннелями внутрь accel-ppp, чтобы независимо от способа туннелирования все настройки шейпинга применялись единообразно.

Как это могло бы выглядеть: некий конфиг-файл, где перечислены необходимые данные для поднятия туннелей (например, логин и удалённый IP). При старте accel-ppp читает эти данные и делает запросы к радиусу для получения клиентского IP и настроек шейпинга, а затем поднимает эти IPIP-туннели. Свой адрес для туннелирования задаётся, например, где-нибудь в секции [ipip], там же шаблон для именования интерфейсов.

Насколько сложно и вообще возможно, и имело бы смысл такое реализовать?

[s.lobanov]

ipip доступ в интернет для эндкастомеров. я даже в России такого нигде не видел

 

проще сделать скрипт, который будет это делать - несколько строка на баше(радклиент, тс, греп, авк)

[Abram]

Насколько сложно и вообще возможно, и имело бы смысл такое реализовать?

Это явно выходит за рамки accel-ppp.

[Victor Safronov]

Насколько сложно и вообще возможно, и имело бы смысл такое реализовать?

Это явно выходит за рамки accel-ppp.

Изначально рамки были ограничены одним только протоколом PPTP. Потом они расширились до L2TP, PPPoE, IPoE. Не вижу никаких противоречий с реализацией других туннелей.

[s.lobanov]

PPTP. Потом они расширились до L2TP, PPPoE, IPoE

 

у этих протоколов/технологий есть сигнализация, ipip является stateless. кроме того, у тех способов есть комьюнити, дающее обратную связь, а ipip для доступа в интернет кроме вас никто больше не использует (ну может ещё Saab95 какой-нибудь)

 

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

[Victor Safronov]

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

Одного скрипта достаточно для навешивания статичного шейпинга. accel же умеет "динамическое" шейпирование в зависимости от времени суток, а это значит, что нужно навешивать свои доп. скрипты в крон, которые будут "бегать" по туннелям, изменяя там скорость. Тот же IPoE на мой взгляд тоже изначально stateless и DHCP как сигнализация притянут за уши, но это не мешает поддерживать эту технологию в accel-ppp. Грубо говоря, чисто теоретически можно по аналогии с реализацией того же IPoE просто ждать пакеты с протоколом 94 (как discover) на определённых интерфейсах, через LUA преобразовывать SRC IP в логин и лезть с ним в радиус, и в этот момент создавать IPIP-туннель. А потом гасить его по истечении "аналога" lease-time — вот и вся сигнализация Просто это опять потребует вмешательства в ядерный код родного модуля ipip, да и нафик не нужно. Поэтому я и говорю о полустатическом подходе, когда туннели создаются при запуске и на них навешиваются стандартные штатные шейперы accel, одинаково действующие на всех интерфейсах. Опционально можно периодически повторно лезть в радиус с целью узнать, не изменилось ли состояние и в случае чего гасить туннель обратно, или заворачивать в ipset и т.д.

[SmallFox]

Прошу помощи.

 

msg: accel-ppp version 5e824440c2044a443d73d53650505f55c6c4038b

Создал стенд, accel-ppp +ipoe +q-in-q. не создаются автоматически интерфейсы eth2.99.101

ipoe.ko загружен

 

[ipoe]
ipv6=deny
verbose=1
username=ifname
lease-time=300
max-lease-time=300
attr-dhcp-client-ip=Framed-IP-Address
attr-dhcp-router-ip=DHCP-Router-IP-Address
attr-dhcp-mask=DHCP-Mask
attr-l4-redirect=L4-Redirect
shared=0
proxy-arp=0
proto=100
mode=L2
start=dhcpv4
vlan-timeout=60
vlan-mon=re:eth2\.9[0-9],100-109
vlan-name=%I.%N
interface=re:eth2\.9[0-9]\.10[0-9]

 

Что делаю не так?

 

#ifconfig
eth2.99   Link encap:Ethernet  HWaddr 00:90:27:59:9c:41  
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:2972 errors:0 dropped:0 overruns:0 frame:0
         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0 
         RX bytes:971410 (948.6 KiB)  TX bytes:0 (0.0 B)

[s.lobanov]

Опционально можно периодически повторно лезть в радиус с целью узнать, не изменилось ли состояние и в случае чего гасить туннель обратно, или заворачивать в ipset и т.д.

вот такого точно делать не нужно, для этого нужно использовать CoA

 

и как в вашу схему вписывается ситуация, если появился новый абонент ipip? ведь у вас тунели создаются только при старте(в полустатической схеме)

 

если делать динамическую схему, то да, оно не stateless и это типичная задача bras, но вопрос в том, что никому оно не нужно

[ichthyandr]

Прошу помощи.

 

msg: accel-ppp version 5e824440c2044a443d73d53650505f55c6c4038b

Создал стенд, accel-ppp +ipoe +q-in-q. не создаются автоматически интерфейсы eth2.99.101

ipoe.ko загружен

 

[ipoe]
ipv6=deny
verbose=1
username=ifname
lease-time=300
max-lease-time=300
attr-dhcp-client-ip=Framed-IP-Address
attr-dhcp-router-ip=DHCP-Router-IP-Address
attr-dhcp-mask=DHCP-Mask
attr-l4-redirect=L4-Redirect
shared=0
proxy-arp=0
proto=100
mode=L2
start=dhcpv4
vlan-timeout=60
vlan-mon=re:eth2\.9[0-9],100-109
vlan-name=%I.%N
interface=re:eth2\.9[0-9]\.10[0-9]

 

Что делаю не так?

 

#ifconfig
eth2.99   Link encap:Ethernet  HWaddr 00:90:27:59:9c:41  
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:2972 errors:0 dropped:0 overruns:0 frame:0
         TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:0 
         RX bytes:971410 (948.6 KiB)  TX bytes:0 (0.0 B)

qinq пакеты до сервера доходят?

[kayot]

SmallFox

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

interface=re:eth2\.9[0-9]

[Abram]

SmallFox,

Регулярка в vlan-mon неправильная. Для начала пробовать так:

vlan-mon=eth2.99
interface=re:eth2\.99\.\d*