LINUX.ORG.RU
Форум — Admin  

pptpd: не разрывает соединение после потери связи с клиентом, клиент не может повторно подключиться

 , ,


0

1

Всем добрый день! Пытаемся решить такую задачу: в чистом поле на электрическом столбе повесить роутеры с прошивкой OpenWRT, к каждому подключены IP-камеры и 4G-модемы. Роутеры должны подключаться к серверу по PPTP, чтобы камеры было видно. Заменить PPTP на OpenVPN нельзя из-за политики владельцев сервера.

Что не получается: На сервере CentOS 6.3, установлен pptpd,настройки такие:

options.pptpd 

name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mppe-128
ms-dns 8.8.8.8
ms-dns 8.8.4.4
debug
nobsdcomp
novj
novjccomp
nologfd

Для клиентов в chap-secrets прописаны постоянные ip-адреса, поскольку по PPTP подключаются роутеры с видеокамерами, которые хочется видеть по конкретным адресам. При подключении клиентов для каждого создаётся сетевой интерфейс ppp0, ppp1, ppp2 и т.д. с этим ip-адресом. Если клиент разрывает соединение как положено - то проблем с повторным подключением нет. Созданный интерфейс моментально исчезает из ifconfig, как только нажимаем кнопку «отключить».

А вот если происходит обрыв связи - то повторно подключиться клиент уже не может. Отбивается с ошибкой 619. На сервере в это время такие логи: 

