Настройка VPN в Linux

NOname · 3 апреля 2009

О настройке VPN (PPTP) клиента в Linux.

========================================================

Данный вариант настройки PPTP был использован в Linux FedoraCore 7, позже

без изменений перенесен в Fedora 10. Возможно, для других дистрибутивов

будет необходимо скорректировать конфигурацию, поэтому комментарии и

дополнения приветствуются.

Очевидно, что данный вариант настройки не является единственно верным.

Всегда есть выбор, например, куда прописать пароль - в файл /etc/chap-secrets

или /etc/peer/bla-bla-bla, а список опций для pppd может быть сокращен или

наоборот дополнен. Поэтому, если кто-то обнаружит, что "все работает" даже

если убрать опцию "refuse-eap", то желательно бы указать, почему именно

лучше работать без нее.

Нужно иметь в виду, что в современные Linux-дистрибутивы включают пакет

NetworkManager и в дополнение к нему поставляется пакет NetworkManager-pptp.

Если вы используете NetworkManager для настройки локальной сети, то имеет

смысл попробовать через него настроить и VPN-соединение тоже.

Пока же оставим это в планах на будущее и приведем вариант настройки типа

"плаваем на веслах". Все операции по конфигурированию и старту VPN-соединения

следует выполнять под системным пользователем root. Команды, которые следует

выполнить будут указаны в строках, начинающихся с

[root@alpha ~]# . . . .

Далее по возможности будут указываться результат выполнения команды.

1. Необходимо, что бы в системе были установлены пакеты ppp и pptp.

Если у Вас rpm-based дистрибутив то следует выполнить команду:

[root@alpha ~]# yum -y update ppp pptp

или нечто этому подобное с учетом специфики packet-manager'а вашего

Linux-дистрибутива.

2. Создадим конфигурационный файл для pppd. Назовем его

/etc/ppp/peers/progress

содержимое файла:

### CUT HERE ####

lock

noauth

refuse-eap

refuse-chap

refuse-mschap

#require-mppe-128

user ВАШ_ЛОГИН

password ВАШ_ПАРОЛЬ

defaultroute

### CUT HERE ####

[используйте ТОЛЬКО тот текст, который находится МЕЖДУ строками "### CUT HERE ####"]

В нижних строках задайте свою пару login / password, используемую для авторизации.

Закрываем файл на чтение/запись для "всех" командой:

[root@alpha ~]# chmod 600 /etc/ppp/peers/progress

3. Создадим файл /etc/ppp/ip-up.local, его содержимое:

### CUT HERE ####

#!/bin/bash

echo `date` ": up: $@" >> /var/log/ppp.log

GW=`netstat -rn | grep '^0.0.0.0 ' | awk '{print $2}'`

if [ -z $GW ]; then

GW=`netstat -rn | grep '^172.16.0.0 ' | awk '{print $2}'`

if [ -z $GW ]; then

exit 1 # can't search IP address of gateway

fi

/sbin/route add -net 172.16.0.0 netmask 255.254.0.0 gw $GW

/sbin/route delete default gw $GW

/sbin/route add default gw $5

### CUT HERE ####

4. Создадим файл /etc/ppp/ip-down.local, его содержимое:

### CUT HERE ####

#!/bin/bash

(echo `date` ": down: $@"; echo) >> /etc/ppp/ppp.log

GW=`netstat -rn | grep '^172.16.0.0 ' | awk '{print $2}'`

if [ -z $GW ]; then

exit 1 # can't search IP address of gateway

fi

route delete -net 172.16.0.0 netmask 255.254.0.0 gw $GW

/sbin/route add default gw $GW

### CUT HERE ####

5. Сделаем исполняемыми оба последних файла:

[root@alpha ~]# chmod 755 /etc/ppp/ip-up.local /etc/ppp/ip-down.local

Теперь проверим, как все это работает. Допустим, наш постоянный IP адрес

172.16.13.53, IP шлюза - 172.16.13.54. В обычной конфигурации без поднятого

VPN маршрутизация выглядит следующим образом

[root@alpha ~]# netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

172.16.13.52 0.0.0.0 255.255.255.252 U 0 0 0 eth0

0.0.0.0 172.16.13.54 0.0.0.0 UG 0 0 0 eth0

Последняя строка означает, что default gw = 172.16.13.54.

Установим pptp-соединение командой:

[root@alpha ~]# pptp 10.87.65.254 nodetach call progress

Using interface ppp0

Connect: ppp0 <--> /dev/pts/2

CHAP authentication succeeded

MPPE 128-bit stateless compression enabled

not replacing existing default route via 172.16.13.54

local IP address 78.24.26.1

remote IP address 78.24.27.255

Поскольку была указана опция nodetach, то pptp останется "висеть" в терминале

после установки соединения с сервером, но в случае ошибки подключения

завершится с выходом в командную строку shell. В этом случае попробуйте

вызвать pptp, добавив еще аргумент debug и проанализировать вывод.

Сейчас не разрывая сессию проверим с другой линии, что же получилось.

[root@alpha ~]# /sbin/ifconfig

................................................................

ppp0 Link encap:Point-to-Point Protocol

inet addr:78.24.26.1 P-t-P:78.24.27.255 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1496 Metric:1

RX packets:10 errors:0 dropped:0 overruns:0 frame:0

TX packets:10 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:3

RX bytes:292 (292.0 b) TX bytes:238 (238.0 b)

................................................................

Появился новый сетевой интерфейс ppp0 и мы получили от VPN-сервера

адрес 78.24.26.1. Посмотрим, что с маршрутизацией:

[root@alpha ~]# netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

78.24.27.255 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0

172.16.13.52 0.0.0.0 255.255.255.252 U 0 0 0 eth0

172.16.0.0 172.16.13.54 255.254.0.0 UG 0 0 0 eth0

0.0.0.0 78.24.27.255 0.0.0.0 UG 0 0 0 ppp0

Ip 172.16.13.54 теперь является шлюзом для локальной сети (172.16.0.0/255.254.0.0),

а шлюзом по умолчанию является VPN-сервер с адресом 78.24.27.255.

Теперь проверим, как ходят пакеты в Интернет:

[root@alpha ~]# traceroute www.yandex.ru

traceroute to www.yandex.ru (77.88.21.3), 30 hops max, 40 byte packets

1 ppp-bras0.istra.ru (78.24.27.255) 0.666 ms 0.637 ms 0.551 ms

2 gw1.istra.ru (78.24.24.248) 0.778 ms 0.838 ms 0.659 ms

3 91.143.38.129 (91.143.38.129) 1.423 ms 1.208 ms 1.116 ms

4 91.143.38.9 (91.143.38.9) 1.894 ms 1.859 ms 1.781 ms

5 ix2-m9.yandex.net (193.232.244.93) 21.228 ms 21.076 ms 20.933 ms

6 silicon-vlan901.yandex.net (77.88.56.125) 2.648 ms 2.552 ms 2.332 ms

7 toyota-vlan4.yandex.net (213.180.210.181) 268.002 ms 267.859 ms 267.821 ms

8 www.yandex.ru (77.88.21.3) 3.083 ms 2.947 ms 3.115 ms

Раз пакеты уходят через роутер ppp-bras0.istra.ru (IP=78.24.27.255),

значит все настроено правильно.

Прервем VPN-сессию, нажатием <Ctrl><C> в том окне где был запущен pptp

и еще раз проверим маршрутизацию:

[root@alpha ~]# netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

172.16.13.52 0.0.0.0 255.255.255.252 U 0 0 0 eth0

0.0.0.0 172.16.13.54 0.0.0.0 UG 0 0 0 eth0

Теперь таблица маршрутизации вернулась в первоначальное состояние.

bukhalo.aleksandr · 26 мая 2009

Ubuntu 9.04

не забываем про pptp-linux и NetworkManager-pptp

Sherman · 10 июня 2009

Здравствуйте, можно получить рекомендации по настройке VPN для kubuntu 9.04. Пробовал проделать те же манипуляции что и для FedoraCore, но ничего не вышло.

bukhalo.aleksandr · 18 июля 2009

Здравствуйте, можно получить рекомендации по настройке VPN для kubuntu 9.04. Пробовал проделать те же манипуляции что и для FedoraCore, но ничего не вышло.

рекомендации вы вряд ли получите, могу лишь сказать что на kde плазмоид knetwork вроде не поддерживает pptp соединение (только OpenVPNCisco-compatible и VPN client (vpnc)). так что только через CLI, пакет pptp-linux должен быть на диске. и если нужно больше иформации, то в гугл. и не забывайте про mppe, в debian с этим проблемы

ITField · 28 сентября 2012

Есть проблемы с подключением. Использую pptpclient 1.7.2-4 и имею частые проблемы с соединением. Во первых бывает так, что соединение с сервером (vpn.istra.ru) есть а интернета нет - помогает переподключение к vpn серверу. Ещё бывает такое, что сервер постоянно рвёт соединение по 200 раз на день и ещё подключается раза с 3-го 5-го. Воспрос собственно такой. У меня одного такое или у всех такая нестабильность подключения. Может мне нехватает каких-то опций? Использует сервер протоколы сжатия? Есть красноглазики, которые помогут разобраться?

