NOname 0 Опубликовано: 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 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 Теперь таблица маршрутизации вернулась в первоначальное состояние. 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
bukhalo.aleksandr 0 Опубликовано: 26 мая 2009 Ubuntu 9.04 не забываем про pptp-linux и NetworkManager-pptp 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Sherman 0 Опубликовано: 10 июня 2009 Здравствуйте, можно получить рекомендации по настройке VPN для kubuntu 9.04. Пробовал проделать те же манипуляции что и для FedoraCore, но ничего не вышло. 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
bukhalo.aleksandr 0 Опубликовано: 18 июля 2009 Здравствуйте, можно получить рекомендации по настройке VPN для kubuntu 9.04. Пробовал проделать те же манипуляции что и для FedoraCore, но ничего не вышло. рекомендации вы вряд ли получите, могу лишь сказать что на kde плазмоид knetwork вроде не поддерживает pptp соединение (только OpenVPNCisco-compatible и VPN client (vpnc)). так что только через CLI, пакет pptp-linux должен быть на диске. и если нужно больше иформации, то в гугл. и не забывайте про mppe, в debian с этим проблемы 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ITField 0 Опубликовано: 28 сентября 2012 Есть проблемы с подключением. Использую pptpclient 1.7.2-4 и имею частые проблемы с соединением. Во первых бывает так, что соединение с сервером (vpn.istra.ru) есть а интернета нет - помогает переподключение к vpn серверу. Ещё бывает такое, что сервер постоянно рвёт соединение по 200 раз на день и ещё подключается раза с 3-го 5-го. Воспрос собственно такой. У меня одного такое или у всех такая нестабильность подключения. Может мне нехватает каких-то опций? Использует сервер протоколы сжатия? Есть красноглазики, которые помогут разобраться? 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
claus 0 Опубликовано: 28 сентября 2012 /var/log/messages в студию так же прихватит netstat -rn с активным pptp(когда коонект есть а тырнета нет) и с погашенным pptp Можно ifconfig -a дать, что бы осознать что там у тебя. 2 ITField ты не поверишь, но 80% програмуль и гуёв юзает pptpclient Можно подробнее расписать? Так же желательно указать дистриб. По попутно if-up и if-down скрипты. (На дебиане я менят таблицу маршрутизации через if-up/if-down скрипты) 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ITField 0 Опубликовано: 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 виртуалки крутятся, там тоже роутинга тьма, но не в них дело. Я пробовал убунту с ноутбука было тоже самое, даже ещё хуже. Интернет постоянно сыпался. Так же пакеты куда-то пропадали, но потом само исчезло. Раньше было ни единого разрыва!) 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
claus 0 Опубликовано: 28 сентября 2012 (изменено) 1. С Archlinux я не работал, по этому дать однозначные ответы я не могу. /etc/network.d/eth0 действительно ничего интересного) Но всё же, а вдруг) Ну в общем в pptp обвзяке вроде всё норм, но я бы в sh скриптах дабавил бы полный путь к утилитам... А вот в логах много ошибок типа "Получен и положен в буфер пакет N (ожидали N-1)" ifconfig ppp0 и ifconfig eth0 стал ещё интереснее. (Нужен именно статус iface. Что-то мне подсказывает, что я знаю куда надо копать) Хочу убедиться. Изменено 28 сентября 2012 пользователем claus 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ITField 0 Опубликовано: 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? 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
slider 0 Опубликовано: 28 сентября 2012 (изменено) Точно,спец=)))))))))))))))))))))))))))))) Читаю и удивляюсь Да еще надо быть дурачком,чтобы спрашивать тут про никсы=) Ладно вопросы то интересные,а тут из серии первогодок,видать он реально на нем,только развлекался)а из работы использовал дефолт Можете в логи не смотреть,все решается на много проще,поскольку я хочу еще посмотреть как сфейлится данный персонаж,то подожду логического завершения темы :) p.s повторюсь,ставь обратно винду)))) Изменено 28 сентября 2012 пользователем slider 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
claus 0 Опубликовано: 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 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
claus 0 Опубликовано: 28 сентября 2012 2 Slider Ну и ещё одна мысль "Чем больше глаз смотрит, тем больше ошибок можно найти" (с) Торвальдс Линус 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ITField 0 Опубликовано: 28 сентября 2012 Точно,спец=))))))))))))))))))))))))))))))Читаю и удивляюсь Да еще надо быть дурачком,чтобы спрашивать тут про никсы=) Ладно вопросы то интересные,а тут из серии первогодок,видать он реально на нем,только развлекался)а из работы использовал дефолт Можете в логи не смотреть,все решается на много проще,поскольку я хочу еще посмотреть как сфейлится данный персонаж,то подожду логического завершения темы :) p.s повторюсь,ставь обратно винду)))) Ну раз вы обладаете достаточными знаниями, чтобы решить эту проблему, расскажите как. Я например не очень хорошо разбираюсь в сетях, и не отрицаю этого, а вы пытаетесь показать свою крутизну оскорбительными сообщениями не несущими полезной информации, на каждом форуме есть индивидумы вроде вас, мы все привыкли. 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ITField 0 Опубликовано: 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 вроде перестал сыпать в лог. Посмотрю, как дальше будет себя вести. 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
claus 0 Опубликовано: 28 сентября 2012 Должно быть лучше. По крайней мере я не сумел найти ещё что-нибудь. Конечно для полноты картины хотелось бы увидеть данные с обородувания Прогресса о коолизиях и ошибках на вашем порту, но думаю они не предоставят тут подобную информацию. А так да. На будующие у vpn и pptp mtu всегда должен быть меньше, чем у реального iface, через который организуется этот канал. 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ITField 0 Опубликовано: 28 сентября 2012 Должно быть лучше. По крайней мере я не сумел найти ещё что-нибудь. Конечно для полноты картины хотелось бы увидеть данные с обородувания Прогресса о коолизиях и ошибках на вашем порту, но думаю они не предоставят тут подобную информацию. А так да. На будующие у vpn и pptp mtu всегда должен быть меньше, чем у реального iface, через который организуется этот канал. Техподдерка говорит, что Linux они не поддерживают) 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ITField 0 Опубликовано: 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) Полетели дальше) 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
claus 0 Опубликовано: 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 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ITField 0 Опубликовано: 28 сентября 2012 Очень хочется что бы кто-нить из инженеров прогресса глянул что у вас там на порту. Ваша система не регистрирует коолизи и ошибки на iface.Проблема может скрываться внутри самого pptp. Может позвонить спросить или здесь на форуме спросить у сотрудников? 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
claus 0 Опубликовано: 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 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ITField 0 Опубликовано: 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 ~]$ 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
claus 0 Опубликовано: 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 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
Alair 0 Опубликовано: 28 сентября 2012 (изменено) Длинный у вас разговор какой-то. Если без роутера: 1)Попробовать с любого другого дистрибутива. Лайв-убунту ту же. Если есть возможность, то и с винды. 2)На всякий случай попробовать с другой сетевой картой. Сразу станет ясно в чём проблема. Если роутер есть, то попробовать без него. Видел такую картинку с пингом при проблеме на кабеле у провайдера (пара скруток). Но косяк может быть и в железках. Изменено 28 сентября 2012 пользователем Alair 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
ITField 0 Опубликовано: 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т. пакетов. 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах
claus 0 Опубликовано: 29 сентября 2012 Что сделал?-) 2 Alair разговор всегда долгий) это ж Linux))) 0 Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах