vpn-client

Проверь по "ifconfig ppp0" что 192.168.100.1 - это его Point-to-Point адрес - то есть адрес удалённого хоста к которому ты создал туннель VPN.
Если это так - то добавь defaultroute опцию в конфиги соединения /etc/ppp/options или что-то такое.
Вручную надо добавлять не так
route del 192.168.100.1
route add default gw 10.10.0.12

А так
route add default gw 192.168.100.1

Надеюсь что помог

Нет, так, route add default gw 192.168.100.1 не подходит, не работает. Ещё раз опишу проблему, так как первый раз я допустил ошибку:
Конектюсь к прову с помощью pptp-client. Мне в route автоматически прописывается такой путь:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.100.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0

Где 192.168.100.1 это ip-адрес vpn-сервера... При этом проц грузится 100 процентов, и сетевой интерфейс полностью загружен, что то передаёт, не понятно что. Интернет не работает, пока не сделаешь в ручную:
route del 192.168.100.1
route add default gw 10.10.0.12
Где 10.10.0.12 ip-адрес моего ppp интерфейса, выданный мне vpn-сервером...
Но это не всегда срабатывает почему-то.
Как лечить.
Дистрибутив rh9. pptp-client последней версии скачан.

нужно именно так чтоб работало. Если сделать как вы сказали, то все пакеты которые в инет будут посылаться на 192.168.100.1, но шлюз эти пакеты не маршрутизирует, он ждёт пакеты для маршрутизации именно с 10.10.0.12, так как когда я конектюсь в vpn серверу, он мне даёт именно этот ip.

Оставим на время замечание про загрузку процессора и стевой карточки. Разберёмся с вопросами раутинга и маскардинга. Для начала - подключаемая машина работает обосоленно или за ней скрыт локальный сегмент? Вначале я думал - роутер локалки в интернет, но похоже - ошибался. Не могли бы Вы указать вывод команд route -n и ifconfig до и после подключения? А то какой-то безпредметный разговор...
Ну и насчёт бешенного траффика и загрузки процессора. netstat -p выдаст список всех программ обрабатывающих уже установленные соединения, а netstat -pl - список всех готовых принять. top Вам поможет. У него есть интерактивная команда A - сортировка по возрасту.

Вот так до подключения:

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

Вот так после подключения, при этом инет не работает:

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.100.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

А работает только в том случае, если сделаешь вот так, и то не всегда работаеш, зависит от того как быстро после подключения сделаешь:
route del 192.168.100.1
route add default gw 10.10.0.12
После изменения правил, инет работает, таблица маршрутов выглядит вот так:

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 10.10.0.12 0.0.0.0 UG 0 0 0 ppp0

Где,
192.168.100.1 - ip-адрес vpn-сервера;
10.10.0.12 - ip-адрес моего ppp0, этот ip выдаёт vpn-сервер и он каждый раз разный, но всегда начинается на 10.10.0.

Ja prosil ificonfig do i posle podkluchenija...
kakoj /etc/ppp/options?

defaultroute v ppp/options

до подключения:

eth0 Link encap:Ethernet HWaddr 00:02:B3:2E:28:AA
inet addr:192.168.100.20 Bcast:192.168.100.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:98180 errors:0 dropped:0 overruns:0 frame:0
TX packets:14470 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:7316049 (6.9 Mb) TX bytes:1144980 (1.0 Mb)
Interrupt:11 Base address:0xa800 Memory:db800000-db800038

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2084 errors:0 dropped:0 overruns:0 frame:0
TX packets:2084 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:142782 (139.4 Kb) TX bytes:142782 (139.4 Kb)

После подключения:

eth0 Link encap:Ethernet HWaddr 00:02:B3:2E:28:AA
inet addr:192.168.100.20 Bcast:192.168.100.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:99654 errors:0 dropped:0 overruns:0 frame:0
TX packets:14566 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:7422868 (7.0 Mb) TX bytes:1157491 (1.1 Mb)
Interrupt:11 Base address:0xa800 Memory:db800000-db800038

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2088 errors:0 dropped:0 overruns:0 frame:0
TX packets:2088 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:142990 (139.6 Kb) TX bytes:142990 (139.6 Kb)

