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

Dimka88

Не используйте адреса /32, и не будет проблемы. Не нужно изобретать костыли там, где они не нужны.

Я пробовал и /8 для 10.0.0.1 но увы картина все та же. Даже на стендовых виртуалках тот же результат.

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


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

Dimka88

Т.е. на loopback вешаете 10.0.0.1/8, и клиентам выдаете из этого же диапазона с маской /8 и gw 10.0.0.1?

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


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

Т.е. на loopback вешаете 10.0.0.1/8, и клиентам выдаете из этого же диапазона с маской /8 и gw 10.0.0.1?

На стенде пробовал и так, но arp все равно уходили с первого в списке на lo scope global. Подскажите пожалуйста, как реализовано у вас, а то я не могу уснуть не решив задачу. =)

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


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

Dimka88

Ну так у всех реализовано, клиенту выдается IP из блока, один из IP этого блока дается серверу, вешается на loopback.

Никаких чудес с роутами и ARP, все думают что они в 1 большом влане.

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


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

Немного наврал, это на цисках нужно на LO вешать полные сети.

[root@IPoE1 ~]# ip a show lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet xx.xx.xx.1/32 scope global lo
      valid_lft forever preferred_lft forever
   inet yy.yy.yy.1/32 scope global lo
      valid_lft forever preferred_lft forever

А клиентам какую маску/gw выдаете?

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


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

Ну так у всех реализовано, клиенту выдается IP из блока, один из IP этого блока дается серверу, вешается на loopback.

Никаких чудес с роутами и ARP, все думают что они в 1 большом влане.

