pptpd: загадочное Session timed out
Здравствуйте!
Бьюсь над проблемой обрыва VPN соединений (уже всю голову сломал... :'( ): соединения у пользователей обрываются в большинстве случаев через 5-15 минут работы, но может провисеть и час-полтора. Вот логи соединения одного пользователя (для всех остальных они такие же, только учётные данные отличаются)
pptp-pppd.log
pptpd.log
Из логов выходит, что pptpd разрывает сессию, из за получения сигнала 15 от pppd - пир не отвечает на echo запросы - считая её мёртвой, но как узнать почему? Соединение поднимается, до разрыва туннель работает исправно, данные по нему ходят... вобщем всё работает как надо. Эксперименты с lcp-echo-interval/timeout результата никакого не принесли. Подскажите, как понять причину разрывов? Если нужно еще какую инфу - пишите - выложу.
ppp-2.4.4-r25
accel-pptp-9999 (0.8.4 - git версия)
- Для комментирования войдите или зарегистрируйтесь
Может у кого нибудь есть хоть
Может у кого нибудь есть хоть какие нибудь предположения? Буду признателен за любую подсказку т.к. уже не знаю, в каком направлении двигаться.Программа получает SIGTERM непонятно откуда и из за чего, может кто нибудь знает способы, как это можно попробовать отследить?
Какое у вас соединение с
Какое у вас соединение с инетом? На сколько сильно загружен канал? Сталкивался с таким поведением, когда pptp соединение работает через сильно загруженный adsl. В этом случае исходящий буфер модема переполняется, пакеты просто отбрасываются и ppp обрывает соединение по причине отсутствия lcp эха. Если ваш провайдер раздает вам инет через ppoe, то по этой же причине может падать соединение с провайдером.
Лечится это шейпером, так, чтобы в запасе оставалось около 10% реальной ширины канала.
К сожалению, провайдер в
К сожалению, провайдер в данной ситуации - это я... И соединение падает у моих клиентов. Логи которые я запостил - это логи со стороны сервера (с моей), с клиентской стороны логи посмотреть не получается т.к. это или виндовая машина или бытовой роутер. Самое занятное, что на linux машинах соединение не обрывается(!). Линия связи абонент <--> pptp сервер у нас 1 Гбит/сек, реальная загрузка около 150 Мбит/сек, lcp-echo приходит (конечно, есть и такие, от кого не приходит, там соединение естественно обрывается по вполне понятным причинам :) но сейчас речь не о них). Соединение обрывается без видимых причин и главный вопрос в чем могут быть эти причины и/или где их еще можно поискать...
Мониторил обрыв соединения в логах и параллельно tcpdump'ом,
логи
дамп
т.е. сервер (10.4.1.107) отправил клиенту (10.4.3.3) Term-Request, скорее всего потому что, как написано в логах, CTRL: Session timed out, ending call. Вот что это за session? Почему timeout? Ничего непонятно...
Попробовал в целях
Попробовал в целях тестирования заменить accel-pptp на стандартный pptpd из портов, рваться перестало(!), но к сожалению это не выход: после ~300 соединений сервер начинает присыпать по страшному захлёбываясь в прерываниях и соединения начинают отваливаться уже по этой причине. При соединении со стандартным pptpd tcpdump'ом обнаружил одно отличие: после обмена обычными LCP-Echo/Reply от сервера к клиенту передаётся еще вот такой пакет
подскажите кто знает, что это может значить?
Оффтоп после ~300
Оффтоп
маловасто будет - настройте сервачек.
P.S l2tp не спасет ваш хомнет ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
_Andrey
а упомянуть про это - забыли.
Ставим на BSD ?
evadim написал(а): а
Ненене, в первом посте указал, что юзаю accel-pptp-0.8.4 (git версия, ebuild кстати скачал прямо тут же - http://www.gentoo.ru/content/accel-pptp), до этого юзал 0.8.3 но проблема на нем тоже была и обновился как раз в надежде её поправить
Пардоньте :) ставил из дерева portage (net-dialup/pptpd-1.3.4), привык простоты ради в обиходе так называть portage
Сегодня влез в исходник, подредактировал pptpctrl.c из pptpd-1.3.3, идущего "в комплекте" с accel-pptp, в блоке
закомментировал goto leave_clear_call (строка 408), скомпилил, запустил - сессия не рвётся, вручную соединение разрывается как надо, при падении физического соединения сессия тоже завершается (при неполучении установленного количества LCP Echo-Reply), вроде теперь всё хорошо... Но смущает одно: раз разработчики включили этот блок проверки в программу знач он зачем-то нужен, а я в программировании слаб :) Подскажите, на какие грабли можно наступить убрав эту строку как это сделал я?
_Andrey написал(а): evadim
значит прозевал...