[xeb]

печалиться не надо, что надо ещё дорабатывать пишите

[xeb]

commit 4e7ed29422fa958ebba78774f6a7745a303eb997
Author: Kozlov Dmitry <xeb@mail.ru>
Date:   Fri Jan 25 11:41:00 2013 +0400

ipoe: insert option 82 to relay request

[ipoe]

agent-remote-id=accel-pppd

[kayot]

С обновлением ipoe не работает совсем, после старта в log/core.log:

[2013-01-25 11:47:19.57]loader: 'ipoe' not found

[kayot]

Спасибо за фикс и их оперативность, ipoe починился.

Баг: relay вставляет option82 в конец пакета, после опции 255 END.

Соответственно софт такие странные пакеты не видит, опции после ENDa игнорируются. У меня сегодня чуть мозг не взорвался пока это отлаживал, tcpdump видит, а другие нет - даже tshark ее показывать отказался :)

 

16:25:39.773996 IP (tos 0x0, ttl 64, id 64222, offset 0, flags [DF], proto UDP (17), length 338)
   10.200.0.100.67 > 10.200.0.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:1a:4b:3b:85:d6, length 310, xid 0xca200acb, secs 7168, Flags [none] (0x0000)
         Gateway-IP 10.200.0.100
         Client-Ethernet-Address 00:1a:4b:3b:85:d6
         Vendor-rfc1048 Extensions
           Magic Cookie 0x63825363
           DHCP-Message Option 53, length 1: Discover
           Client-ID Option 61, length 7: ether 00:1a:4b:3b:85:d6
           Hostname Option 12, length 6: "hp-zik"
           Vendor-Class Option 60, length 8: "MSFT 5.0"
           Parameter-Request Option 55, length 12:
             Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
             Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
             Static-Route, Classless-Static-Route, Classless-Static-Route-Microsoft, Vendor-Option
           END Option 255, length 0
           Agent-Information Option 82, length 23:
             Circuit-ID SubOption 1, length 9: eth1.2001
             Remote-ID SubOption 2, length 10: accel-pppd

END Option 255, length 0 должна быть последней.

 

Ну и вопрос вдогонку. IPOE модуль для vlan на пользователя(shared=0, без драйвера) ведь должен строить маршрут после авторизации пользователя и выдачи ему IP?

Пользователь из vlan 2001 авторизируется радиусом, dhcp выдает ему ip, вижу записи в логах и радиусе об удачном начале сессии и запуске аккаунтинга, а маршрута вида 'ip/32 dev eth1.2001' нет и клиент не доступен.

[xeb]

исправлено

[kayot]

dhcp_relay + option82 работает не верно.

Опция вставляется только для первого пакета, DISCOVER. Последующий REQUEST приходит уже без опции, DHCP-сервер не может завершить согласование.

[Abram]

Опция вставляется только для первого пакета, DISCOVER. Последующий REQUEST приходит уже без опции, DHCP-сервер не может завершить согласование.

Если так - то да, неверно. Опция 82 должна вставляться во все пакеты клиент->сервер, проходящие через релей.

[morfair]

А никто не встречался с такой проблемой? У некоторых клиентов с роутерами подключается на несколько секунд и падает соединение с <Acct-Terminate-Cause User-Error>. Напрямую всё работает.

 