Что то я видно делаю не так. Если я указываю маску /24 или /8, то все адреса например 10.0.0.10/8 или любые другие становятся доступными на loopback интерфейсе. Тут у меня явно пробел в знаниях =(

 

А клиентам какую маску выдаете?

/24 и /8 для 10.0.0.0

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


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

Dimka88

Погоди, грабля должна быть какой-то совсем банальной и смешной.

Proxy-ARP используется системный или accel'я?

gw-ip-address=10.0.0.1/8 в конфиге забит?

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


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

gw-ip-address=10.0.0.1/8 в конфиге забит?

Да, и для 192.168.1.1/24 и 192.168.2.1/24.

 

Proxy-ARP

proxy-arp=1 accel`я, системный отключен.

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

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


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

Перечитал, кучу всякой литературы и пока остановился на одном предположении, что это беда именно Debian(а). Поставлю gentoo и ванильное ядро, посмотрим. Моя проблема не такая уж редкость, как оказалось.

ps:// accel к проблеме имеет косвенное отношение, так что прошу прощение за оффтоп.

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

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


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

На стандартном pppoe сервере даже если указаны service-name - то как минимум с пустым(длина 0, т.е. не указан) на клиенте - все равно пускает. На последних accel - нет.

 

Неужели где-то поломалось после 30cff41b56be0d4c3e407e8aa4de5b289eef2ab0 ? А то я как раз собирался запустить последний accel на PPPoE, тестирую на небольшом сегменте, как то странно подключаются клиенты...

 

На старом сервере с ядром 3.2 и закомментированным service-name работает вроде без проблем.

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

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


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

Для меня поломалось еще в

https://github.com/xebd/accel-ppp/commit/75edc5199bfcf7c83079b58990760f3de57680ec

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

У меня уже готов следующий "мини-патч" для другой модели поведения, когда pppoe отвечает на пустой service-name, а на неправильный - молчит. Такое тоже достаточно часто требуется как оказалось.

Отправлю если xeb примет предыдущий

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


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

Для меня поломалось еще в

https://github.com/xebd/accel-ppp/commit/75edc5199bfcf7c83079b58990760f3de57680ec

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

У меня уже готов следующий "мини-патч" для другой модели поведения, когда pppoe отвечает на пустой service-name, а на неправильный - молчит. Такое тоже достаточно часто требуется как оказалось.

Отправлю если xeb примет предыдущий

 

Спасибо, взял коммит попробовать. Если я правильно понял то должно быть так ? Если клиент указал известный ему SN - подключается, если прилетает пустой (default) - подключается?

 

service-name=nas10
accept-any-service=1

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


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

да, верно

service-name=nas10,nas11 - если нужно несколько

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


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

пока остановился на одном предположении, что это беда именно Debian(а). Поставлю gentoo и ванильное ядро, посмотрим.

Таки дело в debian или в ядре. На gentoo с ядром 4.8.8 даже если на lo висят ip /32 выступающие GW для клиентов, модель поведения ARP ruquest следующая.

05:54:30.170618 ARP, Request who-has 10.0.0.50 tell 192.168.1.1, length 28
05:54:31.194866 ARP, Request who-has 10.0.0.50 tell 192.168.1.1, length 28
05:54:32.219066 ARP, Request who-has 10.0.0.50 tell 192.168.1.1, length 28
05:54:33.672178 ARP, Request who-has 10.0.0.50 tell 10.0.0.1, length 28
05:54:33.672745 ARP, Reply 10.0.0.50 is-at 08:00:27:98:27:b3, length 46

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


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

Все же интересно, существуют ли методы придерживаясь данной схемы с первой попытки отправлять ARP request с ip src из подсети ip dst?

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


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

есть проблема с прохождением трафика через ipoe драйвер

3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux

 

пробовал разные версии 1.10.1 1.9

 

создается интерфейс

ipoe0     Link encap:Ethernet  HWaddr 00:00:00:00:00:00
         UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
         RX packets:5560 errors:0 dropped:4 overruns:0 frame:0
         TX packets:55 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:100
         RX bytes:395388 (386.1 KiB)  TX bytes:7594 (7.4 KiB)

 

трафик от него идет

listening on ipoe0, link-type EN10MB (Ethernet), capture size 262144 bytes
07:36:00.018104 IP 10.28.10.33.54527 > 94.41.184.132.dynamic.o56.ru.31029: Flags [s], seq 4079224478, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
07:36:00.512578 IP 10.28.10.33.30642 > 166-2-124-91.pool.ukrtel.net.57159: UDP, length 20
07:36:00.515454 IP 10.28.10.33.30642 > client.yota.ru.56910: UDP, length 20
07:36:00.515455 IP 10.28.10.33.30642 > ppp91-77-221-197.pppoe.mtu-net.ru.24457: UDP, length 20

 

а вот обратно не хочет

 

конфиг

[ipoe]
verbose=5
#username=lua:username
#lua-file=/etc/accel-ppp.lua
#password=username
shared=1
ifcfg=1
mode=L3
start=up
local-net=10.28.10.32/27
unit-cache=1000
l4-redirect-on-reject=60
l4-redirect-ipset=l4-redirect
nat=1
interface=eth1.4,mode=L3,start=up
proxy-arp=1

[client-ip-range]
10.28.10.32/27

 

 

сессия висит адекватно

 

 ifname |  username   | calling-sid |     ip      |  rate-limit   | type | comp | state  |  uptime
--------+-------------+-------------+-------------+---------------+------+------+--------+----------
ipoe0  | 10.28.10.33 | 10.28.10.33 | 10.28.10.33 | 102400/102400 | ipoe |      | active | 00:08:17

 

 

sysctl -a | grep ip_for
net.ipv4.ip_forward = 1

 

роут в обратную сторону есть.

 

iptables без правил DROP и т.п.

есть идеи? может кто сталкивался, на форуме https://accel-ppp.org/forum/viewtopic.php?f=10&t=30 висит старый топик, проблема похожа.

 

если поставить 0.0.0.0/0 в IPOE модуле,то трафик начинает бежать, но в обход шейпера и счетчиков ipoe

 

 

upd// проблема была в rp_filter O.o

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

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


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

Я недавно писал по поводу падения accel-pppd после завершения сессии и отправки Accounting-Stop - пробовал и последнюю версию с гита - то-же самое, единственное что помогло thread-count=1. Недавно проскакивала инфа о зависании намертво (без kernel-panic) брасов с accel - у меня стабильно наблюдается при up-limiter=police. Меняю на htb + ifb - работает стабильно.

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


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

Кто смог побороть при выдаче ipool и авторизации L2 - присваивать framed-ip-Address?

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


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

Всем доброго времени суток, проблема

radius:BUG: rpd not found

так и осталась. Кто-то знает как можно ее отдебажить? тема на официальном форуме accelя так и осталась без ответа.

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


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

так и осталась. Кто-то знает как можно ее отдебажить? тема на официальном форуме accelя так и осталась без ответа.

Соберите acel-ppp ветку мастер с -DCMAKE_BUILD_TYPE=Debug, и еще раз корку на форум accel-ppp.

Или в оболочке gdb после падения выполните bt full и простыню на форум.

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

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


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

kamae1ka

А на русском?

имею схему dhcp. L2. выдача локального ип из пула, + выдача статичного IP из radius.

 

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

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


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

На днях поставил на новый сервер последний стабильный Debian 8.6 (jessie) (3.16.0-4-amd64)

и accel-ppp из git-а.

 

Собирал с -DCPACK_TYPE=Debian8 -DCMAKE_INSTALL_PREFIX=/usr -DSHAPER=TRUE -DRADIUS=TRUE

 

Используется чисто для pptp + radius. Kernel panic раз в сутки-двое :)

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


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

Вот bt full с предидущего падения - новое пока жду.

(gdb) bt full
#0  0x00007fca16f99067 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
       resultvar = 0
       pid = 5148
       selftid = 5158
#1  0x00007fca16f9a448 in __GI_abort () at abort.c:89
       save_stage = 2
       act = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, sa_mask = {__val = {140505913616128, 140505913613520, 
             140505967078855, 140505560121349, 0, 140505945357392, 140505945386280, 140505828563688, 140505913613520, 0, 140505967104741, 
             0, 140505946259053, 0, 25587488, 0}}, sa_flags = 353494784, sa_restorer = 0x7fca1511e700}
       sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007fca1673f77b in find_pd (ses=0x7fca10001bc0) at /root/accel-ppp-1.11.0/accel-pppd/radius/radius.c:565
       pd = 0x7fca10001c80
       rpd = 0x406b53 <ap_session_read_stats+74>
#3  0x00007fca1673f34c in ses_finishing (ses=0x7fca10001bc0) at /root/accel-ppp-1.11.0/accel-pppd/radius/radius.c:458
       rpd = 0x0
       fr = 0x1892b40
#4  0x00007fca1820a6ff in triton_event_fire (ev_id=3, arg=0x7fca10001bc0) at /root/accel-ppp-1.11.0/accel-pppd/triton/event.c:103
       ev = 0x1870ed0
       h = 0x1870ef0
#5  0x0000000000406433 in ap_session_finished (ses=0x7fca10001bc0) at /root/accel-ppp-1.11.0/accel-pppd/session.c:180
No locals.
#6  0x00007fca16b4eac8 in ipoe_session_terminated (ses=0x7fca10001ad8) at /root/accel-ppp-1.11.0/accel-pppd/ctrl/ipoe/ipoe.c:1142
No locals.
#7  0x00007fca182075b1 in ctx_thread (ctx=0x7fca10001e28) at /root/accel-ppp-1.11.0/accel-pppd/triton/triton.c:238
       h = 0x7fca080033b8
       t = 0x7fca10001ae8
       call = 0x7fca10004718
       tt = 140505828563688
       events = 1
#8  0x00007fca182072b2 in triton_thread (thread=0x1894cc0) at /root/accel-ppp-1.11.0/accel-pppd/triton/triton.c:159
       set = {__val = {516, 0 <repeats 15 times>}}
       sig = 10
       need_free = 0
#9  0x00007fca17de60a4 in start_thread (arg=0x7fca1511e700) at pthread_create.c:309
       __res = <optimized out>
       pd = 0x7fca1511e700
       now = <optimized out>
       unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140505913616128, 6632738507667985572, 0, 140505969254496, 0, 140505913616128, 
               -6658551552126823260, -6658546506137545564}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, 
             cleanup = 0x0, canceltype = 0}}}
       not_first_call = <optimized out>
       pagesize_m1 = <optimized out>
       sp = <optimized out>
       freesize = <optimized out>
       __PRETTY_FUNCTION__ = "start_thread"
#10 0x00007fca1704c87d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.

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


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

Вот bt full с предидущего падения - новое пока жду.

 

Ну и пару строк выше из gdb. И кусочек лога при падении.

 

Используется чисто для pptp + radius. Kernel panic раз в сутки-двое :)

Нагрузка большая?

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

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


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

Join the conversation

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

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

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

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

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

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

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