Jump to content
Если используется шейпер, то было бы хорошо в консоли отображать скорость которая назначена на интерфейс клиенту.
да знаю, что надо команду show sessions расширять, но пока не первоочередная задача ...

 

Share this post


Link to post
Share on other sites

access-list 100 permit ip any any time-range day

access-list 101 permit ip any any time-range night

 

time-range day

periodic daily 9:00 to 1:00

!

time-range night

periodic daily 1:01 to 8:59

!

 

вот так на nas описано

 

Share this post


Link to post
Share on other sites

ну я понял )

 

просто нужно что бы вот такой пакет нормально отрабатывался.

 

[2010-12-28 13:44:06]: info: ppp63: recv [RADIUS Access-Accept id=1 <Service-Type Framed-User> <Framed-Protocol PPP> <Framed-IP-Address 10.50.11.150> <Framed-IP-Netmask 255.255.255.255> <Acct-Interim-Interval 62><Cisco Ci

sco-AVPair "lcp:interface-config#1=rate-limit output access-group 101 5120000 960000 1920000 conform-action transmit exceed-action drop"><Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit output access-group 100 512000

0 960000 1920000 conform-action transmit exceed-action drop"><Cisco Cisco-AVPair "lcp:interface-config#1=rate-limit input access-group 101 5120000 960000 1920000 conform-action transmit exceed-action drop"><Cisco Cisco-AVP

air "lcp:interface-config#1=rate-limit input access-group 100 5120000 960000 1920000 conform-action transmit exceed-action drop"><Microsoft MS-MPPE-Encryption-Policy 1><Microsoft MS-MPPE-Encryption-Type 6><Microsoft MS-MPP

E-Send-Key ><Microsoft MS-MPPE-Recv-Key ><Microsoft MS-CHAP2-Success >]

 

скорость то не ограничивается..

Edited by alexxx71

Share this post


Link to post
Share on other sites

Поймал наконец-то своё падение.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6c14b70 (LWP 28230)]
0xb7d133be in vsnprintf () from /lib/libc.so.6
(gdb)
(gdb)
(gdb) bt
#0  0xb7d133be in vsnprintf () from /lib/libc.so.6
#1  0xb7cf5cc2 in snprintf () from /lib/libc.so.6
#2  0xb741c023 in fill_env (env=0xb43f1f40, pd=0xc70b220) at /tmp/accel-pptp/accel-pptpd/extra/pppd_compat.c:481
#3  0xb741b8aa in ev_radius_coa (ev=0xb43f1fc0) at /tmp/accel-pptp/accel-pptpd/extra/pppd_compat.c:337
#4  0xb7fde7a2 in triton_event_fire (ev_id=201, arg=0xb43f1fc0) at /tmp/accel-pptp/accel-pptpd/triton/event.c:103
#5  0xb7c2c8bb in coa_request (rpd=0xb3cd0ea4) at /tmp/accel-pptp/accel-pptpd/radius/dm_coa.c:157
#6  0xb7fdc31f in ctx_thread (ctx=0xb43f3024) at /tmp/accel-pptp/accel-pptpd/triton/triton.c:170
#7  0xb7ce87bb in makecontext () from /lib/libc.so.6
#8  0xb43f3024 in ?? ()
#9  0xb7c8a107 in pptp_connect (h=0xb7fd3078) at /tmp/accel-pptp/accel-pptpd/ctrl/pptp/pptp.c:613
#10 0xb7fdc36f in ctx_thread (ctx=0xb7ff5d10) at /tmp/accel-pptp/accel-pptpd/triton/triton.c:181
#11 0xb7fe0470 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Share this post


Link to post
Share on other sites

-4. Можно ли в консоли accel отображать помимо remote ip еще и ip клиента с которого устанавливается сессия. Сильно бы упростило скриптописание.
Если используется шейпер, то было бы хорошо в консоли отображать скорость которая назначена на интерфейс клиенту
заценивайте новый show sessions и в help не забудьте заглянуть

 

Share this post


Link to post
Share on other sites

Доброго времени суток уважаемые коллеги!

Возникла тоже проблема с биллингом (stargazer.dp.ua).

Прошу Вашей помощи, похоже наткнулся на баг:

Использую версию accel-pptpd 0.8.5 на CentOS 5 со штатным ядром и ppp с вашим патчем allow-mppe-128

(большое спасибо за него, очень удобно стало, а то надоело следить за 2ми серверами).

ppp общается с биллингом по средствам радиуса, который выдает Framed-IP-Address на туннель из биллинга.

Исторически сложилось, что уживаются 2 вида тарифов:

- пометровые (вид доступа - собственный авторизатор, открыващий фаерволл на роутерах для LAN-ip)

и

- безлимиты (ВПН, на туннелях у юзеров отдельная вирт.сеть),

что обозначено в биллинге в поле IP (у пометровки - lan-ip , у анлимщиков - 10.9.248.0/23)

до перехода когда пометровые клиенты коннектились на впн-сервер со стандартным pptpd

выдавало ошибку 656 (точно не помню, воспроизвести не получается) и разрывало ВПН.

Сейчас accel-pptpd имею:

 

Dec 30 11:28:29 vpn1 pppd[801]: Plugin /usr/lib64/pppd/2.4.4/radius.so loaded.
Dec 30 11:28:29 vpn1 pppd[801]: RADIUS plugin initialized.
Dec 30 11:28:29 vpn1 pppd[801]: Plugin /usr/lib64/pppd/2.4.4/radattr.so loaded.
Dec 30 11:28:29 vpn1 pppd[801]: RADATTR plugin initialized.
Dec 30 11:28:29 vpn1 pppd[801]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
Dec 30 11:28:29 vpn1 pptp[801]: Plugin pptp.so loaded.
Dec 30 11:28:29 vpn1 pptp[801]: PPTP plugin version 0.8.5 compiled for pppd-2.4.4, linux-2.6.18-194.26.1.el5xen
Dec 30 11:28:29 vpn1 pptp[801]: pppd 2.4.4 started by root, uid 0
Dec 30 11:28:29 vpn1 pptp[801]: Using interface ppp107
Dec 30 11:28:29 vpn1 pptp[801]: Connect: ppp107 <--> pptp (10.9.2.33)
Dec 30 11:28:32 vpn1 pptp[801]: MPPE 128-bit stateless compression enabled
Dec 30 11:28:32 vpn1 pptp[801]: local  IP address 10.9.248.1
Dec 30 11:28:32 vpn1 pptp[801]: remote IP address 10.9.2.33
Dec 30 11:28:32 vpn1 kernel: HTB: quantum of class 10030 is small. Consider r2q change.
Dec 30 11:28:44 vpn1 kernel: BUG: soft lockup - CPU#0 stuck for 10s! [pppd:801]
Dec 30 11:28:44 vpn1 kernel: CPU 0:
Dec 30 11:28:44 vpn1 kernel: Modules linked in: ipt_set(U) ip_set_nethash(U) ip_set(U) xt_MARK iptable_mangle act_police sch_i
ngress cls_u32 sch_sfq cls_fw sch_htb testmgr_cipher testmgr aead crypto_blkcipher crypto_algapi crypto_api arc4 ppp_mppe ipt_
MASQUERADE iptable_nat ipt_TCPMSS xt_tcpudp iptable_filter ip_tables x_tables ip_nat_pptp ip_conntrack_pptp ip_nat ip_conntrac
k nfnetlink pptp(U) pppox ppp_generic slhc dm_mirror dm_multipath scsi_dh scsi_mod parport_pc lp parport xennet pcspkr dm_raid
45 dm_message dm_region_hash dm_log dm_mod dm_mem_cache xenblk ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Dec 30 11:28:44 vpn1 kernel: Pid: 801, comm: pppd Tainted: G      2.6.18-194.26.1.el5xen #1
Dec 30 11:28:44 vpn1 kernel: RIP: e030:[<ffffffff80264aa9>]  [<ffffffff80264aa9>] .text.lock.spinlock+0x26/0x30
Dec 30 11:28:44 vpn1 kernel: RSP: e02b:ffff880005c17c28  EFLAGS: 00000286
Dec 30 11:28:44 vpn1 kernel: RAX: ffff880005c17fd8 RBX: ffff880014fdb810 RCX: 00000000000000fc
Dec 30 11:28:44 vpn1 kernel: RDX: ffffffffff578000 RSI: ffff880013e1c9c0 RDI: ffff880014fdb810
Dec 30 11:28:44 vpn1 kernel: RBP: ffff880014fdb810 R08: ffff88005e79347e R09: 0000000000000113
Dec 30 11:28:44 vpn1 kernel: R10: ffff880013e1c9c0 R11: 000000000000002f R12: ffff880002ee1800
Dec 30 11:28:44 vpn1 kernel: R13: 0000000000000034 R14: 0000000000000000 R15: ffff880004f05000
Dec 30 11:28:44 vpn1 kernel: FS:  00002b76e45d9af0(0000) GS:ffffffff805d2000(0000) knlGS:0000000000000000
Dec 30 11:28:44 vpn1 kernel: CS:  e033 DS: 0000 ES: 0000
Dec 30 11:28:44 vpn1 kernel:
Dec 30 11:28:44 vpn1 kernel: Call Trace:
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80264959>] _spin_lock_bh+0x9/0x14
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8819a76e>] :ppp_generic:ppp_push+0x61/0x54c
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8826735e>] :ppp_mppe:mppe_compress+0x141/0x178
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8022efd3>] __alloc_skb+0x77/0x12d
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8819b4e7>] :ppp_generic:ppp_xmit_process+0x525/0x5c1
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80264931>] _spin_lock_irqsave+0x9/0x14
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8819d549>] :ppp_generic:ppp_start_xmit+0x1d9/0x21f
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8041fc0d>] dev_hard_start_xmit+0x1b7/0x28a
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8042fff1>] __qdisc_run+0x136/0x1f9
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80230da8>] dev_queue_xmit+0x25d/0x394
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff802332f6>] ip_output+0x2ae/0x2dd
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff881b701a>] :pptp:pptp_xmit+0x537/0x56d
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8819c2a0>] :ppp_generic:ppp_channel_push+0x3d/0xae
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff8819d691>] :ppp_generic:ppp_write+0x102/0x111
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80217377>] vfs_write+0xce/0x174
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80217bc4>] sys_write+0x45/0x6e
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80260106>] system_call+0x86/0x8b
Dec 30 11:28:45 vpn1 kernel:  [<ffffffff80260080>] system_call+0x0/0x8b
Dec 30 11:28:45 vpn1 kernel:
Dec 30 11:28:54 vpn1 kernel: BUG: soft lockup - CPU#0 stuck for 10s! [pppd:801]
и тд в цикле

 

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

