LINUX.ORG.RU
ФорумAdmin

Регулярные падения PPTP при нагрузке

 , ,


1

2

Приветствую Вас, уважаемые форумчане. Надеюсь разрешить тут одну проблему. Суть в том, что при небольшой нагрузке на сеть все прекрасно работает, но при попытке что-нибудь скачать соединение мигом рвется. Логи в /var ничего не говорят. Сам я пользуюсь archlinux'ом, VPN клиент - pptp. Подключаюсь вот таким вот скриптом:

pptpsetup --create NIKS --server server --username username --password password --start
ip route add default dev ppp0
Специально проверил настройки mtu на сайте провайдера - все стоит правильно: 1400

Надеюсь на вашу помощь

Сколько видел таких тем - нигде никогда ничего хорошего не выходило.
А можно просто для коллекции: какой толщины канал?

thesis ★★★★★ ()
Ответ на: комментарий от thesis

Канал толстый. С серверами моей страны выходит около 80 мбит/с. С бангладешем около 15 мбит/с

BioHazarD ()
Ответ на: комментарий от BioHazarD

Проблема практически наверняка не в pptpd, а в pppd, а от него никуда не деться.
Сунь 'kdebug 1' в /etc/ppp/options, или куда там это положено совать. Может, что-нибудь скажет.

thesis ★★★★★ ()
Ответ на: комментарий от BioHazarD

А теперь гляди: http://linuxgazette.net/165/misc/lg/erratically_dying_pppd.html

Curiously enough- the number of times my connection dies (or PPPD dies) has considerably decreased (or even not happening), since I have started running 'pppd' in 'kdebug' mode

Отсюда видим: баг, как и предсказано, живет в pppd, и его никто так и не починил.
Там в треде народ с lcp играется, но по мне это довольно бессмысленная пляска с бубном.

thesis ★★★★★ ()
Ответ на: комментарий от BioHazarD

Должно-то должно, но вот похоже, что увы.
Dimez, обрати внимание. Если помнишь еще тот тред.
Это именно оно и есть: pppd, похоже, поломан от рождения, и никто его не чинит. Каналы толстеют, жалоб все больше. Рано или поздно придет человек из Кемерово, но пока приходится терпеть и городить костыли.

thesis ★★★★★ ()
Ответ на: комментарий от BioHazarD

Проблема если и в pppd, то только в связке с pptp.

С l2tp оно работает кошерно и не глючит никогда. Проверено с билайновским тырнетом домашним и траффиком ~100мбит постоянным. Работает и не жужжит.

Вообще пора уже от pptp отказываться, он убог от рождения. l2tp рулит.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

Опа.
А покажи, если не трудно, options.xl2tpd и скажи в каком режиме xl2tpd работает - юзерспейсном или ядерном?
Или у тебя не xl2tpd вообще?

thesis ★★★★★ ()
Последнее исправление: thesis (всего исправлений: 1)

Для справки, команду pptpsetup достаточно выполнить один раз без ключа --start и стартовать соединение командой pppd call NIKS (в вашем случае указываете имя соединения NIKS).

Следующее, проверьте качество линии до первого маршрутизатора. Если у вас IP назначен на физическом интерфейсе вручную, сделайте

sudo ping -f -c 100 -s 1600 <server>
и смотрите packet loss, если есть потери, в этом проблема. Если IP получаете динамически, то смотрите
ip route
на тему маршрута до pptp-сервера, то есть будет что-то вида
<server> via <gateway> ...
Вот тот адрес, который будет после via и есть шлюз между вами и pptp-сервером, его и надо попробовать пропинговать простой командой
ping -c 5 <gateway>
если ответы будут, потом можно попробовать флудящим пингом проверить потери (команда выше, которая делается через sudo). Если на шлюз покажет 100% потерь пугаться не стоит, просто на шлюзе стоит защита от icmp-flood, тогда нужно проверить максимальный размер фрейма на который шлюз ещё отвечает и указать этот размер ключом -s <packetlen>.

Да, возможен вариант, что вам выдаётся IP из одной подсети с pptp-сервером, тогда маршрута не будет в таблице и можно сразу пробовать пинговать сервер.

Ещё я бы рекомендовал посмотреть в сторону accel-pptp, не спутайте с accel-ppp. Последний - это реализация исключительно серверной части разных протоколов (L2TP/PPPoE/PPTP) с разными плюшками, а первый - непосредственно ускоритель pptp-соединений. В частности Вас должен интересовать плагин к pppd, который отвечает за связь pppd с ядерным модулем pptp, что ускорит работу самого туннеля (повысит скорость и немного понизит задержки), плюс должно решить проблему с падением pppd (у меня решало, по-крайней мере). Правда, стоит отметить, что исходники слегка протухшие и не факт, что соберутся без бубна.

nickleiten ★★★ ()
Ответ на: комментарий от thesis

xl2tpd, не ядерный. В ядерном у меня когда-то толи ядро падало, толи еще какие залипы были, я на него забил и с тех пор не проверял.

xl2tpd.conf

[global]

[lac beeline]
tx bps = 100000000
lns = tp.internet.beeline.ru
redial = yes
redial timeout = 60
max redials = 2147483647
require chap = yes
require authentication = no
ppp debug = no
pppoptfile = /etc/ppp/options.l2tp.client
autodial = yes

options.l2tp.client:

