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

Centos 6, PPTP, lost carrier

 , ,


0

1

Доброго времени суток! Есть VPN-сервер, от которого есть логин, пасс и адрес. Методом подключения с windows-машины выяснил что поддерживается chap и mschap-v2 авторизация. С windows-машины подключается идеально.

С соседней linux-машины никак не выходит наладить _СТАБИЛЬНОЕ_ подключение. С никсов подключается один-два раза из сотни. Если подключилось - всё работает хорошо. Как только отключился - снова можно пол-дни долбиться для подключения.

Куда копать?

Конфиг ppp-peers: 

debug
dump
pty "pptp IP_HERE --nolaunchpppd"
name sf-1c
file /etc/ppp/options.pptp
ipparam wbpptp
nodeflate
Конфиг options.pptp: 
lock
nobsdcomp
nodeflate
defaultroute
noipdefault
noauth
refuse-pap
refuse-eap
Логи подключения: 
Mar 21 14:37:36 pppd[1320]: pppd options in effect:
Mar 21 14:37:36 pppd[1320]: debug debug#011#011# (from command line)
Mar 21 14:37:36 pppd[1320]: nodetach#011#011# (from command line)
Mar 21 14:37:36 pppd[1320]: dump#011#011# (from command line)
Mar 21 14:37:36 pppd[1320]: noauth#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:37:36 pppd[1320]: refuse-pap#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:37:36 pppd[1320]: refuse-eap#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:37:36 pppd[1320]: name sf-1c#011#011# (from /etc/ppp/peers/wbpptp)
Mar 21 14:37:36 pppd[1320]: #011#011# (from /etc/ppp/options.pptp)
Mar 21 14:37:36 pppd[1320]: pty pptp IP_HERE --nolaunchpppd#011#011# (from /etc/ppp/peers/wbpptp)
Mar 21 14:37:36 pppd[1320]: ipparam wbpptp#011#011# (from /etc/ppp/peers/wbpptp)
Mar 21 14:37:36 pppd[1320]: noipdefault#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:37:36 pppd[1320]: defaultroute#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:37:36 pppd[1320]: nobsdcomp#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:37:36 pppd[1320]: nodeflate#011#011# (from /etc/ppp/peers/wbpptp)
Mar 21 14:37:36 pppd[1320]: pppd 2.4.5 started by root, uid 0
Mar 21 14:37:36 pppd[1320]: Using interface ppp0
Mar 21 14:37:36 pppd[1320]: Connect: ppp0 <--> /dev/pts/2
Mar 21 14:37:36 pptp[1321]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Mar 21 14:37:36 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Mar 21 14:37:36 pptp[1327]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Mar 21 14:37:36 pptp[1327]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Mar 21 14:37:37 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Mar 21 14:37:37 pptp[1327]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Mar 21 14:37:37 pptp[1327]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 0).
Mar 21 14:37:37 pppd[1320]: CHAP authentication succeeded
Mar 21 14:37:37 pppd[1320]: not replacing existing default route via Another_IP
Mar 21 14:37:37 pppd[1320]: local  IP address 192.168.50.51
Mar 21 14:37:37 pppd[1320]: remote IP address 192.168.190.1
Mar 21 14:38:06 pptp[1327]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Mar 21 14:38:06 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Mar 21 14:38:38 pptp[1327]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Mar 21 14:38:38 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Mar 21 14:39:10 pptp[1327]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Mar 21 14:39:10 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Mar 21 14:39:42 pptp[1327]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Mar 21 14:39:42 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Mar 21 14:40:14 pptp[1327]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Mar 21 14:40:14 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Mar 21 14:40:46 pptp[1327]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Mar 21 14:40:46 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Mar 21 14:41:18 pptp[1327]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Mar 21 14:41:18 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Mar 21 14:41:50 pptp[1327]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Mar 21 14:41:50 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Mar 21 14:42:08 pppd[1320]: Terminating on signal 15
Mar 21 14:42:08 pppd[1320]: Modem hangup
Mar 21 14:42:08 pppd[1320]: Connect time 4.6 minutes.
Mar 21 14:42:08 pppd[1320]: Sent 14280 bytes, received 14700 bytes.
Mar 21 14:42:08 pptp[1327]: anon log[callmgr_main:pptp_callmgr.c:234]: Closing connection (unhandled)
Mar 21 14:42:08 pptp[1327]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Mar 21 14:42:08 pptp[1327]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
Mar 21 14:42:08 pppd[1320]: Connection terminated.
Mar 21 14:42:08 pppd[1320]: Exit.


Mar 21 14:59:39 pppd[1534]: pppd options in effect:
Mar 21 14:59:39 pppd[1534]: debug#011#011# (from /etc/ppp/peers/wbpptp)
Mar 21 14:59:39 pppd[1534]: dump#011#011# (from /etc/ppp/peers/wbpptp)
Mar 21 14:59:39 pppd[1534]: noauth#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:59:39 pppd[1534]: refuse-pap#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:59:39 pppd[1534]: refuse-eap#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:59:39 pppd[1534]: name sf-1c#011#011# (from /etc/ppp/peers/wbpptp)
Mar 21 14:59:39 pppd[1534]: #011#011# (from /etc/ppp/options.pptp)
Mar 21 14:59:39 pppd[1534]: pty pptp IP_HERE --nolaunchpppd#011#011# (from /etc/ppp/peers/wbpptp)
Mar 21 14:59:39 pppd[1534]: ipparam wbpptp#011#011# (from /etc/ppp/peers/wbpptp)
Mar 21 14:59:39 pppd[1534]: noipdefault#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:59:39 pppd[1534]: defaultroute#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:59:39 pppd[1534]: nobsdcomp#011#011# (from /etc/ppp/options.pptp)
Mar 21 14:59:39 pppd[1534]: nodeflate#011#011# (from /etc/ppp/peers/wbpptp)
Mar 21 14:59:39 pppd[1535]: pppd 2.4.5 started by root, uid 0
Mar 21 14:59:39 pppd[1535]: Using interface ppp0
Mar 21 14:59:39 pppd[1535]: Connect: ppp0 <--> /dev/pts/2
Mar 21 14:59:39 pptp[1536]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Mar 21 14:59:39 pptp[1546]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Mar 21 14:59:39 pptp[1546]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Mar 21 14:59:39 pptp[1546]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Mar 21 14:59:40 pptp[1546]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Mar 21 14:59:40 pptp[1546]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Mar 21 14:59:40 pptp[1546]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 0).
Mar 21 15:00:07 pptp[1546]: anon log[ctrlp_disp:pptp_ctrl.c:929]: Call disconnect notification received (call id 0)
Mar 21 15:00:07 pptp[1546]: anon log[ctrlp_error:pptp_ctrl.c:199]: Result code is 1 'Lost Carrier'. Error code is 0, Cause code is 0
Mar 21 15:00:07 pptp[1546]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state)
Mar 21 15:00:07 pppd[1535]: Modem hangup
Mar 21 15:00:07 pppd[1535]: Connection terminated.
Mar 21 15:00:07 pppd[1535]: Exit.

Когда не подключается вижу это: 

[root@srv:~]# pppd call wbpptp nodetach dump debug
pppd options in effect:
debug debug             # (from command line)
nodetach                # (from command line)
dump            # (from command line)
noauth          # (from /etc/ppp/options.pptp)
refuse-pap              # (from /etc/ppp/options.pptp)
refuse-eap              # (from /etc/ppp/options.pptp)
name sf-1c              # (from /etc/ppp/peers/wbpptp)
                # (from /etc/ppp/options.pptp)
pty pptp IP_HERE --nolaunchpppd           # (from /etc/ppp/peers/wbpptp)
ipparam wbpptp          # (from /etc/ppp/peers/wbpptp)
noipdefault             # (from /etc/ppp/options.pptp)
defaultroute            # (from /etc/ppp/options.pptp)
nobsdcomp               # (from /etc/ppp/options.pptp)
nodeflate               # (from /etc/ppp/peers/wbpptp)
using channel 112
Using interface ppp0
Connect: ppp0 <--> /dev/pts/2
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x64502a15> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x64502a15> <pcomp> <accomp>]
и т.д....

← подключение по ssh
Скрипт бекапа на bash →

Как только отключился - снова можно пол-дни долбиться для подключения.

А если перезагрузится? Сразу подключит?

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

Нет. От перезагрузки вообще никак не зависит.

Со вчерашнего дня висело соединение, пакеты шли без потерь по pptp. Сегодня утром погасил через pkill pppd и снова не могу подключиться, вот уже 20 минут как.

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

Значит моя мысль оказалась неверна. А винда и linux выходят через одно и тоже подключение к инет?

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

И да и нет. Пробовал и с одного подключения и с разных. В том числе, из разных дата-центров.

Поскольку, windows отовсюду подключается стабильно, а nix из разных ДЦ отваливается с одной и той же ошибкой - я склонен думать что проблема в конфиге на моей стороне.

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

Но все-таки разница возможна как я понял. Не может случаться так что винда идет напрямую а nix через nat ? Ваш случай мне до боли напоминает поведение pptp при работе через nat ( правда такое поведение будет одинаково в любой системе win, *nix)

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

Из трех разных ДЦ пробовал windows и nix подключение. Во всех случаях win подключается успешно.

Я в первую очередь подумал на закрытый gre, поэтому проверял tcpdump-ом и hping-ом. GRE успешно проходит =(

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

Попробовал, не помогло...

Поскольку время было на исходе - пришлось отказаться от настройки. Грешу на pptp-сервер (Dlink DFL-860e).

В итоге, сделал некий workaround.

Установил openvpn-сервер на одном из не сильно нагруженных серверов внутри сети. Установил openvpn-client на удаленном сервере. Прописал роутинг на удаленную машину через openvpn-сервер. Ну и закрыл все подключения кроме vpn из офисной подсети. Как-то так.

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

Так у вас сервер получается тоже свой. Тогда тут куча вариантов была даже с ним, начиная от посмотреть настройки через cli, заканчивая другим тунелем по описанию у него l2tp и ipsec еще есть, вы имхо выбрали худший вариант pptp.

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

На DFL я доступа не имею, а человек у которого есть доступ - по ряду причин не хочет взаимодействовать (Вопли «Я не сетевик» «У меня на винде всё работает» и всё такое)

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

Бывает. Но вообще сам факт такой именно «не работы» странен, точнее я не помню каких-то подводных камней кроме нат. (с конца 90-х и где-то до середины 0-х шамалил в местечковом прове, больше проблем как раз было под вин клиента подстроиться). Но то что я не помню не означает, что еще и других граблей нэма, хотя все равно очень странно, сейчас железные каробки по дэфолту «тупо» настроены и уж при соединениями с ними тоже проблем нет.
ЗЫ Как мысль, неизвестно что тот человек там нашаманил, от дэфолта. Мне вспомнился случай когда я очень долго и мучительно винадмину (в крупной компании) вынужден был вбивать в голову существование MX записей на dns, а он меня пытался убедить что такое невозможно (MX != A_основной_для_домена). Минут 30 на это потратил если не больше, спасал только мой авторитет.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← подключение по ssh
Admin
Скрипт бекапа на bash →