А то не хочется отказываться от данного "чудо" ПО, действительно прирост производительности существенный.

Респект Xeb -у и тем кто принимает участия в разработке

Edited by keshalg

Share this post


Link to post
Share on other sites

Dec 30 11:28:29 vpn1 pptp[801]: Connect: ppp107 <--> pptp (10.9.2.33)

Dec 30 11:28:32 vpn1 pptp[801]: remote IP address 10.9.2.33

юзеру на туннель выдается его же адрес в локалке. ессно - краш.

 

А вообще - "исторически сложившуюся" кривую систему нужно менять. Если не получится простыми мерами - то радикально, с биллингом. Негоже держать биллинг, который не различает VPN с IPoE - обязательно кто-то из саппорта попутает, и вобьет IP юзера ему же на туннель, обеспечив краш всех серверов пула по очереди.

Edited by NiTr0

Share this post


Link to post
Share on other sites

Hу с радикальными методами понятно,

пометровка сама отживает свое, я за компромиссное решение.

Cаппорту трудно будет всех перевести на один вид доступа, да и авторизатор там информативный очень.

....краш всех серверов пула по очереди.
Да не должно же такого быть, стандартный РоРоТОР - выдавал просто ошибку, но не валять же весь *nix.

Удалось воспроизвести на стандартном pptpd

[root@vpn2 ~]# rpm -q pptpd
pptpd-1.3.4-2.rhel5

 

на клиенте пишет после авторизации в момент "Регистрация компьютера в сети..."

 

Ошибка подключения ....
Проверка подключений сетевых протоколов....
TCP/IP протокол сообщает об ошибке 52:
ну удалось подключиться к сети из-за существования совпадающих имен.
Измените имя компьютера на панели управления и повторите попытку

 

на сервере в этот момент

 

Dec 30 17:49:38 vpn2 pppd[6314]: local  IP address 10.9.248.1
Dec 30 17:49:38 vpn2 pppd[6314]: remote IP address 10.9.0.248
Dec 30 17:49:38 vpn2 pppd[6314]: pptpd-logwtmp.so ip-up ppp0 kesha 10.9.0.248
Dec 30 17:49:38 vpn2 pppd[6314]: IPCP terminated by peer (h6hM-9^@<M-Mt^@^@^@4)
Dec 30 17:49:38 vpn2 pppd[6314]: pptpd-logwtmp.so ip-down ppp0
Dec 30 17:49:38 vpn2 pppd[6314]: Connect time 0.0 minutes.
Dec 30 17:49:38 vpn2 pppd[6314]: Sent 59620 bytes, received 16 bytes.
Dec 30 17:49:38 vpn2 pppd[6314]: LCP terminated by peer (h6hM-9^@<M-Mt^@^@^@^@)
Dec 30 17:49:38 vpn2 pppd[6314]: Modem hangup
Dec 30 17:49:38 vpn2 pppd[6314]: Connection terminated.
Dec 30 17:49:38 vpn2 pppd[6314]: Connect time 0.0 minutes.
Dec 30 17:49:38 vpn2 pppd[6314]: Sent 59624 bytes, received 16 bytes.
Dec 30 17:49:38 vpn2 pppd[6314]: Exit.
Dec 30 17:49:38 vpn2 pptpd[6313]: CTRL: Client 10.9.0.248 control connection finished