GRE: read(fd=6,buffer=611860,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Apr  5 13:09:38 omgtu pptpd[1917]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Кроме того, на сервере в ifconfig продолжает висеть интерфейс ppp0 (или ppp1, ppp2 и т.д.), соответствующий данному клиенту. Как будто клиент не отключался. И висит он сколько угодно долго - наверное, несколько часов. Наверное, можно дописать параметр lock в options.pptpd, который разрешает несколько подключений под одним аккаунтом. Но это ведь не выход: постоянный адрес клиента всё равно занят поднятым интерфейсом.

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

Яндекс предлагает в настройки добавить такие директивы в options.pptpd: 

lcp-echo-interval 30 # посылать эхо-пакеты каждые 30 секунд
lcp-echo-failure 2 # если ответа на два эхо-пакета нет, разрывать соединение
Но после пробы (ничего не изменилось) и внимательного чтения выяснилось, что эти директивы наоборот не для сервера, а для клиента - это он должен слать эхо-запросы серверу, и отключаться, если нет ответа. По крайней мере, так утверждают более авторитетные источники. С клиентами, кстати, проблем нет: после обрыва они сразу начинают попытки переподключения к серверу.

Подскажите пожалуйста, как заставить pptpd понимать, что клиента не видно.



Последнее исправление: vovkalenka (всего исправлений: 1)
← Централизация конфигурации portage
Защита от ddos - ssh →

lcp-* директивы они И для сервера и для клиента. У меня всё прекрасно переподключается, ~600 клиентов в пике на одном сервере.

Какая версия ppp(на сервер и на клиенте) и pptpd(на сервере)?

Pinkbyte ★★★★★
()

Скрипт напиши

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

Сервер: 

ppp.x86_64              2.4.5-23.0.rhel6
pptp-release.noarch     4-6.rhel6       installed
pptpd.x86_64            1.3.4-2.el6     installed



Клиент:

kmod-ppp - 3.10.49-1
kmod-pppoe - 3.10.49-1
kmod-pppox - 3.10.49-1
luci-proto-ppp - 0.12+svn-r10530-1
ppp - 2.4.7-2
ppp-mod-pppoe - 2.4.7-2
ppp-mod-pptp - 2.4.7-2

Вообще расширения lcp-* действительно заработали на сервере. Отключают соединение. Понадобилась перезагрузка самого сервера. Видимо, рестарта pptpd для их подключения оказалось недостаточно.

Интерфейс ppp+ отключается правильно, через минуту после обрыва. В настройках поставили интервал 30, попыток 2. 

Apr  5 16:05:24 omgtu pppd[8641]: Connect: ppp1 <--> /dev/pts/7
Apr  5 16:05:57 omgtu pppd[8641]: CCP: timeout sending Config-Requests
Apr  5 16:06:08 omgtu pppd[8226]: No response to 2 echo-requests
Apr  5 16:06:08 omgtu pppd[8226]: Serial link appears to be disconnected.
Apr  5 16:06:08 omgtu pppd[8226]: pptpd-logwtmp.so ip-down ppp0

Теперь другая проблема, со стороны клиента. Обрыв соединения мы имитируем перезагрузкой клиента (чтобы проверить как обрыв связи, так и мигание электричества). Он, как и положено, сразу пытается снова подключиться после загрузки своей системы к серверу. И если эта попытка приходится на ту минуту, в которую прежний сетевой интерфейс ppp на сервере ещё не отключен, подключиться не может (логи сервера): 

Apr  5 16:05:23 omgtu pptpd[8640]: CTRL: Client 178.216.222.10 control connection started
Apr  5 16:05:24 omgtu pptpd[8640]: CTRL: Starting call (launching pppd, opening GRE)
Apr  5 16:05:24 omgtu pppd[8641]: Plugin /usr/lib64/pptpd/pptpd-logwtmp.so loaded.
Apr  5 16:05:24 omgtu pppd[8641]: pptpd-logwtmp: $Version$
Apr  5 16:06:08 omgtu pppd[8226]: pptpd-logwtmp.so ip-down ppp0
Apr  5 16:06:11 omgtu pptpd[8225]: GRE: read(fd=6,buffer=611860,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Apr  5 16:06:11 omgtu pptpd[8225]: CTRL: PTY read or GRE write failed (pty,gre)=(6,8)
Apr  5 16:06:11 omgtu pptpd[8225]: CTRL: Client 178.216.222.10 control connection finished

настройки у клиента такие: network: 

config interface 'vpn'
        option ifname 'pptp-vpn'
        option proto 'pptp'
        option server 'example.com'
        option defaultroute '0'
        option username 'username'
        option password 'password'
        option keepalive '10 5'

options: 

debug
#logfile /dev/null
logfile /var/log/ppp
noipdefault
noaccomp
nopcomp
nocrtscts
lock
maxfail 0
lcp-echo-failure 2
lcp-echo-interval 30

А вот сам клиент считает, что подключился, и даже «получает» ответы на эхо-запросы (лог клиента): 

Plugin pptp.so loaded.
PPTP plugin version 1.00
pptp: call manager for example.com
window size:    50
call id:        1
control connection
unix_sock
Sent control packet type is 1 'Start-Control-Connection-Request'
Received Start Control Connection Reply
Client connection established.
Sent control packet type is 7 'Outgoing-Call-Request'
Received Outgoing Call Reply.
Outgoing call established (call ID 1, peer's call ID 1024).
using channel 1
Using interface pptp-vpn
Connect: pptp-vpn <--> pptp (example.com)
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x5648eebf>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8078f1c1> <pcomp> <accomp>]
sent [LCP ConfRej id=0x1 <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x5648eebf>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x5648eebf>]
rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8078f1c1>]
sent [LCP ConfAck id=0x2 <asyncmap 0x0> <auth chap MS-v2> <magic 0x8078f1c1>]
sent [LCP EchoReq id=0x0 magic=0x5648eebf]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x5648eebf>]
rcvd [LCP EchoReq id=0x0 magic=0x8078f1c1]
sent [LCP EchoRep id=0x0 magic=0x5648eebf]
rcvd [CHAP Challenge id=0xe1 <2420c8c251cd09c19ca635f1d7e1275b>, name = "pptpd"]
added response cache entry 0
sent [CHAP Response id=0xe1 <427aa910391e49b5ed9cb59f244bfc8000000000000000003af30dae084c5eef581bf6649acdcc2f3b3bb1641317138b00>, name = "username"]
rcvd [LCP EchoRep id=0x0 magic=0x8078f1c1]
................................................
System time change detected.
sent [LCP EchoReq id=0x1 magic=0x5648eebf]
...............................................
rcvd [LCP EchoRep id=0x5 magic=0x8078f1c1]
rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
discarding proto 0x80fd in phase 5
rcvd [LCP EchoReq id=0x1 magic=0x8078f1c1]
...................................
rcvd [LCP EchoRep id=0xb magic=0x8078f1c1]
Echo Reply received.
rcvd [LCP EchoReq id=0x2 magic=0x8078f1c1]
.................................................
rcvd [LCP EchoRep id=0x17 magic=0x8078f1c1]
Echo Reply received.
rcvd [LCP EchoReq id=0x4 magic=0x8078f1c1]
sent [LCP EchoRep id=0x4 magic=0x5648eebf]
.................................................
rcvd [LCP EchoRep id=0x1a magic=0x8078f1c1]
sent [LCP EchoReq id=0x1b magic=0x5648eebf]

Но интерфейс pptp-vpn ни на клиенте, ни на сервере при таком фейковом подключении не поднимается. Если же инициировать на клиенте в данной ситуации подключение снова, вручную - клиент отправит запрос серверу на отключение, потом благополучно подключится по настоящему.

vovkalenka
() автор топика
Ответ на: комментарий от Pinkbyte

Добавили 

persist
holdoff 15
Ситуация не изменилась. При установленном соединении отправляем клиента в перезагрузку, он быстро перезагружается и пробует подключиться, неуспешно. Затем ждём минуту с момента начала перезагрузки клиента, пока сервер закроет у себя интерфейс ppp+, перезапускаем подключение на клиенте, и тогда подключается. Если перезапустить до прошествия минуты - не подключится. Сам клиент переподключаться не пробует. Думает, что подключен после первой неудачной попытки.

vovkalenka
() автор топика
Ответ на: комментарий от Pinkbyte

Ещё одна странность. Оказывается, даже когда интерфейс ppp+ уже отключен, клиент может не подключаться совсем: сервер даёт ошибку CCP: timeout sending Config-Requests. Помогает перезагрузка сервера.

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

Проблемы на сервере. Либо у вас что-то нестандартное в конфигурации. Проверьте на другом дистрибутиве или соберите ppp и pptpd из исходников.

Pinkbyte ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Централизация конфигурации portage
Admin
Защита от ddos - ssh →