pptp и skype

[LKharlamov]

Доброго времени суток!
Вопрос скорее просто к людям имеющим опыт в использовании pptp, нежели к биллингу. Как то давно ещё когда на серваке была ubuntu 8.04 решил попробывать голосовую связь, насколько помню, пробывал через мэйл-агента, и заметил сразу такое явление как разрыв впн соединения через произвольные промежутки времени, т.е. можно минуту поговорить и обрыв, можно 10 проболтать успеть. Но изза отсутствия нормальной гарнитуры и особой надобности на этот вопрос тогда забил
Чичас в руки попал ноут, и собственно есть камера с микрофоном, решил поставить скайп, и ситуация годовалой давности повторилась с точностью, операционка уже на серваке другая - ubuntu 9.10. Вот даже и незнаю с чего начинать копать?... может кто сталкивался с подобным явлением...

В /var/log/debug появляется следующие:

Код: Выделить всё

Mar  6 23:18:18 gw349 pptpd[11455]: CTRL: Reaping child PPP[11456]
Mar  6 23:18:19 gw349 pppd[11456]: Script /etc/ppp/ip-down started (pid 12187)
Mar  6 23:18:19 gw349 pppd[11456]: Script /etc/ppp/ip-down finished (pid 12187), status = 0x0
Mar  6 23:18:19 gw349 pppd[11456]: RADATTR plugin removed file /var/run/radattr.ppp2.

При естественном отключении впн-соединения, лог выглядит так:

Код: Выделить всё

Mar  6 23:42:08 gw349 pppd[12658]: rcvd [LCP TermReq id=0xa "i\37777777630*\37777777704\000<\37777777715t\000\000\000\000"]
Mar  6 23:42:08 gw349 pppd[12658]: Script /etc/ppp/ip-down started (pid 12774)
Mar  6 23:42:08 gw349 pppd[12658]: sent [LCP TermAck id=0xa]
Mar  6 23:42:08 gw349 pppd[12658]: Script /etc/ppp/ip-down finished (pid 12774), status = 0x0
Mar  6 23:42:09 gw349 pptpd[12657]: CTRL: Reaping child PPP[12658]
Mar  6 23:42:09 gw349 pppd[12658]: RADATTR plugin removed file /var/run/radattr.ppp2.

[LKharlamov]

В это время в syslog написалось:

Код: Выделить всё

Mar  6 23:18:18 gw349 pptpd[11455]: GRE: read(fd=7,buffer=80514a0,len=8260) from network failed: status = -1 error = Protocol not available
Mar  6 23:18:18 gw349 pptpd[11455]: CTRL: GRE read or PTY write failed (gre,pty)=(7,6)
Mar  6 23:18:18 gw349 pptpd[11455]: CTRL: Reaping child PPP[11456]
Mar  6 23:18:18 gw349 pppd[11456]: Modem hangup
Mar  6 23:18:18 gw349 pppd[11456]: pptpd-logwtmp.so ip-down ppp2
Mar  6 23:18:19 gw349 pppd[11456]: Connect time 28.7 minutes.
Mar  6 23:18:19 gw349 pppd[11456]: Sent 3595485 bytes, received 99379091 bytes.
Mar  6 23:18:19 gw349 pppd[11456]: Script /etc/ppp/ip-down started (pid 12187)
Mar  6 23:18:19 gw349 pppd[11456]: Connection terminated.
Mar  6 23:18:19 gw349 pppd[11456]: Script /etc/ppp/ip-down finished (pid 12187), status = 0x0
Mar  6 23:18:19 gw349 pppd[11456]: RADATTR plugin removed file /var/run/radattr.ppp2.
Mar  6 23:18:19 gw349 pppd[11456]: Exit.
Mar  6 23:18:19 gw349 pptpd[11455]: CTRL: Client 10.57.170.120 control connection finished

Интересно шо это может значить...

[LKharlamov]

http://poptop.sourceforge.net/dox/qna.html

Q. What does Protocol not available mean?

A. The network refuses to let the stream pass.

You might see something like this in your logs:
pppd[124]: Connect: ppp0 <--> /dev/pts/1
pptpd[123]: GRE: read(fd=7,buffer=80515e0,len=8260) from network failed:
status = -1 error = Protocol not available
pptpd[123]: CTRL: GRE read or PTY write failed (gre,pty)=(7,6)
pppd[124]: Modem hangup
pppd[124]: Connection terminated.
pppd[124]: Exit.

This is caused by EPROTO error number returned by read, which in turn is caused by the receipt of an ICMP protocol unreachable message from either the local host or some router or gateway between the server and the client. The usual cause of the ICMP packet is a router or gateway that refuses to pass the GRE stream. You can use tcpdump to find where the ICMP packet comes from, and correct it.

See also the same error as seen by a client. The solution there is probably not relevant.

Думаю это мой случай, тока чёто не понял я сути происходящего...

[NiTr0]

tcpdump на все icmp, и ждать разрыва.

[LKharlamov]

Действительно, после того как прилетает вот это:

Код: Выделить всё

12:52:02.327008 IP 10.57.132.239 > 10.57.168.116: ICMP 10.57.132.239 protocol 47 unreachable, length 168

, сразу разрывается впн-тоннель, почитал вот это:

http://pptpclient.sourceforge.net/howto ... ead_eproto

Protocol not available
Symptom: the following messages appear before the tunnel is established:
log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:580]: Client connection established.
log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:708]: Outgoing call established (call ID 0, peer's call ID 0).
log[decaps_gre:pptp_gre.c:215]: short read (4294967295): Protocol not available
log[callmgr_main:pptp_callmgr.c:245]: Closing connection
log[pptp_conn_close:pptp_ctrl.c:307]: Closing PPTP connection
log[call_callback:pptp_callmgr.c:88]: Closing connection

Diagnosis: usually caused by the client not binding to the GRE socket early enough during the connection sequence. The first GRE packet from the server causes an ICMP protocol unreachable reply. This happens more frequently on high speed connections.

Workaround: load the ip_gre module. This prevents the ICMP protocol unreachable reply from being generated.
# modprobe ip_gre

Solution: upgrade to pptp-linux 1.2.0, which binds the GRE socket prior to calling the server. Loading the ip_gre module should not be needed.

Включение модуля ip_gre не помогло решить проблемму.

Зафильтровал эти пакеты на файрволле так:

Код: Выделить всё

iptables -I INPUT -i wan -p icmp --icmp-type protocol-unreachable -j DROP

Впн-тоннели рваться перестали, но думаю это не самый верный путь решения проблеммы, мож у кого есть какие идеи?

[NiTr0]

разбираться, чего 10.57.132.239 шлет такой ответ.

[xend]

Отключается VPN pptp из-за того, что на машине клиенте уже есть маршрут по умолчанию, а при подключении vpn добавляется ещё один.
Прописывайте маршруты правильно.
Маршрут по умолчанию должен быть только в инет.

[LKharlamov]

Да вродекак с двумя маршрутами по умолчанию винда нормально работает, первый по умолчанию добавляется при получении дхцп, второй позже после подключения впн - у него метрика меньше, и всё идёт по нему. Описаная в теме проблемма появляется только при использовании ip-телефонии, все остальные приложения к разрыву не приводят. Видимо именно при использовании протокола UDP возникают какието сложности...

[xend]

Просто попробуй, в WinXP такой проблемы нет, в Vista, а возможно и в Win 7, есть.

[anstep]

Не знаю как висте (но думаю так же), но в вин7 это решилось включением брандмауэра винды и отключени в нём всей фильтрации