name xxxx
noauth
noaccomp
nopersist
maxfail 0
unit 128

# xl2tpd -v
xl2tpd version:  xl2tpd-1.3.1

# pppd --version
pppd version 2.4.5

Так работает на двух серверах (моём и у родителей) в билайне - траблов нет. Коннект держится неделями, вот это я перезагружал сам:

# zcat syslog*gz | grep pppd
Feb  7 21:41:29 nas pppd[18912]: Terminating on signal 15
Feb  7 21:41:29 nas pppd[18912]: Connect time 22021.2 minutes.
Feb  7 21:41:29 nas pppd[18912]: Sent 1972532287 bytes, received 3166808139 bytes.
Feb  7 21:41:29 nas pppd[18912]: Modem hangup
Feb  7 21:41:29 nas pppd[18912]: Connection terminated.
Feb  7 21:41:29 nas pppd[18912]: Exit.
Коннект провисел 2 недели.

Один раз, правда, такая херня в лог валиться начала:

Feb  3 05:59:52 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xde53
Feb  3 05:59:54 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xbd37
Feb  3 06:00:09 nas pppd[18912]: Protocol-Reject for unsupported protocol 0x9aed
Feb  3 06:05:26 nas pppd[18912]: Protocol-Reject for unsupported protocol 0x8009
Feb  3 06:08:21 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xbd92
Feb  3 06:09:04 nas pppd[18912]: Protocol-Reject for unsupported protocol 0x8c76
Feb  3 06:15:00 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xd7d8
Feb  3 06:15:29 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xcaa9
Feb  3 06:15:40 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xd432
Feb  3 06:17:22 nas pppd[18912]: Protocol-Reject for unsupported protocol 0xf1b6
Feb  3 06:17:22 nas pppd[18912]: Protocol-Reject for unsupported protocol 0x921c
Валилась-валилась целый день, потом перестала. Видать билайн что-то у себя мурыжит.

blind_oracle ★★★★★ ()
Ответ на: комментарий от nickleiten

Да, плюсую accel-pptp. Это плагин к pppd, который позволяет работать без дополнительных приблуд в виде pptp-клиента, чисто силами самого pppd. Позволяет сильно снизить нагрузку на проц как минимум, на дохлых роутерах типа WRT54G мне помогало сильно в свое время.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

Спасибо за конфиги. Надо будет поднять тестовый стенд и погонять все самому.
Кстати, как я понимаю, «Protocol-Reject for unsupported protocol» - тоже часто встречаемая ошибка как раз по данной теме.

Что касается accel-pptp, то его куски же давным-давно впихнули в ядро, сделав отдельное существование бесмысленным.

thesis ★★★★★ ()
Ответ на: комментарий от nickleiten

Огромное спасибо, ребята. Разобрался с accel-pptp - уже час без вылетов

BioHazarD ()
Ответ на: комментарий от thesis

сделав отдельное существование бесмысленным.

Плагин в пппд всё равно нужен. И к нему поддержка в ядре.

Protocol-Reject for unsupported protocol

2-3 февраля такое вылезло один раз, больше не видел.

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

thesis ★★★★★ ()
Ответ на: комментарий от nickleiten

Я, похоже, поторопился. Все давно подключение отваливается.

вот /etc/ppp/peers/NIKS

plugin pptp.so
pptp_server vpn.niks.by
#lock
noauth
nobsdcomp
nodeflate
name LOGIN
remotename NIKS
ipparam NIKS
BioHazarD ()
Ответ на: комментарий от blind_oracle

pppd в связке с accel-pptp работает железобетонно в недороутерах.

pppd с связке с poptop падал от нагрузки, потому-что у poptop нет ядерного модуля и трафик бегает в юзерспейсе вместо кернелспейса при accel-pptp.

Deleted ()
Ответ на: комментарий от thesis

Я хз, как вы его настраиваете. У меня стоит несколько poptop-серверов на разных провайдерах для велосипедного аналога HA для нескольких клиентских вендов, всё пашет, каналы на серверных сторонах - гигабит, на клиентах - сотка. Ну да, когда полоса растёт, нагрузка на проц возрастает, но, с другой стороны, никто там торренты через vpn не гоняет.

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от Deleted

poptop
для вендов

Вооот. Разницы вроде быть не должно, но фиг знает.

Я ж тебе в прошлой теме про accel-pptp писал :)

А ТС уже отписался, что радость была преждевременной.

thesis ★★★★★ ()

Такая же проблема. Ничего не нагуглилось кроме mtu.

kinik ★★☆ ()
Ответ на: комментарий от Deleted

Для _клиентских_ вендов.

Именно. На проблему жалуются обладатели _клиентских_ люниксов.
Вон чуть выше - еще один ITT.

thesis ★★★★★ ()
Ответ на: комментарий от BioHazarD

Отключайте все остальные компрессии, типа ″novj″, ″novjccomp″. Понижайте размер пакета ″mtu 1300″, ″mru 1300″. Включите ″debug″, чтобы посмотреть, какой режим соедиения согласуется и, может, в логах будет указано, кто инициатор разрыва связи.

mky ★★★★★ ()
Ответ на: комментарий от Deleted

А каковы каналы до клиента и насколько бывают забиты лично тобой?
А то на 10мбит оно и УМВР.
Ну и кинь клиентских конфигов, будь добр. Для коллекции.

thesis ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.