claus · 28 сентября 2012

/var/log/messages в студию

так же прихватит netstat -rn с активным pptp(когда коонект есть а тырнета нет) и с погашенным pptp

Можно ifconfig -a дать, что бы осознать что там у тебя.

2 ITField ты не поверишь, но 80% програмуль и гуёв юзает pptpclient Можно подробнее расписать?

Так же желательно указать дистриб. По попутно if-up и if-down скрипты. (На дебиане я менят таблицу маршрутизации через if-up/if-down скрипты)

ITField · 28 сентября 2012

/var/log/messages в студию
так же прихватит netstat -rn с активным pptp(когда коонект есть а тырнета нет) и с погашенным pptp

Можно ifconfig -a дать, что бы осознать что там у тебя.

2 ITField ты не поверишь, но 80% програмуль и гуёв юзает pptpclient Можно подробнее расписать?

Так же желательно указать дистриб. По попутно if-up и if-down скрипты. (На дебиане я менят таблицу маршрутизации через if-up/if-down скрипты)

ну, тогда погнали =)

Дистрибув Archlinux, апдейты самые последние, версия pptp указана (пакет собирается без патчей replacedefaultroute), GUI не использую. Поднимаю локальную сеть через netcfg, vpn поднимаю демоном, роутинг поднимаю ip-up/down скриптами.

/etc/network.d/eth0 (ничего интересного)

   CONNECTION='ethernet'
  DESCRIPTION='cifra1 ethernet connection'
  INTERFACE='eth0'
  IP='static'
  ADDR='172.16.*.*'
  ROUTES=('172.16.0.0/255.254.0.0 via 172.16.*.*')
  GATEWAY='172.16.*.*'
  DNS=('172.17.0.1')

/etc/rc.d/ppp0 (сам демон для подключения)

   #!/bin/bash

  . /etc/rc.conf
  . /etc/rc.d/functions

  DAEMON=ppp0
  ARGS=

  [ -r /etc/conf.d/$DAEMON ] && . /etc/conf.d/$DAEMON


  case "$1" in
start)
  stat_busy "Starting $DAEMON"
  pon cifra1 updetach persist &>/dev/null
  if [ $? = 0 ]; then
	add_daemon $DAEMON
	stat_done
  else
	stat_fail
	exit 1
  fi
 ;;
stop)
  stat_busy "Stopping $DAEMON"
  poff cifra1 &>/dev/null
  if [ $? = 0 ]; then
	rm_daemon $DAEMON
	stat_done
  else
	stat_fail
	exit 1
  fi
 ;;
restart)
  $0 stop
  sleep 1
  $0 start
 ;;
*)
  echo "usage: $0 {start|stop|restart}"  
  esac

/etc/ppp/peers/cifra1 (сам конфиг)

   pty "pptp vpn.istra.ru --nolaunchpppd"
  name ***
  remotename PPTP
  file /etc/ppp/options.pptp
  ipparam cifra1

/etc/ppp/options.pptp (остальные опции подключения)

   # Lock the port
  lock

  # Authentication
  # We don't need the tunnel server to authenticate itself
  noauth

  # We won't do PAP, EAP, CHAP, or MSCHAP, but we will accept MSCHAP-V2
  # (you may need to remove these refusals if the server is not using MPPE)
  refuse-pap
  refuse-eap
  refuse-chap
  refuse-mschap

  # Compression
  # Turn off compression protocols we know won't be used
  nobsdcomp
  #nodeflate

/etc/ppp/ip-up.d/01-defaultroute.sh (запускается при старте pptp)

   ip route del default
  ip route add default dev ppp0

/etc/ppp/ip-down.d/01-defaultroute.sh (запускается после разрыва pptp)

   ip route del default
  ip route add dev eth0

/var/log/messages.log (выхоп pptp)

Sep 24 22:43:13 ITField pptp[512]: anon log[usage:pptp.c:127]: pptp called with wrong arguments, program not started.
Sep 24 22:50:37 ITField pppd[526]: pppd options in effect:
Sep 24 22:50:37 ITField pppd[526]: debug		# (from command line)
Sep 24 22:50:37 ITField kernel: [  992.637656] PPP generic driver version 2.4.2
Sep 24 22:50:37 ITField pppd[526]: nodetach		# (from command line)
Sep 24 22:50:37 ITField pppd[526]: logfd 2		# (from command line)
Sep 24 22:50:37 ITField pppd[526]: dump		# (from command line)
Sep 24 22:50:37 ITField pppd[526]: noauth		# (from /etc/ppp/options.pptp)
Sep 24 22:50:37 ITField pppd[526]: refuse-pap		# (from /etc/ppp/options.pptp)
Sep 24 22:50:37 ITField pppd[526]: refuse-chap		# (from /etc/ppp/options.pptp)
Sep 24 22:50:37 ITField pppd[526]: refuse-mschap		# (from /etc/ppp/options.pptp)
Sep 24 22:50:37 ITField pppd[526]: refuse-eap		# (from /etc/ppp/options.pptp)
Sep 24 22:50:37 ITField pppd[526]: name sanya777		# (from /etc/ppp/peers/cifra1)
Sep 24 22:50:37 ITField pppd[526]: remotename PPTP		# (from /etc/ppp/peers/cifra1)
Sep 24 22:50:37 ITField pppd[526]:		 # (from /etc/ppp/options.pptp)
Sep 24 22:50:37 ITField pppd[526]: pty pptp vpn.istra.ru --nolaunchpppd		# (from /etc/ppp/peers/cifra1)
Sep 24 22:50:37 ITField pppd[526]: crtscts		# (from /etc/ppp/options)
Sep 24 22:50:37 ITField pppd[526]:		 # (from /etc/ppp/options)
Sep 24 22:50:37 ITField pppd[526]: asyncmap 0		# (from /etc/ppp/options)
Sep 24 22:50:37 ITField pppd[526]: lcp-echo-failure 4		# (from /etc/ppp/options)
Sep 24 22:50:37 ITField pppd[526]: lcp-echo-interval 30		# (from /etc/ppp/options)
Sep 24 22:50:37 ITField pppd[526]: hide-password		# (from /etc/ppp/options)
Sep 24 22:50:37 ITField pppd[526]: ipparam cifra1		# (from /etc/ppp/peers/cifra1)
Sep 24 22:50:37 ITField pppd[526]: proxyarp		# (from /etc/ppp/options)
Sep 24 22:50:37 ITField pppd[526]: nobsdcomp		# (from /etc/ppp/options.pptp)
Sep 24 22:50:37 ITField pppd[526]: noipx		# (from /etc/ppp/options)
Sep 24 22:50:37 ITField pppd[526]: pppd 2.4.5 started by alex, uid 0
Sep 24 22:50:37 ITField pppd[526]: Using interface ppp0
Sep 24 22:50:37 ITField pppd[526]: Connect: ppp0 <--> /dev/pts/0
Sep 24 22:50:37 ITField pptp[532]: anon log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Sep 24 22:50:37 ITField pptp[539]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Sep 24 22:50:37 ITField pptp[539]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Sep 24 22:50:37 ITField pptp[539]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Sep 24 22:50:38 ITField pptp[539]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Sep 24 22:50:38 ITField pptp[539]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Sep 24 22:50:38 ITField pptp[539]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 37392).
Sep 24 22:50:38 ITField pppd[526]: CHAP authentication succeeded
Sep 24 22:50:38 ITField kernel: [  993.813392] PPP Deflate Compression module registered
Sep 24 22:50:38 ITField pppd[526]: local  IP address 188.65.13.253
Sep 24 22:50:38 ITField pppd[526]: remote IP address 188.65.13.0
Sep 24 22:51:38 ITField pptp[539]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Sep 24 22:52:38 ITField pptp[539]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Sep 24 22:53:38 ITField pptp[539]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Sep 24 22:54:38 ITField pptp[539]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received
Sep 24 22:55:38 ITField pptp[539]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Sep 24 22:56:38 ITField pptp[539]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Sep 24 22:57:38 ITField pptp[539]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Sep 24 22:58:38 ITField pptp[539]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Sep 24 22:58:45 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 2575 (expecting 2574, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4877 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4878 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4879 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4880 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4881 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4882 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4883 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4884 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4886 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4887 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4888 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4889 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4890 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4891 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4893 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4894 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4895 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4896 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4897 (expecting 4876, lost or reordered)
Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 4898 (expecting 4876, lost or reordered)

После примерно вот так

Sep 24 22:58:48 ITField pptp[532]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 5175 (expecting 4876)
Sep 24 22:58:48 ITField pptp[532]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 5176 (expecting 4876)
Sep 24 22:58:48 ITField pptp[532]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 5177 (expecting 4876)
Sep 24 22:58:48 ITField pptp[532]: anon warn[decaps_gre:pptp_gre.c:426]: discarding bogus packet 5178 (expecting 4876)

Ну и строки такого стиля

Sep 24 22:58:48 ITField pptp[532]: anon log[decaps_gre:pptp_gre.c:414]:  buffering packet 4898 (expecting 4876, lost or reordered)

Занимают львиную долю лога. Больше адских ерроров не находил никаких и варнингов тоже.

netstat -rn

Думаю будет неуместен. У меня ещё мост запущен, и в KVM виртуалки крутятся, там тоже роутинга тьма, но не в них дело. Я пробовал убунту с ноутбука было тоже самое, даже ещё хуже. Интернет постоянно сыпался. Так же пакеты куда-то пропадали, но потом само исчезло.

Раньше было ни единого разрыва!)

