Andrey Lyubimets пишет:
Oleg Frolkov пишет:
Eugene Berdnikov пишет:
On Mon, Jan 14, 2008 at 07:21:21PM +0300, Oleg Frolkov wrote:
роутинг на ip адрес предъявленный с той стороны прописывается на
ppp10 ну и defaultroute естественно прописывается туда-же.
Если адрес ppp сервера не из локальной сети - получаем завертывание
gre пакетов в дефолтроут и соответственно неработу ppp интерфейса.
Во-первых, следует поставить маршрут до vpn-сервера ручками.
Не маленький, знаю - но это идеологически неверно в случае когда
адрес получили с помощью dhcp.
наверное, было бы идеологически верно маршрут до впн-сервера получать
по dhcp. А?
Хех... и такое возможно, но я рассматриваю ситуацию с позиции КОНЕЧНОГО
пользователя которому надо
соединяться не только с VPN сервером провайдера, но и в том числе через
установленное соединение с сервером
провайдера инициировать еще одно соединение - но уже со своим VPN
сервером (тем-же корпоративным
сервером организации).
Я понимаю Вашу позицию "со свиным рылом в калашный ряд", но не могу ее
разделить. Если в виндах что-то работает криво
- то я так и скажу криво, если в Линуксе что-то работает криво - это и
надо называть КРИВО а не (не так как в виндах).
Поднимая VPN соединение я рассчитываю что подсистема поднимающая это
соединение позаботится о том - чтобы не
отрубить сук на котором сидит (маршрутизацию до ppp сервера) а сохранить
его и не упасть. Пока-же я наблюдаю самотверженное
отрубание этого самого сука и падение подсистемы если сисадмин не
предусмотрел подпорки в виде явного прописывание маршрута.
Еще более усугубляет положение выдача удаленным vpn сервером в
качестве удаленного адреса
ppp интерфейса того-же адреса на какой и цепляемся vpn (что в
общем-то естественно если у VPN сервера единственный
интерфейс)
Не в этом ничего естественного. Это нелепость.
Возможно что и нелепость, но в принципе не мешает функционированию
системы.
Ага, функционированию не мешает, но положение усугубляет! :-)
Вот в чем вся забава.... винде это не мешает, а Debian (не знаю как там
у других дистров)
встает в известную позу. Ну да ладно.... будем искать изящный выход из
этой позы,
если тут кто-то не подскажет.
так и напиши - хочу как в винде и точка! чего воду лить?
Винда делает все логически верно, так что не стоит передергивать.
Вода льется в надежде на просветление или на то что какому-либо умному
человеку это надоест и он
ткнет носом в нужном направлении.
почему самостоятельно прописать в конфиге маршрут - идеологически
неправильно, но если за тебя это делает ОченьУмнаяПрограмма - то всё
нормально?
Не должен pppd делать больше чем ему предписано в конфиге!
Вот ему не предписано создавать маршрут до ремотного ip адреса
полученного в результате согласования параметров, однако он
зачем-то его прописывает? Хотя по Вашим словам "не должен".
Похоже, что в MS косяки создаются специально, чтобы потом продавать
лекарства от них в виде одной "единственно правильной" платформы,
набитой костылями от искусственно созданных проблем.
+1, и cisco не забудьте
Проблемы создают все, и у любой проблемы есть 2 варианта решения: 1 -
исправить, 2 - сделать костыль.
Чаще всего используется второй вариант, потому как пинать того кто
должен исправить порой бывает
слишком долго, и от этого никуда не денешься ни в мире WINDOWS ни в мире
Linux. Даже если напишешь
патч - его приложат когда совсем припрет а до тех пор будут пользоваться
костылями.
При чем тут косяки MS? В данном случае я хожу с линукса на линукс. А
вот в варианте с MS на линукс
подобных проблем не возникает, потому что там не настолько накосячили
чтобы заворачивать трафик
vpn сервера в туннель.
В общем-то если не получу инфы о том что я не прав и подсказок как
эту проблему решить изящно - придется править
скрипты...... Хотя вообще крайне странно что в stable дистрибутиве
положены скрипты которые ПРИНЦИПИАЛЬНО
какой скрипт конкретно имеется ввиду?
Ну видимо все-таки не скрипты, а ppp обладает неким искусственным не
достаточно интеллектом.
Чтобы прописать роутинг до ip полученного на ремотной стороне у него
интеллекта хватает, а для
того чтобы перед этим прописать роутинг до VPN сервера - ему интеллекта
не хватает.
неправильно поднимают ppp соединение и в большинстве случаев ppp из
коробки неработоспособен без плясок с бубном.
Надеюсь что я не прав.
Олег.
В общем-то в лоб я проблему решил убрав defaultroute и
replacedefaultroute из конфига /etc/ppp/provider/xxx
Добавив туда ipparam [EMAIL PROTECTED]
и добавив следующие скрипты:
/etc/ppp/ip-up.d/0vpnroute
----------------------------
#!/bin/sh
# Adjust routing
case "$PPP_IPPARAM" in
[EMAIL PROTECTED])
GW=`route -n|grep ^0\.0\.0\.0|awk '{print $2}'`
route del $PPP_REMOTE dev $PPP_IFACE
route add -host $PPP_REMOTE gw $GW
route add default dev $PPP_IFACE
;;
[EMAIL PROTECTED])
;;
*)
echo "No PPP_IPPARAM defined"
;;
esac
----------------------------------------
/etc/ppp/ip-down.d/0vpnroute
-----------------------------------------
#!/bin/sh
# Adjust routing
case "$PPP_IPPARAM" in
[EMAIL PROTECTED])
route del -host $PPP_REMOTE
route del default dev $PPP_IFACE
;;
[EMAIL PROTECTED])
;;
*)
echo "No PPP_IPPARAM defined"
;;
esac
-----------------------------------------
Теперь каждый провайдер требует не только создания скрипта для
подключения но и изменения этих файлов. В общем кривой костыль
там где винда отрабатывает без проблем. Покопался в форумах.... от этого
косяка плачет большое количество нубов, они просто не понимают
что такое роутинг, как его настраивать и как он вообще работает.
Олег.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
