у меня два соединения, одно на 64Кб второе на 4Мб. Так вот то которое на 64 устанавливается, но трафик идет только исходящий, входящего буквально на 300 байт. 4Мб соединение летает без проблем.
К сожалению ситуация не меняется. По прежнему не могу стабильно выйти в Интернет . Когда же прогнозируется решение вопроса? P.S. Несколько раз удавалось выйти в Интернет после множества попыток поднятия VPN- соединения.
вот после обновления ПО проблемы начались у меня (до этого не было) - утром ppp туннель был жив, но пакеты не бегали, помог реконнект. сейчас с работы домой не могу достучаться, вероятно таки снова умер линк (аналогично не могу достучаться до oleg23 - хотя там ВПН соединение должно цепко держаться MPD-хой)
Информирую, как положено VPN всё равно не работает, подключиться удаётся с большим трудом, то всплывает сообщение об ошибке 738 о неназначении сервером адреса, то не идёт трафик, как и раньше, а если и удаётся всё-же подключиться, идёт большой входящий трафик от Вашего сервера к моему компьютеру, он увеличился, по сравнению, с тем, что было несколько дней назад, до обновления у Вас ПО в 2-3 раза. У меня не безлимитный, потому мне не доставляет удовольствия оплачивать за этот непонятно откуда возникающий на Вашей стороне ВХОДЯЩИЙ трафик. Моя сторона "чистая", система "голая" свежеустановленная (т.е. никаких программ не установлено), обновления отключены. При этом получается, что я должен оплачивать не только за объём переданной/принятой информации, а ещё и за время в Интернете. Это непорядок, извините за резкозть высказывания. P.S. Может я что-то недопонимаю по части трафика, проясните , пожалуйста, откуда он возникает ?
по своей проблеме. после поверхностного изучения выяснил что отваливается дефолтроут. до более глубокого изучения поставил костыль: echo "* * * * * root if [ -z `/usr/bin/fping 194.44.21.53 | grep alive`]; then route add default dev ppp0; fi">>/etc/crontab&&/etc/init.d/cron restart
после обновления Вами ПО перестал подниматься ВПН под линухом.. оптяь проблемы с маршрутами.. вывод route до ВПН Код: [root@localhost ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.16.12.0 * 255.255.255.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 172.16.12.1 0.0.0.0 UG 0 0 0 eth0 и после поднятия ВПН Код: [root@localhost ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.16.0.1 172.16.12.1 255.255.255.255 UGH 0 0 0 eth0 sputnik.donapex * 255.255.255.255 UH 0 0 0 ppp0 172.16.12.0 * 255.255.255.0 U 0 0 0 eth0 172.16.0.0 * 255.255.0.0 U 0 0 0 ppp0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default 172.16.12.1 0.0.0.0 UG 0 0 0 eth0 что я забыл?
проделал данную операцию.. трафик до гугля доходит, до меня - нет таблица превратилась в Код: [root@localhost ~]# route delete default&& route add default dev ppp0 [root@localhost ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 172.16.0.1 172.16.12.1 255.255.255.255 UGH 0 0 0 eth0 sputnik.donapex * 255.255.255.255 UH 0 0 0 ppp0 172.16.12.0 * 255.255.255.0 U 0 0 0 eth0 172.16.0.0 * 255.255.0.0 U 0 0 0 ppp0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default * 0.0.0.0 U 0 0 0 ppp0
хм. скажи в одной консоли traceroute google.com а в другой tcpdump -ippp0 - может это прольет свет на проблему?..
Слава волшебнику body и другим волшебникам команды Donapex Team , вроде бы с проблемой VPN справились , аж полегчало на душе :up: Спасибо велике P.S. Интересно, что после переналадки VPN у меня поменялись IP сервера и назначаемый IP адрес клиенткой машины для работы в Интернете ...
traceroute выдет звезды tcdump -ippp 016:03:49.758891 IP vpn124.donapex.net.64000 > jc-in-f99.google.com.traceroute: UDP, length 40 16:03:49.762533 IP vpn124.donapex.net.64001 > jc-in-f99.google.com.33435: UDP, length 40 16:03:49.766828 IP vpn124.donapex.net.64002 > jc-in-f99.google.com.33436: UDP, length 40 16:03:49.770451 IP vpn124.donapex.net.64003 > jc-in-f99.google.com.33437: UDP, length 40 16:03:49.774455 IP vpn124.donapex.net.64004 > jc-in-f99.google.com.33438: UDP, length 40
а я вот только щас всмотрелся в табличку... почему 172.16.0.0 прописан через ppp0? кто такой 169.254.0.0 и почему это висит на апексянском интерфейсе? у меня табличка роутинга выглядит примерно так Код: root@vsd:/home/vsd# ip r 172.17.1.140 via 172.16.8.1 dev eth2 172.17.1.7 via 172.16.8.1 dev eth2 194.44.21.57 dev ppp0 proto kernel scope link src 192.168.253.209 172.17.29.0/24 via 172.17.25.253 dev eth0 172.17.26.0/24 via 172.17.25.253 dev eth0 172.17.27.0/24 via 172.17.25.253 dev eth0 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 172.17.25.0/24 dev eth0 proto kernel scope link src 172.17.25.151 172.17.7.0/24 via 172.16.8.1 dev eth2 172.17.20.0/24 via 172.16.8.1 dev eth2 172.17.2.0/24 via 172.16.8.1 dev eth2 172.17.3.0/24 via 172.16.8.1 dev eth2 172.16.8.0/24 dev eth2 proto kernel scope link src 172.16.8.3 172.17.32.0/24 via 172.16.8.1 dev eth2 172.17.1.0/24 via 172.17.25.253 dev eth0 172.16.0.0/16 via 172.16.8.1 dev eth2 10.254.0.0/16 via 10.254.0.110 dev tun0 10.254.0.0/16 dev tun0 proto kernel scope link src 10.254.0.45 default dev ppp0 scope link если убрать всё что не относится к апексу то так: Код: 194.44.21.57 dev ppp0 proto kernel scope link src 192.168.253.209 172.16.8.0/24 dev eth2 proto kernel scope link src 172.16.8.3 172.16.0.0/16 via 172.16.8.1 dev eth2 default dev ppp0 scope link это при поднятом впн.
поднимается какого -то сейчас этот роут по команде ifup pptp0 не обращал внимания.. буду искать спс.. попробуем найти что не так.. если что -я еще обращусь..