claus · 28 сентября 2012

1. С Archlinux я не работал, по этому дать однозначные ответы я не могу.

/etc/network.d/eth0 действительно ничего интересного) Но всё же, а вдруг)

Ну в общем в pptp обвзяке вроде всё норм, но я бы в sh скриптах дабавил бы полный путь к утилитам...

А вот в логах много ошибок типа "Получен и положен в буфер пакет N (ожидали N-1)"

ifconfig ppp0 и ifconfig eth0 стал ещё интереснее. (Нужен именно статус iface. Что-то мне подсказывает, что я знаю куда надо копать) Хочу убедиться.

Изменено 28 сентября 2012 пользователем claus

ITField · 28 сентября 2012

А вот в логах много ошибок типа "Получен и положен в буфер пакет N (ожидали N-1)"
ifconfig ppp0 и ifconfig eth0 стал ещё интереснее. (Нужен именно статус iface. Что-то мне подсказывает, что я знаю куда надо копать) Хочу убедиться.

Я не совсем понял что вы хотите

Вот выхлоп ifconfig

[alex@ITField ~]$ ifconfig 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
	inet 172.16.*.*  netmask 255.255.255.0  broadcast 172.16.*.*
	inet6 fe80::21a:4dff:fe9f:a3c5  prefixlen 64  scopeid 0x20<link>
	ether 00:12:23:34:45:56  txqueuelen 1000  (Ethernet)
	RX packets 12261550  bytes 10785134625 (10.0 GiB)
	RX errors 0  dropped 0  overruns 0  frame 0
	TX packets 11218398  bytes 3285711329 (3.0 GiB)
	TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
	inet 188.65.13.160  netmask 255.255.255.255  destination 188.65.13.0
	ppp  txqueuelen 3  (Point-to-Point Protocol)
	RX packets 1112113  bytes 568840287 (542.4 MiB)
	RX errors 0  dropped 0  overruns 0  frame 0
	TX packets 1253822  bytes 663868200 (633.1 MiB)
	TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Может покрутить mtu?

slider · 28 сентября 2012

Точно,спец=))))))))))))))))))))))))))))))

Читаю и удивляюсь

Да еще надо быть дурачком,чтобы спрашивать тут про никсы=)

Ладно вопросы то интересные,а тут из серии первогодок,видать он реально на нем,только развлекался)а из работы использовал дефолт

Можете в логи не смотреть,все решается на много проще,поскольку я хочу еще посмотреть как сфейлится данный персонаж,то подожду логического завершения темы :)

p.s повторюсь,ставь обратно винду))))

Изменено 28 сентября 2012 пользователем slider

claus · 28 сентября 2012

Да это именно то что я хотел)

Стоит.... особенно учитывая что на iface нету дропов и ошибок.

eth3	  Link encap:Ethernet  HWaddr F4:6D:04:6D:5A:3F  
	  inet addr:172.16.193.177  Bcast:172.16.193.179  Mask:255.255.255.252
	  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
	  RX packets:300811397 errors:0 dropped:0 overruns:0 frame:0
	  TX packets:303661180 errors:0 dropped:0 overruns:0 carrier:0
	  collisions:0 txqueuelen:1000 
	  RX bytes:2655130414 (2.4 GiB)  TX bytes:1440283372 (1.3 GiB)

ppp0	  Link encap:Point-to-Point Protocol  
	  inet addr:188.65.12.146  P-t-P:188.65.13.0  Mask:255.255.255.255
	  UP POINTOPOINT RUNNING MULTICAST  MTU:1400  Metric:1
	  RX packets:279678 errors:0 dropped:0 overruns:0 frame:0
	  TX packets:382477 errors:0 dropped:0 overruns:0 carrier:0
	  collisions:0 txqueuelen:3 
	  RX bytes:33103519 (31.5 MiB)  TX bytes:283999510 (270.8 MiB)

add

p.s. 2 Slider. Я думаю не стоит так рьяно на кого-то кидаться с кулаками.... И делать какие то выводы. И если честно, мне обсалютно всё равно как и кем ставит себя ITField. Он обратился за помощью, я решил эту помощь оказать, если вы образуете свое самомнение за счёт нападок на других, то мне вас жаль.

Изменено 28 сентября 2012 пользователем claus

claus · 28 сентября 2012

2 Slider

Ну и ещё одна мысль

"Чем больше глаз смотрит, тем больше ошибок можно найти" (с) Торвальдс Линус

ITField · 28 сентября 2012

Точно,спец=))))))))))))))))))))))))))))))
Читаю и удивляюсь

Да еще надо быть дурачком,чтобы спрашивать тут про никсы=)

Ладно вопросы то интересные,а тут из серии первогодок,видать он реально на нем,только развлекался)а из работы использовал дефолт

Можете в логи не смотреть,все решается на много проще,поскольку я хочу еще посмотреть как сфейлится данный персонаж,то подожду логического завершения темы :)

p.s повторюсь,ставь обратно винду))))

Ну раз вы обладаете достаточными знаниями, чтобы решить эту проблему, расскажите как. Я например не очень хорошо разбираюсь в сетях, и не отрицаю этого, а вы пытаетесь показать свою крутизну оскорбительными сообщениями не несущими полезной информации, на каждом форуме есть индивидумы вроде вас, мы все привыкли.

ITField · 28 сентября 2012

Connect: ppp0 <--> /dev/pts/1
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x3c00a479> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <accomp> <pcomp> <mru 1500> <magic 0x99b86bb5> <auth chap MS-v2>]
sent [LCP ConfAck id=0x1 <accomp> <pcomp> <mru 1500> <magic 0x99b86bb5> <auth chap MS-v2>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x3c00a479> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x3c00a479]
rcvd [CHAP Challenge id=0x1 <bb1e6875a8b3bd33d47d22cbb8e86af4>, name = ""]
sent [CHAP Response id=0x1 <f4c06fd62cbbe79a7a025ab3dc5a74ce0000000000000000c453274cbc9324a21634713b5885
d5e149ca25524124b60800>, name = "***"]
rcvd [LCP EchoRep id=0x0 magic=0x99b86bb5]
rcvd [CHAP Success id=0x1 "S=3AEF7B1D85DAFEE720F1939640E22C31A164157D"]
CHAP authentication succeeded
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <addr 188.65.13.0> <compress VJ 0f 00>]
sent [IPCP ConfAck id=0x1 <addr 188.65.13.0> <compress VJ 0f 00>]
rcvd [IPCP ConfNak id=0x1 <addr 188.65.14.120>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 188.65.14.120>]
rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 188.65.14.120>]
Cannot determine ethernet address for proxy ARP
local  IP address 188.65.14.120
remote IP address 188.65.13.0
Script /etc/ppp/ip-up started (pid 3607)
Script /etc/ppp/ip-up finished (pid 3607), status = 0x0
sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15>]
rcvd [LCP ProtRej id=0x1 80 fd 01 01 00 0c 1a 04 78 00 18 04 78 00]
Protocol-Reject for 'Compression Control Protocol' (0x80fd) received

Выставил 1400 вроде перестал сыпать в лог. Посмотрю, как дальше будет себя вести.

claus · 28 сентября 2012

Должно быть лучше. По крайней мере я не сумел найти ещё что-нибудь.

Конечно для полноты картины хотелось бы увидеть данные с обородувания Прогресса о коолизиях и ошибках на вашем порту, но думаю они не предоставят тут подобную информацию.

А так да. На будующие у vpn и pptp mtu всегда должен быть меньше, чем у реального iface, через который организуется этот канал.

ITField · 28 сентября 2012

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

А так да. На будующие у vpn и pptp mtu всегда должен быть меньше, чем у реального iface, через который организуется этот канал.

Техподдерка говорит, что Linux они не поддерживают)

ITField · 28 сентября 2012

Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5472 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5473 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5474 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5482 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5483 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5484 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5485 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5486 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5487 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5488 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5489 (expecting 5463, lost or reordered)

Полетели дальше)

claus · 28 сентября 2012

Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5472 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5473 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5474 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5482 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5483 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5484 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5485 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5486 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5487 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5488 (expecting 5463, lost or reordered)
Sep 28 17:37:27 ITField pptp[3829]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 5489 (expecting 5463, lost or reordered)

Полетели дальше)

хм.. Лан давай анализировать сеть.

traceroute vpn.istra.ru при выключенном pptp

ping vpn.istra.ru (штучек 20)

ping -s 1500 vpn.istra.ru (то же штучек 20) (вообще с параметром надо поиграться. Нужно что быв размер пакета равнялся mtu)

Можно играться в попытке вылечить:

Так же можно добавить для pptp ключик --nobuffer тогда он не будет буферизировать пакеты, но от потерь мы не избавимся.