Edited by keshalg

Share this post


Link to post
Share on other sites

не нужно это воспроизводить, надо этого избегать любыми путями
т.е. мне не "светит" аксцель?

А нельзя ли подправить код, подобно стандартному pptpd, что бы аксцель обрабатывал точно так же это исключение?

И правда же механические операторов ошибки просто неизбежны

Share this post


Link to post
Share on other sites

Hу с радикальными методами понятно,

пометровка сама отживает свое, я за компромиссное решение.

Cаппорту трудно будет всех перевести на один вид доступа, да и авторизатор там информативный очень.

После предложения хомякам 10-20-50 мбит за 10$ они толпой побегут за дешевыми тарифами, забыв о пометровке и информативном авторизаторе. И если сравнивать траффик при "массвых" каналах в 2 мбита и "массовых" каналах в 20 мбит - разница будет максимум раза в 1.5-2.

 

т.е. мне не "светит" аксцель?
Вам виднее.

 

А нельзя ли подправить код
Можно, правьте :)

Share this post


Link to post
Share on other sites

(gdb) bt
#0  0x0804a90d in __list_del (prev=0x0, next=0x0) at /tmp/accel-pptp/accel-pptpd/include/list.h:85
#1  0x0804a937 in list_del (entry=0xaab5cbc) at /tmp/accel-pptp/accel-pptpd/include/list.h:96
#2  0x0804b038 in destablish_ppp (ppp=0xaab5cbc) at /tmp/accel-pptp/accel-pptpd/ppp/ppp.c:195
#3  0x0804b960 in ppp_layer_finished (ppp=0xaab5cbc, d=0xaf796430) at /tmp/accel-pptp/accel-pptpd/ppp/ppp.c:432
#4  0x0804d7e7 in _lcp_layer_finished (lcp=0xaf796430) at /tmp/accel-pptp/accel-pptpd/ppp/ppp_lcp.c:125
#5  0xb7fdc31f in ctx_thread (ctx=0xb429b024) at /tmp/accel-pptp/accel-pptpd/triton/triton.c:170
#6  0xb7ce87bb in makecontext () from /lib/libc.so.6
#7  0xb429b024 in ?? ()
#8  0xb7c8a107 in pptp_connect (h=0xb7fd3078) at /tmp/accel-pptp/accel-pptpd/ctrl/pptp/pptp.c:613
#9  0xb7fdc36f in ctx_thread (ctx=0xb7ff5d10) at /tmp/accel-pptp/accel-pptpd/triton/triton.c:181
#10 0xb7fe0470 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

0489841b673164b666a800255d86ab94d25cd45b

Версия старенькая, может, уже вылечили?

Share this post


Link to post
Share on other sites

Свежачок. 6409b409508f22ea7dbb3f3fa2cb9de78d5073c5

(gdb) bt
#0  0xb7fdb050 in __list_del (prev=0x0, next=0x0) at /tmp/accel-pptp/accel-pptpd/triton/list.h:85
#1  0xb7fdb07a in list_del (entry=0xb27f1878) at /tmp/accel-pptp/accel-pptpd/triton/list.h:96
#2  0xb7fdb30e in triton_thread (thread=0xb27f1878) at /tmp/accel-pptp/accel-pptpd/triton/triton.c:104
#3  0xb7fb4e60 in start_thread () from /lib/libpthread.so.0
#4  0xb7d7bf9e in clone () from /lib/libc.so.6

 

Share this post


Link to post
Share on other sites

А нельзя ли подправить код
Можно, правьте :)

Обошлось без правки кода.

По совету уважаемого martin74, моя "частная проблема" решена скриптом auth-up из /еtс/ppp (man pppd)

Спасибо за помощь и разрешение править GPL-проект.

Я думал версия 0.8.5 актуальна, хотя бы для тех, кто работает на RH5-based системах

(которым недоступны официальные новые ядра для 1.X).

Прошу прощения, если влез в обсуждение неактуальной версии.

Share this post


Link to post
Share on other sites

Ну у меня 0.8.5; работает. Все что нужно - поправил в биллинге. На 1.x - пока не спешу переползать, т.к. это требует втягивания в мой дистр cmake и еще скорее всего еще библиотек + насилования всего этого для кросс-компиляции, + пока его в продакшн пускать рановато...

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.