[2012-12-26 14:13:53]:  info: ppp158: send [RADIUS(1) Access-Request id=1 <User-Name "login"> <NAS-Identifier "nas4"> <NAS-IP-Address xx.xx.xx.xx> <NAS-Port 158> <NAS-Port-Type Virtual> <Tunnel-Type PPTP> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.171.92"> <Called-Station-Id "yy.yy.yy.yy"><Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP2-Response >]
[2012-12-26 14:13:53]:  info: ppp158: 171092: authentication succeeded
[2012-12-26 14:14:03]:  info: ppp158: send [RADIUS(1) Accounting-Request id=1 <User-Name "login"> <NAS-Identifier "nas4"> <NAS-IP-Address xx.xx.xx.xx> <NAS-Port 158> <NAS-Port-Type Virtual> <Tunnel-Type PPTP> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.171.92"> <Called-Station-Id "yy.yy.yy.yy"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "07101cdcd74e7bc9"> <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 X.X.X.X>]
[2012-12-26 14:14:08]:  info: ppp158: send [RADIUS(1) Accounting-Request id=1 <User-Name "login"> <NAS-Identifier "nas4"> <NAS-IP-Address xx.xx.xx.xx> <NAS-Port 158> <NAS-Port-Type Virtual> <Tunnel-Type PPTP> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.171.92"> <Called-Station-Id "yy.yy.yy.yy"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "07101cdcd74e7bc9"> <Acct-Session-Time 15> <Acct-Input-Octets 444> <Acct-Output-Octets 124> <Acct-Input-Packets 15> <Acct-Output-Packets 10> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address X.X.X.X> <Acct-Terminate-Cause User-Error>]

 

accel-ppp version 98466f59d258d2079755d2a1808cd34631d9f230

 

Проблема не уходит... За выходные четыре клиента набежало, которым нечего ответить. Вот разве что удалось выяснить, что у всех роутеры D-Link DIR-300 Bx 2.05. Причем они не однозначно не подключаются. Вот у одного было User-Error каждые 3 сек в тчении нескольких часов, попросили его воткнуть в комп - всё заработало, втыкает назад в роутер - всё работает. Что за хрень?....

 

И что с поднятием второй сессии с одного компа? Ошибка 800 для втоого подключения:

[2013-01-24 16:22:22]:  warn: ppp0: unexpected PPTP_OUT_CALL_RQST

Изменено 27 января, 2013 пользователем morfair

[-Ars-]

И что с поднятием второй сессии с одного компа? Ошибка 800 для втоого подключения:

Есть баг:

http://sourceforge.net/tracker/?func=detail&aid=3560238&group_id=390718&atid=1622576

Ждем-с.

[kayot]

А зачем вообще может быть нужна возможность поднятия второй сессии?

[taf_321]

Не собирается ядерный модуль ipoe на ядре 3.7.4:

 

make[3]: Entering directory `/usr/src/linux-3.7.4-std-def-alt1'
 CC [M]  /usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver/ipoe.o
/usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver/ipoe.c: In function 'ipoe_nl_cmd_noop':
/usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver/ipoe.c:1010:29: error: 'struct genl_info' has no member named 'snd_pid'
/usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver/ipoe.c:1022:55: error: 'struct genl_info' has no member named 'snd_pid'
/usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver/ipoe.c: In function 'ipoe_nl_cmd_create':
/usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver/ipoe.c:1071:29: error: 'struct genl_info' has no member named 'snd_pid'
/usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver/ipoe.c:1093:55: error: 'struct genl_info' has no member named 'snd_pid'
/usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver/ipoe.c: In function 'ipoe_nl_cmd_dump_sessions':
/usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver/ipoe.c:1310:46: error: 'struct netlink_skb_parms' has no member named 'pid'
make[4]: *** [/usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver/ipoe.o] Error 1
make[3]: *** [_module_/usr/src/RPM/BUILD/kernel-modules-ipoe-std-def-2.0.0/BUILD/drivers/ipoe/driver] Error 2

 

И действительно, в определениях этих структур указанных элементов нет.

[purecopper]

Как-то странно себя ведет accel при работе с ipoe.

Пытаюсь настроить vlan на пользователя + ip-unnumbered с авторизацией по радиусу.

Насколько я понимаю логику работы, при поступлении запроса DHCP на интерфейс должен создаваться интерфейс eth2.$VLAN + набор правил типа ip route add $USER_IP dev eth2.$VLAN. Но происходит нечто странное - пользователь получает IP-адрес, но интерфейс не поднимается. Т.е. по факту получается этакий dhcp-сервер. :) Сегодня обновился из git до 59a82263d482f74f1405c19fb78f16873f2f8bac. В результате при получении DHCP Discover на eth2 все настройки интерфейса сбрасываются, а в логах accel-ppp видно следующее:

 

 

[2013-01-28 15:28:28]: error: libnetlink: RTNETLINK answers: No such file or directory

[2013-01-28 15:28:28]: error: genl: error talking to kernel

[2013-01-28 15:28:28]: warn: ipoe: unclassified packet handling is disabled

[2013-01-28 15:28:28]: msg: accel-ppp version 59a82263d482f74f1405c19fb78f16873f2f8bac

 

 

 

 

cat /etc/accel-ppp.conf

 

 

[modules]

path=/usr/lib/accel-ppp

log_file

#log_syslog

#log_tcp

#log_pgsql

ipoe

#pptp

#l2tp

#pppoe

 

auth_mschap_v2

auth_mschap_v1

auth_chap_md5

auth_pap

 

radius

#ippool

sigchld

pppd_compat

 

#shaper

#shaper_tbf (obsolete)

#chap-secrets

#net-snmp

#logwtmp

#connlimit

 

#ipv6_nd

#ipv6_dhcp

#ipv6pool

 

[core]

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

thread-count=4

 

[ppp]

verbose=1

min-mtu=1280

mtu=1400

mru=1400

#ccp=0

#sid-case=upper

#check-ip=0

#single-session=replace

#mppe=require

ipv4=require

ipv6=deny

ipv6-intf-id=0:0:0:1

ipv6-peer-intf-id=0:0:0:2

ipv6-accept-peer-intf-id=1

lcp-echo-interval=20

#lcp-echo-failure=3

lcp-echo-timeout=120

#unit-cache=1000

 

[auth]

#any-login=0

#noauth=0

 

[pptp]

#echo-interval=30

#mppe=allow

#ip-pool=pool1

verbose=1

 

[pppoe]

#interface=eth0

#interface=eth1,padi-limit=1000

#ac-name=xxx

#service-name=yyy

#pado-delay=0

#pado-delay=0,100:100,200:200,-1:500

#ifname-in-sid=called-sid

#tr101=1

#padi-limit=0

#mppe=allow

#ip-pool=pool2

verbose=1

 

[l2tp]

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

#hello-interval=60

#timeout=60

#rtimeout=5

#retransmit=5

#host-name=accel-ppp

#dir300_quirk=0

#secret=

#mppe=allow

#ip-pool=pool3

#verbose=1

 

[dns]

dns1=10.11.0.4

dns2=10.11.0.1

 

[wins]

#wins1=172.16.0.1

#wins2=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

#auth-server=127.0.0.1:1812,testing123 (obsolete)

#acct-server=127.0.0.1:1813,testing123 (obsolete)

#server=127.0.0.1,testing123 (obsolete)

server=127.0.0.1,testing123,auth-port=1812,acct-port=1813,req-limit=0,fail-time=0

dae-server=127.0.0.1:3799,testing123

verbose=1

#timeout=3

#max-try=3

#acct-timeout=120

#acct-delay-time=0

 

[client-ip-range]

10.0.0.0/8

 

[ip-pool]

gw-ip-address=192.168.0.1

#vendor=Cisco

#attr=Cisco-AVPair

attr=Framed-Pool

192.168.0.2-255

192.168.1.1-255,pool1

192.168.2.1-255,pool2

192.168.3.1-255,pool3

192.168.4.0/24

 

[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

 

[log-pgsql]

conninfo=user=log

log-table=log

 

[pppd-compat]

#ip-pre-up=/etc/ppp/ip-pre-up

ip-up=/etc/ppp/ip-up

ip-down=/etc/ppp/ip-down

ip-change=/etc/ppp/ip-change

radattr-prefix=/var/run/radattr

verbose=1

 

[chap-secrets]

gw-ip-address=192.168.100.1

#chap-secrets=/etc/ppp/chap-secrets

#encrypted=0

#username-hash=md5

 

[shaper]

#attr=Filter-Id

#down-burst-factor=0.1

#up-burst-factor=1.0

#latency=50

#mpu=0

#r2q=10

#quantum=1500

#cburst=1534

#ifb=ifb0

up-limiter=police

down-limiter=tbf

#leaf-qdisc=sfq perturb 10

verbose=1

 

#tbf is obsolete, use shaper module

#[tbf]

#attr=Filter-Id

#down-burst-factor=0.1

#up-burst-factor=1.0

#latency=50

 

[cli]

telnet=127.0.0.1:2000

tcp=127.0.0.1:2001

#password=123

 

[snmp]

master=0

agent-name=accel-ppp

 

[connlimit]

limit=10/min

burst=3

timeout=60

 

[ipv6-pool]

fc00:0:1::/48,64

delegate=fc00:1::/36,48

 

[ipv6-dns]

#fc00:1::1

#fc00:1::2

#fc00:1::3

#dnssl=suffix1.local.net

#dnssl=suffix2.local.net.

 

[ipv6-dhcp]

verbose=1

pref-lifetime=604800

valid-lifetime=2592000

route-via-gw=1

 

[ipoe]

mode=L2

shared=0

ifcfg=0

start=dhcpv4

verbose=5

lease-time=600

max-lease-time=3600

interface=eth2

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

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

attr-dhcp-mask=DHCP-Mask

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

#username=lua:username

 

 

 

uname -a

 

 

Linux debian 3.2.0-0.bpo.4-rt-amd64 #1 SMP PREEMPT RT Debian 3.2.35-2~bpo60+1 x86_64 GNU/Linux

 

 

 

cmake opt

 

 

cmake -DBUILD_IPOE_DRIVER=TRUE -DCMAKE_INSTALL_PREFIX=/usr -DRADIUS=TRUE -DNETSNMP=FALSE -DLOG_PGSQL=FALSE -DLUA=TRUE -DBUILD_DRIVER=TRUE

 

 

Изменено 28 января, 2013 пользователем purecopper

[xeb]

Насколько я понимаю логику работы, при поступлении запроса DHCP на интерфейс должен создаваться интерфейс eth2.$VLAN

все вланы уже должны быть подняты и указаны в конфиге

 

и логи для отладки надо снимать с:

[log]

level=5

Изменено 28 января, 2013 пользователем xeb

[purecopper]

Вот лог с level=5

 

 

[2013-01-28 15:52:02]: msg: accel-ppp version 59a82263d482f74f1405c19fb78f16873f2f8bac

[2013-01-28 15:52:08]: info: eth2: recv [DHCPv4 Discover xid=2d62a839 chaddr=00:18:f3:3f:37:cd <Message-Type Discover> <Client-ID 010018f33f37cd> <Host-Name test> <Vendor-Class 4d53465420352e30> <Request-List Subnet,Domain-Name,Router,DNS,44,46,47,31,Route,Classless-Route,249,Vendor-Specific>]

[2013-01-28 15:52:09]: error: libnetlink: RTNETLINK answers: No such file or directory

[2013-01-28 15:52:09]: error: genl: error talking to kernel

[2013-01-28 15:52:09]: warn: ipoe: unclassified packet handling is disabled

[2013-01-28 15:52:09]: msg: accel-ppp version 59a82263d482f74f1405c19fb78f16873f2f8bac

 

 

 

Т.е., как я понимаю если у меня 4000 пользователей, то мне нужно предварительно создать в accel-ppp.conf 4000 записей типа interface=eth2.$VLAN? А accel-ppp просто в данном случае позволяет провайдеру маршрутизировать динамические ip-адреса в пользовательские VLAN?

[xeb]

какой-то странный лог, ни запросов к радиусу, ничего не видно

 

Т.е., как я понимаю если у меня 4000 пользователей, то мне нужно предварительно создать в accel-ppp.conf 4000 записей типа interface=eth2.$VLAN?

чтобы не делать 4000 записей можно воспользоваться регулярными выражениями

 

А accel-ppp просто в данном случае позволяет провайдеру маршрутизировать динамические ip-адреса в пользовательские VLAN?

точно так

[purecopper]

Спасибо за ответ.

Содержание лога:

 

 

[2013-01-28 16:14:10]: error: ipoe: 'eth2.100': ioctl(SIOCGIFINDEX): No such device

 

 

 

хотя

 

 

ifconfig eth2.100

eth2.100 Link encap:Ethernet HWaddr 50:46:5d:8b:e1:76

BROADCAST MULTICAST MTU:1500 Metric:1

RX packets:0 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:0 (0.0 B) TX bytes:0 (0.0 B)

 

 

 

А насколько бредовой кажется идея дать возможность при перехвате DHCP Discover выполнять произвольный bash-скрипт. По-идее это может дать возможность рулить как Vlan, так и оборудованием по SNMP. Т.е. можно будет VLAN пользователю назначать "динамически".

 

s.lobanov Спасибо :)

Изменено 28 января, 2013 пользователем purecopper

[s.lobanov]

purecopper

ifconfig eth2.100 up

[xeb]

Т.е. можно будет VLAN пользователю назначать "динамически".

DHCP запрос придёт уже в влане и если такого влана на сервер нет, то пакет никуда не попадёт

если влана нет , то дхцп пакет никак не перехватить, если только через libpcap попробовать

 

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

Изменено 28 января, 2013 пользователем xeb

[kayot]

В любом случае все клиентские интерфейсы должны быть созданы заранее и подняты. И сервер должен их слушать. Как иначе сервер вообще увидит трафик от клиентов, находящихся в разных вланах? :)

 

У нас сейчас данная схема работает, авторизация абонента по dhcp-запросу:

1) relay получает клиентский запрос, добавляет опцию 82 в виде circuit=eth1.xxx или любом нужном нам.

2) авторизация пользователя в radius. Вообще этот пункт у меня лично вызывает большие вопросы, адрес ведь клиенту все равно должен быть выдан, хоть клиент активен, хоть должник.. Даже неклиенту нужно что-то выдавать, что б можно было web-auth сделать(привязать логин/пароль клиента к влану). Т.е. смысла в такой авторизации нет, придется ставить заглушку выдающую true.

3) dhcp-запрос релеится на сервер, сервер по opt82 выдает ip. Клиентам белую статику, должникам серые из блока1 с редиректом на страницу "дай денег", неклиентам серые из другого блока с требованием авторизации.

4) после выдачи IP создается маршрут вида "clint_ip via client_vlan".

Все, все счастливы.

[xeb]

Т.е. смысла в такой авторизации нет, придется ставить заглушку выдающую true.

можно noauth опцию добавить, чтобы заглушки не городить

[kayot]

Вопросы/предложения:

1. IMHO L4-redirect средствами ip rule не имеет смысла. При большом числе правил нагрузка на систему вероятно будет даже больше чем от линейных правил в iptables, которые в свою очередь всегда можно в ipset упаковать.

Проще редиректить выдачей ip из другого блока, для данного блока будет 1 запись ip rule с маршрутом на нашу заглушку.

2. Небольшая кривость в работе релея. Клиенту релей выдает свой giaddr а качестве option 3 routers, вместо опции выданной dhcp-сервером. И это в корне неправильно, у меня к примеру релей и сервер общаются посредством внутренней серой сети(10.хх), соответственно клиенту этот IP в качестве шлюза и выдается.

[s.lobanov]

kayot

при использовании ip rule from ... table ... вроде как хеш-таблицы используются(http://linux-ip.net/html/routing-selection.html#tb-routing-selection-adv ), т.е. ничего страшного не случится при большом кол-ве правил

[purecopper]

Т.е. можно будет VLAN пользователю назначать "динамически".

DHCP запрос придёт уже в влане и если такого влана на сервер нет, то пакет никуда не попадёт

если влана нет , то дхцп пакет никак не перехватить, если только через libpcap попробовать

 

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

Попробую обрисовать схему.

В данный момент мы используем схему Vlan на пользователя через QinQ. Коммутаторы на доступе находятся в отдельном управляющем Vlan с IP 192.168.100.0/24, скажем, с ID 4090. Выше на агрегации стоит коммутатор, который навешивает на пользовательский внешний тег, скажем, 4000. В результате пользовательский интерфейс имеет вид eth1.4000.$VLAN. Между агрегацией и NAS поднят VLAN с VID 100 и IP-адресами 192.168.1.1/30 на стороне сервера и 192.168.1.2/30 на стороне коммутатора агрегации. НА коммутаторах доступа в качестве Relay прописан Ip-адрес сервера 192.168.1.1. В результате чего DHCP Discover приходит всегда на интерфейс сервера eth1.100.

Идея состоит в следующем:

Получаем DHCP-запрос с opt82, формируем по нему имя пользователя, получаем от Radius-сервера параметры пользовательского интерфейса, которые направляем на вход собственного скрипта, который выделяет пользователю VLAN, поднимает интерфейс, добавляет ip route bla-bla-bla, прописывает по SNMP QinQ-трансляцию и VLAN на коммутаторе доступа.

 

Вот как-то так :)

[kayot]

purecopper

А в чем смысл таких заморочек? Скрипт сгенерирует нужное число двухтеговых интерфейсов за минуту при загрузке сервера, пусть себе висят.

[purecopper]

kayot

Смысл исключительно в удобстве управления пользовательскими VLAN на коммутаторах доступа. Ведь сейчас нужно хранить в биллинге информацию о VID и SVID пользователя, что не совсем удобно. А тут получается этакий L2-аналог PPtP/L2TP/PPPoE. :)