Ещё можно попробовать контролировать длину пакета через iptables

iptables -t mangle -A FORWARD -p tcp -o ppp0 --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1250 (ещё меньше сделаем) или

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Но это всё лечение симптомов. Проблема состоит в том что pptp теряет пакеты....

Очень хочется что бы кто-нить из инженеров прогресса глянул что у вас там на порту. Ваша система не регистрирует коолизи и ошибки на iface.

Проблема может скрываться внутри самого pptp.

Изменено 28 сентября 2012 пользователем claus

ITField · 28 сентября 2012

Очень хочется что бы кто-нить из инженеров прогресса глянул что у вас там на порту. Ваша система не регистрирует коолизи и ошибки на iface.
Проблема может скрываться внутри самого pptp.

Может позвонить спросить или здесь на форуме спросить у сотрудников?

claus · 28 сентября 2012

Вообщем резюмирую происходящие:

Symptom: while running pptp, this message appears, which may or may not be associated with any other problem:

log[decaps_gre:pptp_gre.c:397]: buffering out-of-order packet 272 (expecting 271)

Diagnosis: this is a normal situation. Many network links drop or re-order packets as a normal part of their operation. This message informs you that a packet was lost or re-ordered. The TCP network infrastructure above this level will retransmit the lost data.

(out-of-order in this context relates to the sequence of the packets, and should not be confused with the use of the phrase in some locales to warn that public equipment is not operating.)

Solution: if the loss is higher than the physical layer should provide, check the physical layer for problems.

You can also use the link statistics feature of pptp, see the man page for how to obtain and understand the statistics.

Перевод:

буферизация "out-of-order" ("не в обычном порядке") пакета

Признак: при работе pptp, появляется это сообщение, которое, возможно, связано и с любым другим событием:

log[decaps_gre:pptp_gre.c:397]: buffering out-of-order packet 272 (expecting 271)

Диагноз: это - нормальная ситуация. Множество сетевых соединений блокирует или меняет порядок следования пакетов в общем потоке пакетов - это обычная нормальная штатная ситуация как часть в их работе. Данное сообщение информирует вас о том, что пакет был потерян или у него был изменён порядок следования в общем потоке пакетов. Сетевая инфраструктура TCP (в модели OSI), которая находится выше этого уровня, ретранслирует потерянные данные.

(фраза "out-of-order" ("не в обычном порядке") в этом контексте относится к последовательности пакетов, и не должна быть перепутана с использованием фразы в некоторых переводах на другие языки для предупреждения о неработоспособности общедоступного оборудования.)

Решение: если потери пакетов происходят на уровне выше, чем физический уровень (в модели OSI), проверьте физический уровень (в модели OSI) на наличие возможных проблем.

Вы можете также использовать возможность подсчёта статистики PPTP-соединения, для получения и понимания статистики смотрите руководство страниц man.

Нужно искать проблемы на физике, если их нет, либо менять ppp клиент (не повезло archlinux), либо играться с опиями у pptp и iptables.

Очень хочется что бы кто-нить из инженеров прогресса глянул что у вас там на порту. Ваша система не регистрирует коолизи и ошибки на iface.
Проблема может скрываться внутри самого pptp.

Может позвонить спросить или здесь на форуме спросить у сотрудников?

Подобную информацию они вряд ли предоставят по телефону.

Может кто-нить заглянет в тему. И даст ответ.

p.s попробуйте через icmp проверить физику канал (по бросайтесь большими пакетами в vpn.istra.ru или 172.17.0.1, желательно отправлять много пакетов (много это пару тысяч))

У прогрессовцев я спросил. Они добрые) скорее всего помогут, но сегодня пятница и 10 вечера, у них есть семьи, так что ответ может прийти с запозданием.

Изменено 28 сентября 2012 пользователем claus

ITField · 28 сентября 2012

 [alex@ITField ~]$ tracepath vpn.istra.ru
 1:  172.16.*.*										0.255ms pmtu 1500
 1:  172.16.*.*									  3008.058ms !H
  Resume: pmtu 1500

 --- vpn.istra.ru ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99018ms
rtt min/avg/max/mdev = 0.142/0.250/0.549/0.089 ms

вот это уже интереснее, достучаться не получается

 [alex@ITField ~]$ ping -s 1500 vpn.istra.ru
PING vpn.istra.ru (10.87.65.254) 1500(1528) bytes of data.
From 172.16.*.* icmp_seq=1 Destination Host Unreachable
From 172.16.*.* icmp_seq=2 Destination Host Unreachable
From 172.16.*.* icmp_seq=3 Destination Host Unreachable

вот собственно максимальный размер пакета

 [alex@ITField ~]$ ping -s 1300 vpn.istra.ru
PING vpn.istra.ru (10.87.65.254) 1300(1328) bytes of data.
From 172.16.*.* icmp_seq=1 Destination Host Unreachable
From 172.16.*.* icmp_seq=2 Destination Host Unreachable
From 172.16.*.* icmp_seq=3 Destination Host Unreachable
From 172.16.*.* icmp_seq=4 Destination Host Unreachable
^C
--- vpn.istra.ru ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3001ms
pipe 4
[alex@ITField ~]$ ping -s 1299 vpn.istra.ru
PING vpn.istra.ru (10.87.65.244) 1299(1327) bytes of data.
1307 bytes from vpn.istra.ru (10.87.65.244): icmp_req=1 ttl=63 time=0.494 ms
1307 bytes from vpn.istra.ru (10.87.65.244): icmp_req=2 ttl=63 time=0.541 ms
1307 bytes from vpn.istra.ru (10.87.65.244): icmp_req=3 ttl=63 time=0.550 ms
^C
--- vpn.istra.ru ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.494/0.528/0.550/0.030 ms
[alex@ITField ~]$

claus · 28 сентября 2012

а у вас роутер есть?

PING vpn.istra.ru (10.87.65.254) 1300(1328) bytes of data.

From 172.16.*.* icmp_seq=1 Destination Host Unreachable

From 172.16.*.* icmp_seq=2 Destination Host Unreachable

From 172.16.*.* icmp_seq=3 Destination Host Unreachable

Потому как это выглядит крайне странным

учитывая что

[alex@ITField ~]$ ping -s 1299 vpn.istra.ru

PING vpn.istra.ru (10.87.65.244) 1299(1327) bytes of data.

1307 bytes from vpn.istra.ru (10.87.65.244): icmp_req=1 ttl=63 time=0.494 ms

1307 bytes from vpn.istra.ru (10.87.65.244): icmp_req=2 ttl=63 time=0.541 ms

1307 bytes from vpn.istra.ru (10.87.65.244): icmp_req=3 ttl=63 time=0.550 ms

Alair · 28 сентября 2012

Длинный у вас разговор какой-то.

Если без роутера:

1)Попробовать с любого другого дистрибутива. Лайв-убунту ту же. Если есть возможность, то и с винды.

2)На всякий случай попробовать с другой сетевой картой.

Сразу станет ясно в чём проблема.

Если роутер есть, то попробовать без него.

Видел такую картинку с пингом при проблеме на кабеле у провайдера (пара скруток). Но косяк может быть и в железках.

Изменено 28 сентября 2012 пользователем Alair

ITField · 29 сентября 2012

Роутера нет. Вот с подключенным vpn

[alex@ITField ~]$ ping -s 1500 vpn.istra.ru
PING vpn.istra.ru (10.87.65.244) 1500(1528) bytes of data.
1508 bytes from vpn.istra.ru (10.87.65.244): icmp_req=1 ttl=63 time=0.611 ms
1508 bytes from vpn.istra.ru (10.87.65.244): icmp_req=2 ttl=63 time=0.512 ms
1508 bytes from vpn.istra.ru (10.87.65.244): icmp_req=3 ttl=63 time=0.512 ms
^C
--- vpn.istra.ru ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.512/0.545/0.611/0.046 ms

[alex@ITField ~]$ ping -s 1379 vpn.istra.ru
PING vpn.istra.ru (10.87.65.244) 1379(1407) bytes of data.
1387 bytes from vpn.istra.ru (10.87.65.244): icmp_req=1 ttl=63 time=0.477 ms
1387 bytes from vpn.istra.ru (10.87.65.244): icmp_req=2 ttl=63 time=0.526 ms
^C
--- vpn.istra.ru ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.477/0.501/0.526/0.033 ms

Это с отключенным. Это сегодня. Компьютер на ночь не выключался, соединение не разрывалось.

Пакеты не теряются, ни на шлюз ни на vpn сервер. Пускал 5-7т. пакетов.

claus · 29 сентября 2012

Что сделал?-)

2 Alair разговор всегда долгий) это ж Linux)))

Настройка VPN в Linux

Рекомендованные сообщения

NOname 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

bukhalo.aleksandr 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

Sherman 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

bukhalo.aleksandr 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

ITField 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

claus 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

ITField 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

claus 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

ITField 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

slider 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

claus 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

claus 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

ITField 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

ITField 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

claus 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

ITField 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

ITField 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

claus 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

ITField 0

Поделиться сообщением

Ссылка на сообщение

Поделиться на других сайтах

claus 0

Поделиться сообщением