Проблема вот в чем.
Мой провайдер всех пускает в сеть через свой VPN-server. У него стоит то что в загловке, точней сказать не могу. У меня на клиенте стоит ASPLinux 9 (kernel-2.4.20-9asp)+ ppp-2.4.2-0.20030420asp+pptp-1.2.0-1asp.
Все настроено, с учетом всевозможных рекомендаций.
Логинится, создается туннель. И он даже почти "работает". Что значит почти. Когда я делаю пинг до внешнего узла, запрос уходит, а ответ не принимается. Хотя у провайдера проверяли, до его сервера ответы на пинги доходили. А у меня tcpdump в это время выкидовал такие вот сообщения:
,,,,,,,,,,,,,
10:10:28.669951 195.162.39.213 > 172.22.22.236: gre [KAv1] ID:0000 A:387 ppp
10:10:29.648282 172.22.22.236 > 195.162.39.213: gre [KSv1] ID:2ce3 S:388 ppp: (DF)
10:10:29.659803 195.162.39.213 > 172.22.22.236: gre [KSAv1] ID:0000 S:213 A:388 ppp:
10:10:29.660892 172.22.22.236 > 195.162.39.213: gre [KSAv1] ID:2ce3 S:389 A:213 ppp: Prot-Rej(176), Rejected-Protocol=2145 (DF)
,,,,,,,,,,,,,
запросы уходят, а ответы откидываются.
Было подозрение на сжатие (mppc), но при установке некоторых модулей для поддержки сжатия (брал здесь http://www.polbox.com/h/hs001/), ничего не изменилось.
Виндовозные клиенты цепляются как родные. А линуховые ни в какую. Пробывал кучу всяких ядер и дистров(RH7.2,RH9.0, 2.4.20 c kernel.org) - не помогает.
Причем такая ботва не только у меня, есть еще как минимум один хрен с такой же проблемой. Самое интересное, что моя конфигурация работает c виндовозным VPN-серверомКто-нидь сталкивался с такой проблемой? Уже 2 месяца бьюсь....
такое впечатление, что не ходит gre, gre пропускаешь на firewall ?
>такое впечатление, что не ходит gre, gre пропускаешь на firewall ?
Между клиентом и сервером находится только хаб (мы в одном сегменте).
На моем клиенте фильтрация пакетов отключена (accept по всем цепочкам без дополнительных правил).
Возможно, у прова стоит такая хрень. Как можно проверить? GRE через какой порт ходит?
>>такое впечатление, что не ходит gre, gre пропускаешь на firewall ?
>Между клиентом и сервером находится только хаб (мы в одном сегменте).
>На моем клиенте фильтрация пакетов отключена (accept по всем цепочкам без дополнительных
>правил).
>Возможно, у прова стоит такая хрень. Как можно проверить? GRE через какой
>порт ходит?сам VPN по протоколу pptp пашет пот порту 1723, а
GRE это не порт, это тип протокола номер 47, если у прова включен firewall, то vpn должен пропускается примерно так:ipchains -A forward -j MASQ -p tcp -s 10.0.0.0/255.0.0.0 -
ipchains -A input -j ACCEPT -p 47 -s 217.196.98.3/255.255.255.0 -d 0.0.0.0/0 -i eth0на iptables где-то так
sbin/iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 1723 -j DNAT --to 192.168.0.5
/sbin/iptables -t nat -A PREROUTING -i eth1 -p 47 -j DNAT --to 192.168.0.5пров должен и output цепочки пропускать от тебя раз он посредник, короче разберетесь
Пообщался с провойдером. Была не верная инфа относительно того что я с ним в одном сегменте. Мы через 3 шлюза с ним соеденены. Но это не существенно (хотя как знать).
Вобщем как мне сказал мой пров, у него все открыто и все проходит. Какие могут быть еще грабли?
Учтите, виндовозные клиенты работают. В чем тогда отличие клиентов?
Попробуй вот что.
Почитай - http://www.degunino.com/support/linux/index.html
Очень полезная штука !
Скачай самый свежий pptp_client с - http://sourceforge.net/projects/pptpclient
Зделай как написанно в доке - все должно работать !
Удачи.
t@rri
>Проблема вот в чем.
>Мой провайдер всех пускает в сеть через свой VPN-server. У него стоит
>то что в загловке, точней сказать не могу. У меня на
>клиенте стоит ASPLinux 9 (kernel-2.4.20-9asp)+ ppp-2.4.2-0.20030420asp+pptp-1.2.0-1asp.
>Все настроено, с учетом всевозможных рекомендаций.
>Логинится, создается туннель. И он даже почти "работает". Что значит почти. Когда
>я делаю пинг до внешнего узла, запрос уходит, а ответ не
>принимается. Хотя у провайдера проверяли, до его сервера ответы на пинги
>доходили. А у меня tcpdump в это время выкидовал такие вот
>сообщения:
>,,,,,,,,,,,,,
>10:10:28.669951 195.162.39.213 > 172.22.22.236: gre [KAv1] ID:0000 A:387 ppp
>10:10:29.648282 172.22.22.236 > 195.162.39.213: gre [KSv1] ID:2ce3 S:388 ppp: (DF)
>10:10:29.659803 195.162.39.213 > 172.22.22.236: gre [KSAv1] ID:0000 S:213 A:388 ppp:
>10:10:29.660892 172.22.22.236 > 195.162.39.213: gre [KSAv1] ID:2ce3 S:389 A:213 ppp: Prot-Rej(176), Rejected-Protocol=2145 (DF)
>,,,,,,,,,,,,,
>запросы уходят, а ответы откидываются.
>Было подозрение на сжатие (mppc), но при установке некоторых модулей для поддержки
>сжатия (брал здесь http://www.polbox.com/h/hs001/), ничего не изменилось.
>Виндовозные клиенты цепляются как родные. А линуховые ни в какую. Пробывал кучу
>всяких ядер и дистров(RH7.2,RH9.0, 2.4.20 c kernel.org) - не помогает.
>Причем такая ботва не только у меня, есть еще как минимум один
>хрен с такой же проблемой. Самое интересное, что моя конфигурация работает
>c виндовозным VPN-сервером
>
>Кто-нидь сталкивался с такой проблемой? Уже 2 месяца бьюсь....Есть два лекарства:
1. если все настроено правильно, тогда попробуй перед тем как запускать ВПН клиент...удалить роут который стоить по умолчанию (route del default).... после чего запускаеш ВПН-клиент и пробуеш пинговать...
2. Если не помог пункт 1 :) тогда у тебя проблкема в настройке самого клиента.. а точнее непрописан правильно ДНС... значит начинаем смотреть и править resolv.conf.pptp и resolv.conf.real. Они находяться в /etcв resolv.conf.pptp:
search
nameserver "IP твоего ДНС сервера"
nameserver ......
если их несколько то прописываеш все!!1в resolv.conf.real:
nameserver "IP твоего ДНС сервера"
nameserver ......
если их несколько то прописываеш все!!1после чего запускаеш ВПН клиент и работаеш!!!
Удачи в нелегком деле:)
Отвечаю сразу всем. Относитетельно настройки ДНС. В данном случае до днс дела не доходит. Я оперирую только IP-адресами.
Относительно того что взять самые свежие версии, как я писал выше, я оттуда уже сдергивал все самое свежее и ставил по их рекомендациям.
Не помогает.
>Отвечаю сразу всем. Относитетельно настройки ДНС. В данном случае до днс дела
>не доходит. Я оперирую только IP-адресами.
>Относительно того что взять самые свежие версии, как я писал выше, я
>оттуда уже сдергивал все самое свежее и ставил по их рекомендациям.
>
>Не помогает.pptp-1.2.0-1asp. - это не самый свежий клиент !
Поставь pptp-linux-1.3.1-1.i386.rpm (http://pptpclient.sourceforge.net/howto-redhat-90.phtml),который для RedHat 9.0 он в ASP тоже должен нормально встать.
Я думаю - если у тебя появляется тунель "ррр0" и пингуется внешние ip, то - авторизация и соединение VPN проходят нормально, значит или pptp-client не поддерживает какой то стандарт или у тебя закрыто что то брендмауэром !
Это все понятно. Но у меня не пингуется внешний ip (тот который на стороне сервера). pptp-client не поддерживает какой-то стандарт - вопрос в том КАКОЙ? Чего требует mpd чего нет в pptp? У меня все открыто! Везде все открыто. Есть несоответствие стандартов. Кто-нидь работал с mpd? Знает его спецификацию, совместимость?
надыбал конфиг mpd своего прова:
default:
load vpn1
load vpn2
.............................
load vpn87
load vpn88
load vpn89
load vpn90
load vpn91vpn1:
new -i ng1 vpn1 vpn1
set iface disable on-demand
set iface idle 0
set iface addrs 192.168.11.221 192.168.11.100
set ipcp ranges 192.168.11.221/32 192.168.11.100/32
set bundle disable multilink
set link yes acfcomp protocomp
set link no pap
set link yes chap
set ipcp dns 195.162.39.221
# If remote machine is NT you need this..
set link enable no-orig-auth
set link keep-alive 10 75
set ipcp yes vjcomp
# If you wanted MPPE encryption and had ng_mppc(8)...
set bundle enable compression
set ccp yes mppc
set ccp yes mpp-e40
set ccp yes mpp-e128
set bundle enable crypt-reqd
set ccp yes mpp-stateless
open
#___________________кто нидь может пояснить некоторые моменты этого конфига. ИНтересны вот эти места:
set link yes acfcomp protocompset link enable no-orig-auth
set link keep-alive 10 75
set ipcp yes vjcompset bundle enable crypt-reqd
set ccp yes mpp-stateless
остальное вроде понятно.
и еще относительно default gw на машинке подключающейся к впн серверу.
Я уже знаю как минимум 3 разных мнения. Может кто-то обстоятельно выскажется по этому поводу.
Вот и карты тебе в руки, тут все написано что тебе надо....
А default gw ненужен тебе точно.....
>Вот и карты тебе в руки, тут все написано что тебе надо....
>
>А default gw ненужен тебе точно.....можно по подробгей про >А default gw ненужен тебе точно.....
а то уже комплекс неполноценности развивается.
Все что мне нужно у меня вроде как есть. Хотя есть вопрос относительно mppc.
Почему в win2000 это все прокатывает, а freeBSD нет.
Такой же глюк
Проявляется только когда на сервере mpd на клиенте linux
Бьюсь 3 месяца, а до этого работало! ДО ОБНОВЛЕНИЯ mpd
По моему дело не в маршрутах
Похоже что - то связанное с заголовками пакетов ip
Пакеты приходят и уходят - проверял по ethereal
Но на стороне клиента не понимается протокол 0x2145
0x21 - это код ip пакета (вроде)
Так вот при сжатии Protocol field compression его там не должно быть - опускается по стандарту, при запрете этого сжатия он должен быть
Когда его нет получаем кучу неизвестных протоколов например 0x45
Когда он есть linux наверное считает что он двухбайтовый
Причём глюк появился после включения mppe
Это по моему.
Как запретить серверу вообще пользоваться однобайтовыми кодами протоколов?
То есть озаглавливать пакет ip 0x0021
Какие будут соображения?
>Такой же глюк
>Проявляется только когда на сервере mpd на клиенте linux
>Бьюсь 3 месяца, а до этого работало! ДО ОБНОВЛЕНИЯ mpd
У меня почти тоже но еще хуже, клиент линукс, сервер freebsd с mpd. Канал поднимается, потом в него отправляется за секунду какието непонятные 60 мегабаит траффика(если скорость в сети всего 1-2 метра) и на это канал вырубается..
Тоже самое... какой mpd на сервере? У моего провайдера 3.13
Я ещё нашёл в Омске таких же как мы:http://linuxportal.ru/forums/index.php/m/0/13406/20/
Компилил ядро и модули и pppd с поддержкой MPPC
РЕЗУЛЬТАТ ТАКОЙ ЖЕ - не в mppc дело не в mppc ... :(Сдесь брал... http://www.polbox.com/h/hs001/
Узнал здесь: http://pptpclient.sourceforge.net/howto-diagnosis.phtml#mppc
>Компилил ядро и модули и pppd с поддержкой MPPC
>РЕЗУЛЬТАТ ТАКОЙ ЖЕ - не в mppc дело не в mppc ...
>:(
>
>Сдесь брал... http://www.polbox.com/h/hs001/
>
>Узнал здесь: http://pptpclient.sourceforge.net/howto-diagnosis.phtml#mppcУ меня были похожие проблемы.
Тоесть туннель поднимался, но ничего через этот туннель не ходило.
Виндовый сервак отвечал мессагами "Prot-Rej"
Так вот я просто апгрейданул свои линуха с RH 9.0
на Linux Enterprise Server 3.0 (в нем ядро 2.4.21-4.EL) а затем перекомпилил kernelmod как собственно советовалось на sourceforge.net