ppp0 Link encap:Point-to-Point Protocol
inet addr:10.10.0.15 P-t-P:192.168.100.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1486 Metric:1
RX packets:11 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:752 (752.0 b) TX bytes:297 (297.0 b)

В defaultroute в /etc/ppp/optoins.pptp и /etc/ppp/options не прописаны, прописаны только ms-dns два штуки в /etc/ppp/options.pptp, это файл и является настройкой pptp.

ADSL or Cable?
На какой IP идёт соединение "звонилки"?
если юто тот же 192.168.100.1 - то так в жизни не заработает.
На другой стороне должен быть один IP на который pptp будет пытаться подключиться и один для туннеля - никогда не один и тот же.
Если запуск "звонилки" происходит как-то так
pptp <ISP_IP> user <username> remotename <ISP>
то я бы перед её запуском добавил
route add -host <ISP_IP> dev eth0
а затем запустил звонилку так
pptp <ISP_IP> user <username> remotename <ISP> defaultroute mtu 1452 mru 1452 noauth
И всё.
Надеюсь что помог

ADSL or Cable?
На какой IP идёт соединение "звонилки"?
если это тот же 192.168.100.1 - то так в жизни не заработает.
На другой стороне должен быть один IP на который pptp будет пытаться подключиться и один для туннеля - никогда не один и тот же.
Если запуск "звонилки" происходит как-то так
pptp <ISP_IP> user <username> remotename <ISP>
то я бы перед её запуском добавил
route add -host <ISP_IP> dev eth0
а затем запустил звонилку так
pptp <ISP_IP> user <username> remotename <ISP> defaultroute mtu 1452 mru 1452 noauth
И всё.
Надеюсь что помог

Вообще соединяюсь через локальную сеть, и vpn сервер и мой комп в одной локальной сети.

Тогда как я и сказал
---------------------8<----------------------------------
route add -host <то что введено ниже строчкой как IP или имя сервера VPN> dev eth0
pptp <всё как было> defaultroute mtu 1452 mru 1452 noauth
---------------------8<----------------------------------
должно помочь по идее...

Надеюсь что помог

Хотя смысл создания туннеля в локальной сети...

Нет, не работает, видно не сделать, а тунель в локальной сети нужен для авторизации доступа в инет и подсчёта трафика, и для того чтоб пароли не снифирили к поп3 фтп, и т.д.
Оказывается для работы не обязательно прописывать
route add default gw 10.10.0.12
Достаточно написать в options.pptp опцию defaultroute, тогда автоматически прописывается в route -n такой путь:
0.0.0.0 192.168.100.1 0.0.0.0 UG 0 0 0 ppp0

И для того, чтобы был инет, нужно чтобы в начале не было пути, который тоже автоматически прописывается:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0

Если его удачно удалить, то инет появится...

А конектюсь я через #pptp-command, по другому не умею.

Большое спасибо тебе за уделённое мне время...

>А конектюсь я через #pptp-command, по другому не умею.
man pptp - и всего делов...


>Достаточно написать в options.pptp опцию defaultroute
;-)

> для того, чтобы был инет, нужно чтобы в начале не было пути
route del <IP>


>0.0.0.0 192.168.100.1 0.0.0.0 UG 0 0 0 ppp0
Это результат "route add default gw 192.168.100.1" который твоя звонилка сама прописывает из-за опции "defaultroute" - как я с смого начала и советовал.
А теперь найди 3 отличия:

>192.168.100.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
> при этом интернет не работает.

первое поле переводится как назначение -т.е "конечный адресат"
второе поле - как шлюз. Т.е. "через что посылать"
Первое правило (корректное) говорит: "пеересылать всё остальное через 192.168.100.1 на ppp0".
Второе (некорректное) говорит: "пересылать всё что идёт на 192.168.100.1 через любой доступный маршрут на ppp0"
Разницу улавливаешь?

Удач в дальнейших нелёгких начинаниях.

Вопрос: Почему pptp-command прописывает этот путь, неправельный:
192.168.100.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
Как сделать чтоб он этого не писал????
То же самое прописывает команда:
service pptp start
Зачем мне автоматом этот дурной путь pptp пишет???

Ещё раз спасибо...

И фигня в том, что не всегда, когда удаляешь этот путь который неправельно автоматом прописывается, инет появляется.

failes:
/etc/init.d/pptp
/etc/ppp/options.pptp

man pptp

Ja ser'ozno - posmotrite tuda i vse stranet jasno.

Ja by ubil nafig /etc/init.d/pptp,
i v rc.local dobavil by skript dlja zapuska vsego.
Udach

Блин, но это уже никуда не годится, я думал, что этот дурной путь, скрипт запуска прописывает, ан нет. Делаю так:
#pppd noauth nodeflate name andrey remotename PPTP pty "pptp 192.168.100.1 --nolaunchpppd"
И этот путь:
192.168.100.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
опять написан, и нужно его удалить, чтоб инет работал.
Кстати, одно дополнение: оказывается всегда после удаления этого пути инет начинает работать, по-крайней мере web. Почему раньше заблуждался в этом, а я для проверки работает или нет интернет проверял командой ping mail.ru, и днс очень часто при удалении этого пути, не резолвит, а пинги по ip оказывается всегда проходят.

Пробуем так
# route del 192.168.100.1
# route add 192.168.100.1 dev eth0
#pppd noauth nodeflate defaulroute name andrey remotename PPTP pty "pptp 192.168.100.1 --nolaunchpppd"
и наслаждаемся. Надеюсь

Или так
# route del 192.168.100.1
# route add 192.168.100.1 gw192.168.100.20 dev eth0
# pppd noauth nodeflate defaulroute name andrey remotename PPTP pty "pptp 192.168.100.1 --nolaunchpppd"
Если работает - оформляем как скрипт

А почему собсно --nolaunchpppd?

1. Без --nolaunchpppd почему то интерфейс ppp не поднимается.
2. Вначале я не могу удалить путь
route del 192.168.100.1,
так как до дозвона его нет. А вот этот путь зачем нужен:
route add 192.168.100.1 gw 192.168.100.20 dev eth0,
без него работает, но работает почему то через раз, всё соединяется, но инет не работает, работать начинает с третьей - шестой попытки.
3. Может это что нить подскажет, если я делаю так:
pppd noauth nodeflate defaultroute name andrey remotename PPTP pty "pptp 192.168.100.1 --nolaunchpppd" 10.10.0.12:192.168.100.20,
где 10.10.0.12 мне выдается vpn-сервером, его надо угадать, а 192.168.100.20 мой локальный адрес, вместо дурного пути:
192.168.100.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0,
мне уже прописывается:
192.168.100.20 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0,
но это соединение долго не держится.
4. Как в команде pppd задать чтоб опции брались из файла /etc/ppp/options.pptp

3. Не понял. Можно ли ещё раз и поподробнее? Или это просто строка скомандой прервана посередине в Вашем посте? Должно быть так
pppd noauth nodeflate defaultroute name andrey remotename PPTP pty "pptp 192.168.100.1 --nolaunchpppd" 10.10.0.12:192.168.100.20

Выловить (а не угадать IP) можно так
tail -n 100 /var/log/messages|grep "remote IP"
если добавлена опция debug для pppd.
Но вообще-то в этом мало смысла - указывать файл опций когда половина уже передана в командной стоке - noauth nodeflate defaultroute.......
Тогда уж всё это надо перенести в тот файл.

4.
file /etc/ppp/options.pptp

from <man pppd>
--------------------------------------------------------------
file name
Read options from file name (the format is described below). The file
must be readable by the user who has invoked pppd.
--------------------------------------------------------------

pppd noauth nodeflate defaultroute name andrey remotename PPTP pty "pptp 192.168.100.1 --nolaunchpppd" 10.10.0.12:192.168.100.20
Вот именно такая команда...

Победить автоматическое добовление пути я так и не смог, но вот кое что другое выяснил:
Оказывается:
Если я конектюсь к vpn-серверу вот так:
pppd noauth nodeflate defaultroute name andrey remotename PPTP pty "pptp 192.168.0.1 --nolaunchpppd",
в логах сервера vpn пишется такое:
Sep 8 01:11:04 gateway pptpd[23165]: CTRL: Client 192.168.100.20 control connection started
Sep 8 01:11:05 gateway pptpd[23165]: CTRL: Starting call (launching pppd, opening GRE)
Sep 8 01:11:05 gateway pppd[23166]: pppd 2.4.1 started by root, uid 0
Sep 8 01:11:05 gateway pppd[23166]: Using interface ppp2
Sep 8 01:11:05 gateway pppd[23166]: Connect: ppp2 <--> /dev/pts/2
Sep 8 01:11:05 gateway pppd[23166]: MSCHAP-v2 peer authentication succeeded for andrey
Sep 8 01:11:05 gateway pppd[23166]: local IP address 192.168.100.1
Sep 8 01:11:05 gateway pppd[23166]: remote IP address 10.10.0.13
Sep 8 01:11:05 gateway pppd[23166]: BSD-Compress (15) compression enabled <<< обрати внимания на эту строчку, для того, чтоб было понятно дальше
Sep 8 01:11:05 gateway /etc/hotplug/net.agent: assuming ppp2 is already up
Sep 8 01:11:24 gateway pptpd[23165]: GRE: Discarding out of order packet <<< эта строка появляется когда я делаю route del 192.168.100.1
То инет всегда начинает работать после удаления того дурного пути, который добовляется автоматически, то есть инет начинает работать тогда, когда поступит команда route del 192.168.100.1

Если же я конектюсь так:
pppd noauth nodeflate defaultroute require-mppe-128 name andrey remotename PPTP pty "pptp 192.168.0.1 --nolaunchpppd"
(здесь добавленно шифрование трафика по mppe-128, это админ требует обязательно, сервак сделан так, что без этого шифрования связь не установится, но временно админ убрал это условие), то в логах сервера пишется такое:
Sep 8 01:24:07 gateway pptpd[23457]: CTRL: Client 192.168.100.20 control connection started
Sep 8 01:24:08 gateway pptpd[23457]: CTRL: Starting call (launching pppd, opening GRE)
Sep 8 01:24:08 gateway pppd[23458]: pppd 2.4.1 started by root, uid 0
Sep 8 01:24:08 gateway pppd[23458]: Using interface ppp2
Sep 8 01:24:08 gateway pppd[23458]: Connect: ppp2 <--> /dev/pts/2
Sep 8 01:24:09 gateway pppd[23458]: MSCHAP-v2 peer authentication succeeded for andrey
Sep 8 01:24:09 gateway /etc/hotplug/net.agent: assuming ppp2 is already up
Sep 8 01:24:09 gateway pppd[23458]: MPPE 128 bit, stateless compression enabled <<< вот этой строкой отличается от предыдущего лога, то есть включено mppe шифрование
Sep 8 01:24:15 gateway pppd[23458]: local IP address 192.168.100.1
Sep 8 01:24:15 gateway pppd[23458]: remote IP address 10.10.0.11

После удаления неправильного пути командой route del 192.168.100.1 строчка как в предыдущем логе не появляется и инет не всегда работает.

Итог:
В первом случае, удалить путь командой route del 192.168.100.1 можно в любое время и после удаления этого пути, инет заработает, во втором же случае работа интернета зависит от того, как быстро ты удалишь этот неправильный путь после поднятия интерфейса, чем быстрее тем более вероятно, что инет будет работать. Первый случай для меня не пригоден, так как админ говорит о безопастности и что из-за меня одного он не будет убирать требование шифрования по протоколу mppe-128.

the end

s MPPE nikogda ne stalkivalsja - nichego skazat' ne mogu. K sozhaleniju.

если проблема только "успеть" удалить путь, то я бы попробовал - не мудрствуя - такой скриптик:

-------------------------------------------------------------
#/bin/bash
pppd noauth nodeflate defaultroute require-mppe-128 name \
andrey remotename PPTP pty "pptp 192.168.0.1 --nolaunchpppd"
sleep 1
route del 192.168.100.1
-------------------------------------------------------------

Думаю секунда - достаточно чтоб установить соединение.
Обратите внимание - сивмол '\' добавлен чтобы скрыть перевод строки.
Можно в принципе и без него - одной строчкой.

Надеюсь что помог.

Секунда это много.. %-))) Проверку надо делать в цикле с периодом 200 мс, наверное. И то, когда проц загружен чем нить процентов на 70, когда что-то происходит или компилится что-нить, то никакая скорость не оможет получить инет, так как видно при сильной загрузке проца, команда удаления пути не сразу отрабатывает. Приду домой и попробую сделать в цикле без прерывания чтобы путь пытался удалиться раз так 100, надеюсь поможет.

За всё ОГРОМНОЕ СПАСИБО...

Настоятельно советую почитать:
http://www.earendil.ath.cx/content/linux_cable_pptp_il.html#pptp_and_l2tp

Вот посмотрел, там в конце написано, что должно получиться, вот у меня это и получается:
eth0 Link encap:Ethernet HWaddr 01:23:45:67:89:AB
inet addr:XXX.XXX.XXX.XXX Bcast:255.255.255.255 Mask:255.255.254.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2652841 errors:0 dropped:0 overruns:0 frame:0
TX packets:1881230 errors:0 dropped:0 overruns:0 carrier:0
collisions:4428 txqueuelen:100
RX bytes:803214813 (766.0 MiB) TX bytes:823849284 (785.6 MiB)
Interrupt:12 Base address:0xcc00

ppp0 Link encap:Point-to-Point Protocol
inet addr:YYY.YYY.YYY.YYY P-t-P:ZZZ.ZZZ.ZZZ.ZZZ Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1460 Metric:1
RX packets:30358 errors:0 dropped:0 overruns:0 frame:0
TX packets:45650 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:2602961 (2.4 MiB) TX bytes:49443114 (47.1 MiB)

Now use /sbin/route to check the routing table. Typical output:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
ZZZ.ZZZ.ZZZ.ZZZ * 255.255.255.255 UH 0 0 0 ppp0
pns.inter.net.il WWW.WWW.WWW.WWW 255.255.255.255 UGH 0 0 0 eth0
QQQ.QQQ.QQQ.QQQ * 255.255.254.0 U 0 0 0 eth0
default YYY.YYY.YYY.YYY 0.0.0.0 UG 0 0 0 ppp0


У меня тоже самое, но не работает, отличие только в том, что у меня не ADSL, и соответственно маска eth0 не 255.255.255.255, а 255.255.255.0 и для меня путь ZZZ.ZZZ.ZZZ.ZZZ * 255.255.255.255 UH 0 0 0 ppp0, это путь из-за которого не работает. Заметь, этот путь в скрипте запуска они не добовляют, он автоматически прописывается. Вот в этом моя беда.

>Заметь, этот путь в скрипте запуска они не добовляют, он
>автоматически прописывается. Вот в этом моя беда
NOT correct! They do change routing table in dialer script!
see there "The main connection script" to understand how to do so.

>Заметь, этот путь в скрипте запуска они не добовляют, он
>автоматически прописывается. Вот в этом моя беда
Ага. Автоматически. Благодаря их скрипту. Читать внимательнее раздел
"The main connection script"