[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Косяки с роутингом ppp при подключении как клиент.



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 user1@provider1
и добавив следующие скрипты:
/etc/ppp/ip-up.d/0vpnroute
----------------------------
#!/bin/sh
# Adjust routing
case "$PPP_IPPARAM" in
 user1@provider1)
   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
;;
 user2@provider2)
;;
 *)
 echo "No PPP_IPPARAM defined"
;;
esac
----------------------------------------

/etc/ppp/ip-down.d/0vpnroute
-----------------------------------------
#!/bin/sh
# Adjust routing
case "$PPP_IPPARAM" in
 user1@provider1)
   route del -host $PPP_REMOTE
   route del default dev $PPP_IFACE
;;
 user2@provider2)
;;
 *)
 echo "No PPP_IPPARAM defined"
;;
esac
-----------------------------------------

Теперь каждый провайдер требует не только создания скрипта для подключения но и изменения этих файлов. В общем кривой костыль там где винда отрабатывает без проблем. Покопался в форумах.... от этого косяка плачет большое количество нубов, они просто не понимают
что такое роутинг, как его настраивать и как он вообще работает.


Олег.


Reply to: