[srg555]

Тут вопрос появился - а как правильно логи ротейтить? попробовал на ходу очистить лог - а он не очистился... Может демону что то шепнуть надо?

 

Воспользуйтесь самым правильным способом и универсальным способом для большинства демонов - syslog. А уже сислог ротейтить без проблем, да и в 99% это уже есть

[xeb]

http://sourceforge.net/apps/trac/accel-ppp/wiki/FAQ#logrotate

[purecopper]

Поставили новую версию accel-ppp для использование ipoe c shared=0 и обнаружили, что не создается radattr-файл вида radattr.eth1.100.200. Раньше создавался :(

 

Отвечу сам:

забыл подгрузить модуль pppd_compat. Все создается.

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

[morfair]

Звонил с тех. поддержки, не получается установить подключения с роутера ASUS:

 

[2013-05-27 17:54:39]:  info: l2tp: new tunnel 1-35249 created following reception of SCCRQ from 172.20.4.110:1701
[2013-05-27 17:54:39]:  info: l2tp tunnel 1-35249 (172.20.4.110:1701): established at 172.20.1.20:37797
[2013-05-27 17:54:39]:  info: l2tp tunnel 1-35249 (172.20.4.110:1701): new session 14337-36547 created following reception of ICRQ
[2013-05-27 17:54:39]:  info: ppp12: connect: ppp12 <--> l2tp(172.20.4.110:1701 session 36547)
[2013-05-27 17:54:40]:  warn: ppp10: lcp: no echo reply
[2013-05-27 17:54:40]:  info: ppp10: send [RADIUS(1) Accounting-Request id=1 <User-Name "118001"> <NAS-Identifier "nas2"> <NAS-IP-Address 192.168.235.212> <NAS-Port 10> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "172.20.6.53"> <Called-Station-Id "172.20.1.21"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "05802d7b766191fa"> <Acct-Session-Time 3602> <Acct-Input-Octets 23189996> <Acct-Output-Octets 68873466> <Acct-Input-Packets 126926> <Acct-Output-Packets 111750> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 176.110.210.1> <Acct-Terminate-Cause Lost-Carrier>]
[2013-05-27 17:54:40]:  info: ppp10: recv [RADIUS(1) Accounting-Response id=1]
[2013-05-27 17:54:40]: error: libnetlink: RTNETLINK answers: No such device
[2013-05-27 17:54:40]:  warn: ppp10: failed to get interface statistics
[2013-05-27 17:54:42]:  info: ppp12: send [RADIUS(1) Access-Request id=1 <User-Name "15605"> <NAS-Identifier "nas2"> <NAS-IP-Address 192.168.235.212> <NAS-Port 12> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "172.20.4.110"> <Called-Station-Id "172.20.1.20"><Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP2-Response >]
[2013-05-27 17:54:42]:  info: ppp12: recv [RADIUS(1) Access-Accept id=1 <Acct-Interim-Interval 0> <Framed-IP-Address 176.110.211.193> <PPPD-Downstream-Speed-Limit 10240><Microsoft MS-CHAP2-Success ><Microsoft MS-MPPE-Recv-Key ><Microsoft MS-MPPE-Send-Key ><Microsoft MS-MPPE-Encryption-Policy 2><Microsoft MS-MPPE-Encryption-Type 6>]
[2013-05-27 17:54:42]:  info: ppp12: 15605: authentication succeeded
[2013-05-27 17:54:42]:  warn: ppp12: IPCP: discarding packet
[2013-05-27 17:54:42]: error: libnetlink: RTNETLINK answers: No such device
[2013-05-27 17:54:42]:  warn: ppp12: failed to get interface statistics
[2013-05-27 17:54:42]:  info: l2tp session 1-35249, 14337-36547: PPP session finished (ppp12:15605), disconnecting session
[2013-05-27 17:54:42]:  info: l2tp tunnel 1-35249 (172.20.4.110:1701): no more session, disconnecting tunnel
[2013-05-27 17:54:45]:  info: ppp10: disconnected

[xeb]

на 1.7.3 работает ?

[morfair]

на 1.7.3 работает ?

Недельной давности, Git'ом выкачивал master. Debian 7 32bit

[demidc3]

Ребята, помогите с одной странной проблемой.

Пытаюсь сделать простой vpn (pptp) сервер, беру исходники, компилирую, ставлю, запускаю "accel-pppd -c /etc/accel-pppd.conf". Подключаюсь клиентом, всё отлично, авторизация проходит, клиент получает правильный адрес и шлюз. Только вот на сервере интерфейс ppp (ppp0) для него не создается. Соответственно, связи нет. Ошибок тоже никаких. Система - пробовал Centos 6.4 и Fedora 18 (собрал пакет из src rpm и поставил). На более старых centos (6.2) я ставил и работало, но тогда ещё модуля pptp.ko не было в их ядре. Вот конфиг (лишнее поудалял) и лог на самом подробном уровне:

/etc/accel-ppp.conf

[modules]
log_file
pptp
auth_mschap_v2
radius
ippool
sigchld

[core]
log-error=/var/log/accel-ppp/core.log
thread-count=4

[ppp]
verbose=9
min-mtu=1280
mtu=1400
mru=1400
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-timeout=120

[auth]
#noauth=0

[pptp]
verbose=9

[dns]
dns1=10.1.0.1

[wins]
#wins1=172.16.0.1

[radius]
nas-identifier=gate
nas-ip-address=10.0.0.61
gw-ip-address=10.1.0.49
server=10.0.0.254,test,auth-port=1812,acct-port=1813,req-limit=0,fail-time=5
verbose=1
acct-interim-interval=2592000

[client-ip-range]
disable

[ip-pool]
gw-ip-address=10.1.0.49
attr=Framed-Pool
10.1.0.50-64

[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
copy=1
level=9

[cli]
telnet=127.0.0.1:2000
tcp=127.0.0.1:2001
#password=123

 

/var/log/accel-ppp/accel-ppp.log

[2013-05-27 22:36:05]:   msg: accel-ppp version 1.8.0-beta
[2013-05-27 22:36:09]:  info: pptp: new connection from 10.0.0.7
[2013-05-27 22:36:09]:  info: : recv [PPTP Start-Ctrl-Conn-Request ...
[2013-05-27 22:36:09]:  info: : send [PPTP Start-Ctrl-Conn-Reply ... 
[2013-05-27 22:36:09]:  info: : recv [PPTP Outgoing-Call-Request ... 
[2013-05-27 22:36:09]:  info: : send [PPTP Outgoing-Call-Reply ...
[2013-05-27 22:36:09]:  info: ppp0: connect: ppp0 <--> pptp(10.0.0.7)
[2013-05-27 22:36:09]: debug: ppp0: lcp_layer_init
[2013-05-27 22:36:09]: debug: ppp0: auth_layer_init
[2013-05-27 22:36:09]: debug: ppp0: ccp_layer_init
[2013-05-27 22:36:09]: debug: ppp0: ipcp_layer_init
[2013-05-27 22:36:09]: debug: ppp0: ipv6cp_layer_init
[2013-05-27 22:36:09]: debug: ppp0: ppp established
[2013-05-27 22:36:09]: debug: ppp0: lcp_layer_start
[2013-05-27 22:36:09]:  info: ppp0: send [LCP ConfReq id=1 <auth MSCHAP-v2>...
[2013-05-27 22:36:09]:  info: ppp0: recv [PPTP Set-Link-Info]
[2013-05-27 22:36:09]:  info: ppp0: recv [LCP ConfReq id=0 <mru 1400>...
[2013-05-27 22:36:09]:  info: ppp0: send [LCP ConfRej id=0  <pcomp> <accomp> < d 3 6 >]
[2013-05-27 22:36:09]:  info: ppp0: recv [LCP ConfReq id=1 <mru 1400> <magic 44ee7adc>]
[2013-05-27 22:36:09]:  info: ppp0: send [LCP ConfAck id=1 ]
[2013-05-27 22:36:12]: debug: ppp0: fsm timeout
[2013-05-27 22:36:12]:  info: ppp0: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1400> <magic 3f2dba31>]
[2013-05-27 22:36:12]:  info: ppp0: recv [LCP ConfAck id=1 <auth MSCHAP-v2> <mru 1400> <magic 3f2dba31>]
[2013-05-27 22:36:12]: debug: ppp0: lcp_layer_started
[2013-05-27 22:36:12]: debug: ppp0: auth_layer_start
[2013-05-27 22:36:12]:  info: ppp0: send [MSCHAP-v2 Challenge id=1 <bc1cbebe52c2a3376ada0674459ac30>]
[2013-05-27 22:36:12]:  info: ppp0: recv [LCP Ident id=2 <MSRASV5.10>]
[2013-05-27 22:36:12]:  info: ppp0: recv [LCP Ident id=3 <MSRAS-0-VORTEX>]
[2013-05-27 22:36:12]:  info: ppp0: recv [PPTP Set-Link-Info]
[2013-05-27 22:36:12]:  info: ppp0: recv [MSCHAP-v2 Response id=1 ...
[2013-05-27 22:36:12]:  info: ppp0: send [RADIUS(1) Access-Request id=1 ...
[2013-05-27 22:36:12]:  info: ppp0: recv [RADIUS(1) Access-Accept id=1...
[2013-05-27 22:36:12]:  info: ppp0: send [MSCHAP-v2 Success id=1 ..
[2013-05-27 22:36:12]: debug: ppp0: auth_layer_started

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

[morfair]

И еще вопрос, возможно глупый, l2tp на accel-ppp можно настроить так, чтобы на windows-клиентах не приходилось отключать ipsec в реестре?

 

И еще) Что значит:

 

[2013-05-27 18:29:21]:  warn: l2tp: incorrect avp received (type=6, M=1, must be 0)

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

[xeb]

demidc3, это весь лог ?

 

И еще вопрос, возможно глупый, l2tp на accel-ppp можно настроить так, чтобы на windows-клиентах не приходилось отключать ipsec в реестре?

accel-ppp за ipsec не отвечает, нужно использовать racoon, openswan, freeswan или др.

 

И еще) Что значит:

 

[2013-05-27 18:29:21]:  warn: l2tp: incorrect avp received (type=6, M=1, must be 0)

значит клиент не отвечает спецификациям rfc

[morfair]

 

И еще вопрос, возможно глупый, l2tp на accel-ppp можно настроить так, чтобы на windows-клиентах не приходилось отключать ipsec в реестре?

accel-ppp за ipsec не отвечает, нужно использовать racoon, openswan, freeswan или др.

 

И еще) Что значит:

 

[2013-05-27 18:29:21]:  warn: l2tp: incorrect avp received (type=6, M=1, must be 0)

значит клиент не отвечает спецификациям rfc

1) Спасибо

2) И его не подключить?

[xeb]

2) И его не подключить?

[l2tp]

avp_permissive=1

[morfair]

2) И его не подключить?

[l2tp]

avp_permissive=1

недокументирвоанные возможности =)

[demidc3]

авторизация проходит, клиент получает правильный адрес и шлюз. Только вот на сервере интерфейс ppp (ppp0) для него не создается. Соответственно, связи нет.

Проблема в том, что accel-pppd не может загрузить модуль ядра, только не всегда об этом пишет в лог.

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

Debian 6 и готовый пакет с sourceforge любой версии = "segfault in libtriton.so"

Fedora 18 и сборка из любой версии исходника до последнего git - "failed to load pptp kernel module". Модуль ядра из исходников не собирается.

Centos 6.4 и сборка из исходников - либо "failed to load pptp kernel module", либо втихую не работает (не создает интерфейс ppp при коннекте).

Debian 7 и сборка - "failed to load pptp kernel module".

[srg555]

demidc3

поставьте ядро 3.9 из elrepo на centos, в новых ядрах модуль уже есть

[morfair]

В седьмом дебиане модуль в ядре (3.2.0-4-686-pae)

[martin74]

demidc3, я на Centos 6.4 собрал...

[srg555]

Debian 7 и сборка - "failed to load pptp kernel module".

В седьмом дебиане модуль в ядре (3.2.0-4-686-pae)

 

А сборка под 6ой, где модуля не было в ядре

[demidc3]

У меня есть одно сообщение, чтобы ответить всем :-)

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

 

xeb:

demidc3, это весь лог ?

Это весь accel-ppp.log от запуска до установки соединения (disconnect не входит). Ещё есть core.log и emerg.log, но там ничего интересного.

 

srg555:

А сборка под 6ой, где модуля не было в ядре

Под "сборкой" я имел ввиду самостоятельно собранные бинарники (cmake, make, make install)

 

martin74

demidc3, я на Centos 6.4 собрал...

Собрать-то и я собрал, но не работает. Centos со старым ядром и старым же gcc - там собирается всё, включая модуль ядра, то есть совместимость должна быть абсолютной. А результат тот же. Такое чувство, что я очень глобально что-то упускаю, не совсем очевидное, и надо только найти эту мелочь, и всё заработает.

 

Я не написал сразу - считал это очевидным. Во всех случаях, когда accel-pppd "жалуется" на невозможность загрузки модуля ядра, разумеется, этот модуль в системе присутствует. Он может быть уже загружен (например, через modprobe), или не загружен - неважно. Если модуль загружен не был, то при запуске accel-pppd он успешно загружается, это видно через lsmod. Вместе с ним также загружаются slhc, ppp_generic, pppox и ppp_mppe, и это происходит всегда и без лишних вопросов, т.е. проблема не в отсутствии модуля, а в том, что, по какой-то причине, accel-pppd не может с ним нормально взаимодействовать.

[srg555]

srg555:

А сборка под 6ой, где модуля не было в ядре

Под "сборкой" я имел ввиду самостоятельно собранные бинарники (cmake, make, make install)

 

Так вы модуль pptp не собираете. Почитайте манула там написаны ключи для cmake, чтоб модуль собрался

[xeb]

demidc3, судя по приведённым логам проблема не в модуле pptp, иначе бы дело до авторизации бы не дошло

[demidc3]

demidc3, судя по приведённым логам проблема не в модуле pptp, иначе бы дело до авторизации бы не дошло

Нашёл я, где грабли зарыты. Вот в этом параметре:

[radius]
acct-interim-interval=2592000

При таком значении наблюдается описанное поведение. Точную границу не искал, но при 1000000 ещё нормально.

И иногда записываемое при старте в лог сообщение "warn: failed to load pptp kernel module" на работоспособность тоже не влияет, как выяснилось.

[kayot]

Немного нелогичная система уровней log messages для ipoe.

Все сообщения модуля ipoe идут с уровнем info2. При этом самые важные сообщения - session start и session stop вообще идут как debug.

Все сообщения модуля radius идут с уровнем info1

 

При log level=5 имеем:

info: recv [DHCPv4 Request
info: : recv [DHCPv4 Discover (тут видимо опечатка : : некрасиво выглядит лог)
info: eth2.999.2021: send [RADIUS(1) Access-Request
info: eth2.999.2021: recv [RADIUS(1) Access-Accept
info: eth2.999.2021: send [DHCPv4 relay Discover
... десяток info сообщений от релея
info: eth2.999.2021: send [RADIUS(1) Accounting-Request...
info: eth2.999.2021: recv [RADIUS(1) Accounting-Response...
debug: eth2.999.2021: ipoe: session started

С log level=4 все тоже кроме последнего дебага

 

С log level=3 имеем только радиус(если включен vebose=1 для модуля), бессмысленные 4 строчки.

info: eth2.999.2021: send [RADIUS(1) Access-Request
info: eth2.999.2021: recv [RADIUS(1) Access-Accept
info: eth2.999.2021: send [RADIUS(1) Accounting-Request...
info: eth2.999.2021: recv [RADIUS(1) Accounting-Response...

Если же для радиуса не задан verbose, то в логе вообще будет глобальная тишина :)

 

Предлагаю сообщениям ipoe: session started и session stopped сменить log_ppp_debug на log_ppp_info1.

Тогда на level=3 будет только старт/стоп сессий, на 4 - DHCP лог, на 5 полный дебаг.

 

p.s. сделал такую правку у себя, лог выглядит куда лучше

[2013-05-29 23:36:11]:  info: eth2.999.2001: ipoe: session finished
[2013-05-29 23:36:11]:  info: eth2.999.2003: ipoe: session finished
[2013-05-29 23:36:11]:  info: eth2.999.2021: ipoe: session finished
[2013-05-29 23:36:11]:  info: terminate, sig = 15
[2013-05-29 23:36:15]:  warn: ppp: kernel doesn't support ipv6
[2013-05-29 23:36:15]: error: libnetlink: RTNETLINK answers: No such file or directory
[2013-05-29 23:36:15]: error: genl: error talking to kernel
[2013-05-29 23:36:15]:  warn: ipoe: unclassified packet handling is disabled
[2013-05-29 23:36:15]:   msg: accel-ppp version cf27bf49df5243237acb15389fb5544f5a863685
[2013-05-29 23:36:15]:  info: eth2.999.2001: ipoe: session started
[2013-05-29 23:36:35]:  info: eth2.999.2021: ipoe: session started
[2013-05-29 23:36:43]:  info: eth2.999.2003: ipoe: session started

Изменено 29 мая, 2013 пользователем kayot

[kayot]

И в догонку. При остановке сервиса у меня практически всегда в core.log появляется запись

2013-05-29 23:36:11.562]BUG:ctx:triton_unregister_ctx: handlers is not empty

Так ведь не должно быть?

[nik247]

Может нужно для режима IPoE сделать игнорирование Framed-IP-Address, или тогда рабочий конфиг такого вида:

attr-dhcp-client-ip=Framed-IP-Address

Который на данный момент не отрабатывает.

это тоже должно работать

to xeb:

Спасибо.

Стало нормально отрабатывать, так как по умолчанию стало nat=0.

При nat=1 работает, как раньше. Но я это не использую - главное он уже настраивается.

 

3) shaper:

- отрабатывает с консоли нормально команду: shaper change [temp] и устанавливает нужный шейпер.

- на команды "shaper restore " и "shaper restore all" происходит рестарт accel-ppp и дальше п.2

исправлено

to xeb:

Спасибо.

Изменения шейпера отрабатывают нормально - в корку не падает.

 

2) не закрываются ipoe сессии на radius сервере при перезагрузке accel-ppp (/etc/init.d/accel-ppp restart)

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

исправлено

to xeb:

Спасибо.

Но странно оно как-то работает: один раз закрывает сессии, потом три раза не закрывает. Логики не нашел.

По "accel-cmd shutdown" всегда корректно закрывает.

 

Продолжаю тестировать IPoE - shared=1, ifcfg=1, mode=L2.

Добавился на стенд свитч с opt.82 username формируется с использованием opt.82 через lua.

При переключении клиента с порта в порт клиент на RENEW продолжает получать тот же IP - не анализируются опции Relay-Agent.

мне не на чем опцию82 отлаживать

Отписался в личку.

[Abram]

demidc3, судя по приведённым логам проблема не в модуле pptp, иначе бы дело до авторизации бы не дошло

Нашёл я, где грабли зарыты. Вот в этом параметре:

[radius]
acct-interim-interval=2592000

При таком значении наблюдается описанное поведение. Точную границу не искал, но при 1000000 ещё нормально.

И иногда записываемое при старте в лог сообщение "warn: failed to load pptp kernel module" на работоспособность тоже не влияет, как выяснилось.

Охренеть у вас интервал. Я думал, что 300 (5 минут) - это уже многовато. У вас это 30 суток? ЗАЧЕМ?