Re: Косяки с роутинго м ppp при подключении к ак клиент.
chindi пишет: On Tue, 15 Jan 2008 20:14:28 +0300 Oleg Frolkov [EMAIL PROTECTED] wrote: А если подумать, то станет ясно, что идиот здесь админ vpn-сервера, выдавший такой адрес серверной стороне туннеля. И то, что винда содержит костыль-предохранитель от короткого замыкания -- это не аргумент за то, что такая конфигурация правильна. Хорошо. я идиот. Какая конфигурация правильна? Выдать совершенно левый ip? Например, у нас пользователям по PPTP выдаются адреса из сети 10.1.0.0/16, и адрес серверной стороны туннеля соотв. 10.1.0.1. А теперь контрольный вопрос: Какой IP у самого VPN сервера? Олег. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Косяки с роутинго м ppp при подключении к ак клиент.
Oleg Frolkov пишет: Не маленький, знаю - но это идеологически неверно в случае когда адрес получили с помощью dhcp. наверное, было бы идеологически верно маршрут до впн-сервера получать по dhcp. А? Хех... и такое возможно, но я рассматриваю ситуацию с позиции КОНЕЧНОГО пользователя которому надо почему тогда провайдер не может позаботиться о своих клиентах - конечных пользователях? соединяться не только с VPN сервером провайдера, но и в том числе через установленное соединение с сервером провайдера инициировать еще одно соединение - но уже со своим VPN сервером (тем-же корпоративным сервером организации). в первоначальном письме про это не было так и напиши - хочу как в винде и точка! чего воду лить? Винда делает все логически верно, так что не стоит передергивать. Вода льется в надежде на просветление или на то что какому-либо умному человеку это надоест и он ткнет носом в нужном направлении. Вода воде рознь.Иногда она камень точит, иногда - просто кто-то слюной брызжет. Похоже, что в MS косяки создаются специально, чтобы потом продавать лекарства от них в виде одной единственно правильной платформы, набитой костылями от искусственно созданных проблем. +1, и cisco не забудьте Проблемы создают все, ;-) - отучайтесь говорить за всех и у любой проблемы есть 2 варианта решения: 1 - исправить, 2 - сделать костыль. Чаще всего используется второй вариант, потому как пинать того какой скрипт конкретно имеется ввиду? Ну видимо все-таки не скрипты, а ppp обладает неким искусственным не достаточно интеллектом. Чтобы прописать роутинг до ip полученного на ремотной стороне у него интеллекта хватает, а для того чтобы перед этим прописать роутинг до VPN сервера - ему интеллекта не хватает. К сведению: ppp протокол канального уровня, ip - протокол сетевого уровня, маршрутизация относится к сетевому. -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Косяки с роутинго м ppp при подключении к ак клиент.
Max Dmitrichenko пишет: On Wednesday 16 January 2008 13:37, Andrey Lyubimets wrote: Ну видимо все-таки не скрипты, а ppp обладает неким искусственным не достаточно интеллектом. Чтобы прописать роутинг до ip полученного на ремотной стороне у него интеллекта хватает, а для того чтобы перед этим прописать роутинг до VPN сервера - ему интеллекта не хватает. К сведению: ppp протокол канального уровня, ip - протокол сетевого уровня, маршрутизация относится к сетевому. Не совсем корректное утверждение. PPP - это вообще семейство протоколов. В чём не корректно? хорошо, ррр - семейство протоколов канального уровня Среди них есть IPCP, который согласует параметры IP, без него IP работать не будет, так что некоторая привязка к IP есть. Это не противоречит тому что я написал. -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [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
Re: Косяки с роутинго м ppp при подключении к ак клиент.
Eugene Berdnikov пишет: [axed] наверное, было бы идеологически верно маршрут до впн-сервера получать по dhcp. А? +1 dhcp у кого? У провайдера а VPN мне нужен не только провайдерский но и мой корпоративный. Предположим я могу с ноута выйти в инет с десятка локаций (в том числе и через wifi) я не должен решать - есть стандартные механизмы и они должны отрабатывать данную ситуацию, но они этого не делают. 2 Frolkov: Зарубите себе на носу: Вам никто ничего не должен. Даже если Вы выдумаете себе сказочный мир, в котором якобы есть какие-то замечательные механизмы выправления маршрутизации, они от этого не возникнут, пока их кто-то придумает не в мечтах, а в реальности, и запрограммирует. Вы решили поставить меня на место? Любая программа с обозначенным функционалом - должна этот функционал выполнять. Программа ДОЛЖНА работать, а если она не работает значит она ГЛЮКАВА и точка. Мне никто ничего не должен, но надо просто признать что ЕСТЬ ГЛЮКИ а не вправлять мне мозги на тему никто не должен. Не надо с обсуждения проблемы переходить на обсуждение людей, я Вас не собираюсь заставлять что-то для меня программировать. Возможно что и нелепость, но в принципе не мешает функционированию системы. Думаю, дальнейший спор не имеет смысла. Если не хотите думать -- поставьте винду и не парьтесь. Не забудьте заплатить за неё, ведь винда якобы решает все проблемы, во всяком случае, создаёт красивую иллюзию этого. Действительно... вот это Ваше письмо не имеет совершенно ни какого смысла, как говорится одна голова хорошо а две лучше - потому я и задаю тут вопросы на тему как лучше сделать и где я не прав. Если-бы Вы внимательнее читали мои письма то увидели что решение частного случая я нашел и без Ваших ядовитых замечаний - меня больше интересовало действительно-ли это проблема или я что-то не так делаю. Советы купить винду приберегите для других людей, а лучше вообще для себя. Люди на этом форуме делятся на тех кто помогает (кинув порой одну строчку по которой можно выгуглить решение) и тех кто крутой перец и все остальные у него годны только для того чтобы поставить винду и не париться. Мне кажется стремиться во вторую категорию не стоит, лучше хотя-бы промолчать если нечего подсказать по теме. Прошу прощения у всех остальных читателей рассылки за флейм, но просто не могу не ответить когда начинаются нападки типа Вам никто ничего не должен и поставьте винду и не парьтесь, мне кажется рассылка создана не для наездов. Олег. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Косяки с роутинго м ppp при подключении к ак клиент.
Eugene Berdnikov wrote: полученного в результате согласования параметров, однако он зачем-то его прописывает? Хотя по Вашим словам не должен. В результате работы pppd появляется явный маршрут до remoteip, и перебивает маршрут на vpn-сервер, а Вы устраиваете из-за этого типично чайницкий свист. Вместо того, чтобы подумать головой. Совершенно верно. Вообще, проблема решается при помощи iproute2. Я имел такую экспу при подключении к корбине. А если подумать, то станет ясно, что идиот здесь админ vpn-сервера, выдавший такой адрес серверной стороне туннеля. И то, что винда содержит костыль-предохранитель от короткого замыкания -- это не аргумент за то, что такая конфигурация правильна. Однозначно. Подход в винде работает - и ладно, при котором кладется большой болт на все возможные стандарты - изрядно достал. В частности, винда позволяет вольно обращаться с маской сети при раздаче адресов по dhcp - сама догадывается прописать роутинг через интерфейс на шлюз, если шлюз не попадает в текущую маску сети. В результате такие прямые сетки встречаются - мама дорогая... -- Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Косяки с роутинго м ppp при подключении к ак клиент.
Max Dmitrichenko пишет: Хех... и такое возможно, но я рассматриваю ситуацию с позиции КОНЕЧНОГО пользователя которому надо соединяться не только с VPN сервером провайдера, но и в том числе через установленное соединение с сервером провайдера инициировать еще одно соединение - но уже со своим VPN сервером (тем-же корпоративным сервером организации). Честно говоря, только сейчас я стал понимать в чем у тебя проблема. До этого несколько раз почитал и не понял, чего тебе надо и что у тебя не работает. Сейчас правда тоже не уверен, что до конца понимаю. Да нет у меня проблем :) - у меня только неудобство связанное с использованием pptp, который не достаточно умен чтобы отрабатывать достаточно стандартную ситуацию. У меня все работает, прикладыванием скриптов исправляющих врожденные косяки pppd - однако разговор о другом, о том что косяки в серверных сервисах это одно, их решают квалифицированные люди - а вот косяки в пользовательских сервисах это задница.. если проблема у меня я ее решу, а вот когда проблема у нуба с той стороны экрана или на том конце провода - это уже более серьезная ситуация и надо знать самое простое решение. В общем-то из этого треда и гугления я понял что проблему могут пофиксить только писатели дистрибов (написав соответствующие скрипты и приложив в дистриб) или писатели pppd. Поднимая VPN соединение я рассчитываю что подсистема поднимающая это соединение позаботится о том - чтобы не отрубить сук на котором сидит (маршрутизацию до ppp сервера) а сохранить его и не упасть. Пока-же я наблюдаю самотверженное отрубание этого самого сука и падение подсистемы если сисадмин не предусмотрел подпорки в виде явного прописывание маршрута. Я думаю, что даже винда, не обладает таким интелектом, просто ты как-то не так сконфигурил ppp и у тебя от этого все беды. Как говорили выше, проблемы ppp суть проблемы кривых рук. Как раз винда-то и обладает, и если в любой винде сказать #route print - то можно увидеть что она активно пользуется метриками, а если поднимаешь VPN соединение она увеличивает на 1 метрику у дефолтного маршрута а метрику нового маршрута выставляет=1. Вдобавок винда создает прямой маршрут с маской /32 до VPN сервера с которым начинает соединение. В принципе любое другое поведение не имеет смысла. Если мы не хотим обрубить сук на котором сидим то первым делом надо выяснить адрес шлюза и прописать на него прямой роутинг до того VPN сервера с которым СЕЙЧАС_НАЧНЕМ соединяться. Вода льется в надежде на просветление или на то что какому-либо умному человеку это надоест и он ткнет носом в нужном направлении. Нарисуй пожалуйста схему стенда со связями и адресами. А то лично я ничего не понимаю в топологии твоих туннелей с твоих слов. Поэтому ткнуть носом точно не могу. Да что понимать? В исходном сообщении есть стартовые условия. Получили адрес по DHCP (не суть важно откуда, смысл в том что сеть настроена автоматически и крайне не хотелось-бы ручного вмешательства). т.е. в предельно упрощенном варианте имеем маршрут для своей сети смотрящий в интерфейс и дефолтный маршрут смотрящий на шлюз. Далее предположим: Поднимаем VPN соединение с опцией defaultroute Получаем: после поднятия интерфейса создается прямой маршрут на адрес представленный с той стороны и заворачивается в ppp, в случае если предъявленный адрес = адресу с которым соединялись получаем роутинг пакетов для ppp сервера в туннель. с defaultroute тоже косяк он просто не создается в принципе, потому что есть уже маршрут по умолчанию, хотя собственно никто не мешает pppd завести второй маршрут по умолчанию. Я в этом свете вообще не понимаю зачем нужна директива defaultroute если она не добавляет маршрута если есть уже маршрут по умолчанию. В идеале клиент dhcp должен после получения ip адреса выставлять ненулевую метрику, чтобы дать возможность изменить маршрут не удаляя его запись, однако факт остается фактом - метрика = 0 со всеми вытекающими. Можно конечно поднимать с опциями defaultroute replacedefaultroute - но тогда теряем старый роутинг по умолчанию и не можем его достать из скрипта в /etc/ppp/ip-up.d В общем-то как я писал выше - запретил я pppd менять маршруты и делаю это сам. Хотя конечно маршрут для ip выданного на том конце ppp все-таки он вкрячивает - приходится его удалять. В принципе для таких случаев в pppd должна быть проверка типа if remote_ipvpn_ip route add но видимо этого нет, ну да ладно. почему самостоятельно прописать в конфиге маршрут - идеологически неправильно, но если за тебя это делает ОченьУмнаяПрограмма - то всё нормально? Не должен pppd делать больше чем ему предписано в конфиге! Вот ему не предписано создавать маршрут до ремотного ip адреса полученного в результате согласования параметров, однако он зачем-то его прописывает? Хотя по Вашим словам не должен. Дело в том, что задача не прописывать такой маршрут лишена всякого смысла, на кой тогда вообще соединение нужно? Это частный случай -
Re: Косяки с роутинго м ppp при подключении к ак клиент.
Eugene Berdnikov пишет: On Tue, Jan 15, 2008 at 05:39:42PM +0300, Oleg Frolkov wrote: Andrey Lyubimets пишет: почему самостоятельно прописать в конфиге маршрут - идеологически неправильно, но если за тебя это делает ОченьУмнаяПрограмма - то всё нормально? Не должен pppd делать больше чем ему предписано в конфиге! Вот ему не предписано создавать маршрут до ремотного ip адреса Это не регулируется конфигом pppd. Pppd лишь конфигурит интерфейс, а маршрут при этом создаёт ядро. О! Вот за эту инфу спасибо, я как-то упустил из вида подобный ньюанс надо будет на досуге обкурить. хотя конечно никто не мешает pptp перед соединением создать маршрут до vpn сервера, это решило-бы проблему. полученного в результате согласования параметров, однако он зачем-то его прописывает? Хотя по Вашим словам не должен. В результате работы pppd появляется явный маршрут до remoteip, и перебивает маршрут на vpn-сервер, а Вы устраиваете из-за этого типично чайницкий свист. Вместо того, чтобы подумать головой. Да ладно... это не единственная проблема :) Есть еще косячекс если не прописать маршрут до VPN сревера, то даже если удаленная сторона предъявит другой ip - маршрут по умолчанию перебьет старый маршрут и опять - опаньки, так что без костылей все равно не обойтись до тех пор пока не поправят pppd/pptp. А если подумать, то станет ясно, что идиот здесь админ vpn-сервера, выдавший такой адрес серверной стороне туннеля. И то, что винда содержит костыль-предохранитель от короткого замыкания -- это не аргумент за то, что такая конфигурация правильна. Хорошо. я идиот. Какая конфигурация правильна? Выдать совершенно левый ip? Или выделить пул реальных IP и раздавать vpn серверам для фиктивных интерфейсов? Моим аргументом является то что выделенный мною белый ip не может пересечься ни с чьей внутренней сетью, если-же я буду выдавать что-то типа 10.0.0.1 то теоретически в какой-то конфигурации я из чужой сети с роутером имеющим тот-же адрес не смогу соединиться со своим VPN сервером. Любой придуманный экзотический ip из серой сети может применяться где-то еще, хотя конечно вероятность стремится к нулю, а лишних реальныех ip всегда не хватает, потому и пользую тот единственный который есть у VPN сервера. Олег. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Косяки с роутинго м ppp при подключении к ак клиент.
Eugene Berdnikov пишет: On Tue, Jan 15, 2008 at 06:04:20PM +0300, Oleg Frolkov wrote: Pppd РАБОТАЕТ, и делает то, что ему сказано. Точка. А то, что результат Вам не нравится -- это другой вопрос. Да, если ему дать костыли - он работает, я не спорю. Мне никто ничего не должен, но надо просто признать что ЕСТЬ ГЛЮКИ а не вправлять мне мозги на тему никто не должен. Надо научиться отличать глюки в СВОЕЙ голове от глюков софта и тараканов в голове софтописателей. Вы пока что никаких содержательных аргументов против линуксовых алгоритмов не привели. У винды проблем нет -- это не аргумент. Алгоритм - заменить defaultroute не прописав при этом шлюз до VPN сервера Вы считаете правильным? В общем-то работающий алгоритм достаточно прост: взяли defaultroute, зароутили на него VPN сервер, соединились с VPN сервером, поменяли defaultroute и так можно сколь угодно большую вложенность создать. одна голова хорошо а две лучше - потому я и задаю тут вопросы на тему как лучше сделать и где я не прав. Так Вам написали, как лучше сделать. И если бы не Ваше упорное желание считать, что линукс работает неправильно, потому что у него из коробки не взлетает, то никакого флейма и не было бы. Вы неправы в том, что не задумываетесь, как в классической модели маршрутизации ядро должно выбрать маршрут на remoteip, который один и тот же для vpn-сервера и серверного конца туннеля. Задумайтесь. Проблема именно здесь. А затем задумайтесь над тем, какого хрена винда этой модели не следует, и как с этим жить, если предугадать её недокументированное поведение невозможно. С клиентами под MacOS и BeOS тоже всё нормально с этим vpn-сервером? :) Не знаю, но в таком случае хотя-бы костыль получается не слишком громоздким, потому что адрес VPN сервера скрипт может узнать из переменной $PPP_REMOTE, а вот в случае если выдавать адрес отличный от адреса сервера - взять ip самого сервера изнутри скрипта в /etc/ppp/ip-up.d неоткуда. и даже если его передавать в $PPP_IPPARAM в виде символьного адреса - то надо будет исключить defaultroute и replacedefaultroute тогда его можно будет отрезолвить и поднять интерфейс как надо, но вот досада. возвращать назад надо будет тоже скриптом, и в этом скрипте неоткуда взять адрес старого шлюза. В общем-то я пока не нашел универсального гибкого решения. Заплаток можно сколько угодно сделать но моей целью является придумывания такого способа - чтобы не приходилось впредь менять содержимое каких либо скриптов, а для этого имя vpn сервера должно быть именем а не адресом и информация не должна браться из каких-либо файлов отличных от /etc/ppp/peers/provider. Ну и еще оно должно позволять поднимать несколько ppp интерфейсов как с изменением defaultroute так и без его изменения. Пока никто готового решения не предложил ;) Все норовят чайником обозвать :) Те несколько решений которые пытался реализовать - не покрывают те или иные потребности. Все было-бы проще, если-бы pppd добавлял defaultroute к уже существующему - но он почему-то это не делает - только перезаписывает если указано replacedefaultroute :( Олег. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Косяки с роутинго м ppp при подключении к ак клиент.
Eugene Berdnikov пишет: On Tue, Jan 15, 2008 at 08:14:28PM +0300, Oleg Frolkov wrote: Или выделить пул реальных IP и раздавать vpn серверам для фиктивных интерфейсов? Моим аргументом является то что выделенный мною белый ip не может пересечься ни с чьей внутренней сетью, если-же я буду выдавать что-то типа 10.0.0.1 то теоретически в какой-то конфигурации я из чужой сети с роутером имеющим тот-же адрес не смогу соединиться со своим VPN сервером. Любой придуманный экзотический ip из серой сети может применяться где-то еще, Да, это проблема, и принципиально неразрешимая с IPv4. Но практически она решается уходом с начала адресного диапазона куда-то вглубь, где вероятность пересечься с другой организацией ничтожно мала. В принципе ладно - выделил я еще один белый ip - но плучил другую проблему, все равно без костылей pppd маршрут делает неправильно, а с костылями я не могу - они вызываются уже после удаления defaultroute или с defaultroute приходится работать самому - что приводит к невозможности регулировать тип соединения (устанавливать на него defaultroute или нет) в конфиге pppd для конкретного vpn сервера.. Мало того что если выдаваемый той стороне адрес не равен адрсу сервера (у правильного админа) то получить в костыле ip VPN сервера из его символьного адреса невозможно - потому что в момент передачи управления костылю defaultroute уже снесен и резолвинг не работает. В общем-то вот такие вот шахматы. куда не пойдешь - мат в 1 ход :) Принципиальные проблемы существуют. Даже в винде, сюрприз. Вот яркий пример: винда считает список dns'ов параметром интерфейса, если на ней поднять vpn, то возникнет новый туннельный интерфейс, на котором можно прописать свои dns'ы. В случае pptp, и для цисковких клиентов, и для openvpn, и для некоторых других vpn-нов сервер умеет список dns'ов оправить клиенту, а винда умеет их принять и прописать. А теперь, внимание, вопрос. Какой dns будет использоваться? Вопрос не праздный, потому что домен lan.company.tld, может быть не виден из интернета, и если спросить сначала интернетовский dns, то резолвер получит NXdomain и дальше искать НЕ ПОЙДЁТ. Как быть? Ставить приоритетным тот dns, который на туннельном интерфейсе? Ага, так поступают многие vpn-клиенты, причём это обычно никак не регулируется. Но теперь надо вспомнить, что у нас есть не только та локалка, которая доступна через vpn, но и своя, в которую торчит физический интерфейс. И в своей локалке тоже может быть свой локальный dns, очень-очень нужный для локальной почты, web-прокси и ещё тыщи вещей. Винда этот вопрос решить не может, точнее, костылей для него в винде пока нет. Если я правильно понял Вашу проблему - то надо пойти в свойства VPN соединения - Сеть-TCPIP-Использовать следующие адреса для DNS серверов и там указать ваши локальные DNS и при желании адреса DNS серверов выдаваемых автоматически VPN сервером. В итоге после поднятия этого интерфейса получите нужный список и нужный порядок DNS серверов. Хотя конечно это не решит общей проблемы, винда все равно не пойдет к другому серверу если получила ответ от первого. А разве поведение Линукса в этом плане отличается? Тут тоже вроде как общий список для резолвинга. Еще есть наверное шанс получить нужное поведение если поставить под винду какой-либо локальный DNS сервер, настроить его на нужное поведение а резолвинг завернуть на него. Впрочем это уже совсем оффтопик пошел. Олег. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Косяки с роутинго м ppp при подключении к ак клиент.
Eugene Berdnikov пишет: On Tue, Jan 15, 2008 at 09:37:15PM +0300, Oleg Frolkov wrote: Можно дописать нужную фунциональность к линуксовому pptp-клиенту, снабдив его интеллектом круче виндового. Исходники открыты. Да этого наверное и не надо надо просто поправить /usr/bin/pon - но вот беда в том, что при очередном apt-get dist-upgrade это может запросто затереться хотелось сделать Debian-Way - поменять в таком месте которое не касается при апдейте системы. Олег. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Косяки с роутинго м ppp при подключении к ак клиент.
Eugene Berdnikov пишет: On Mon, Jan 14, 2008 at 07:21:21PM +0300, Oleg Frolkov wrote: роутинг на ip адрес предъявленный с той стороны прописывается на ppp10 ну и defaultroute естественно прописывается туда-же. Если адрес ppp сервера не из локальной сети - получаем завертывание gre пакетов в дефолтроут и соответственно неработу ppp интерфейса. Во-первых, следует поставить маршрут до vpn-сервера ручками. Не маленький, знаю - но это идеологически неверно в случае когда адрес получили с помощью dhcp. Во-вторых, нужно для себя решить, через какой именно шлюз ходить в интернет, а если через разные -- то каким маршрутом в какую сеть идти. Акцепт default route это лишь одно из частных решений задачи выбора. Предположим я могу с ноута выйти в инет с десятка локаций (в том числе и через wifi) я не должен решать - есть стандартные механизмы и они должны отрабатывать данную ситуацию, но они этого не делают. Еще более усугубляет положение выдача удаленным vpn сервером в качестве удаленного адреса ppp интерфейса того-же адреса на какой и цепляемся vpn (что в общем-то естественно если у VPN сервера единственный интерфейс) Не в этом ничего естественного. Это нелепость. Возможно что и нелепость, но в принципе не мешает функционированию системы. Однако адрес типа pointopoint можно в ip-up разобрать на localip:remoteip, удалить его с интерфейса, и потом поднять другой, типа localip/localmask, при этом явный маршрут на remoteip не поднимется. Маска в протоколе ppp не передаётся, но ifconfig может придумать её сам. :) В принципе можно вообще назначить /0 с высокой метрикой, главное, чтобы явный маршрут на remoteip не прошёл через интерфейс ppp. Зачем все эти сложности? В принципе если в дистре это косяк то придется править скрипты на предмет выяснения defaultroute перед изменением маршрутизации и заворачивать роутинг на VPN сервер в сторону указанного там шлюза. Пока спас положение вписыванием строчки: up route add vpn.xx.xx gw localgateway но в общем-то учитывая то что ip адрес получается по dhcp и предполагается что комп (ноут) будет цепляться из разных локаций - придется эту строчку регулярно править в зависимости от локации. Зависит от того самого выбора, о котором писалось выше. Если с выбором проблемы -- пишите рекламации в ip-up, ip-down... Вот цель моего поста выяснить - писать мне рекламации или может я неправильно готовлю ppp ВНИМАНИЕ ВОПРОС! Как это разрулить идеологически правильно? По идее роутинг на VPN сервер должен прописываться туда - куда смотрел старый дефолтроут скриптом устанавливающим соединение. В общем-то винда кушает все без проблем, а тут такой косяк. Похоже, что в MS косяки создаются специально, чтобы потом продавать лекарства от них в виде одной единственно правильной платформы, набитой костылями от искусственно созданных проблем. При чем тут косяки MS? В данном случае я хожу с линукса на линукс. А вот в варианте с MS на линукс подобных проблем не возникает, потому что там не настолько накосячили чтобы заворачивать трафик vpn сервера в туннель. В общем-то если не получу инфы о том что я не прав и подсказок как эту проблему решить изящно - придется править скрипты.. Хотя вообще крайне странно что в stable дистрибутиве положены скрипты которые ПРИНЦИПИАЛЬНО неправильно поднимают ppp соединение и в большинстве случаев ppp из коробки неработоспособен без плясок с бубном. Надеюсь что я не прав. Олег. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Косяки с роутинго м ppp при подключении к ак клиент.
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. А? Во-вторых, нужно для себя решить, через какой именно шлюз ходить в интернет, а если через разные -- то каким маршрутом в какую сеть идти. Акцепт default route это лишь одно из частных решений задачи выбора. Предположим я могу с ноута выйти в инет с десятка локаций (в том числе и через wifi) я не должен решать - есть стандартные механизмы и они должны отрабатывать данную ситуацию, но они этого не делают. Еще более усугубляет положение выдача удаленным vpn сервером в качестве удаленного адреса ppp интерфейса того-же адреса на какой и цепляемся vpn (что в общем-то естественно если у VPN сервера единственный интерфейс) Не в этом ничего естественного. Это нелепость. Возможно что и нелепость, но в принципе не мешает функционированию системы. Ага, функционированию не мешает, но положение усугубляет! :-) Однако адрес типа pointopoint можно в ip-up разобрать на localip:remoteip, удалить его с интерфейса, и потом поднять другой, типа localip/localmask, при этом явный маршрут на remoteip не поднимется. Маска в протоколе ppp не передаётся, но ifconfig может придумать её сам. :) В принципе можно вообще назначить /0 с высокой метрикой, главное, чтобы явный маршрут на remoteip не прошёл через интерфейс ppp. Зачем все эти сложности? В принципе если в дистре это косяк то придется править скрипты на предмет выяснения defaultroute перед изменением маршрутизации и заворачивать роутинг на VPN сервер в сторону указанного там шлюза. Пока спас положение вписыванием строчки: up route add vpn.xx.xx gw localgateway но в общем-то учитывая то что ip адрес получается по dhcp и предполагается что комп (ноут) будет цепляться из разных локаций - придется эту строчку регулярно править в зависимости от локации. Зависит от того самого выбора, о котором писалось выше. Если с выбором проблемы -- пишите рекламации в ip-up, ip-down... Вот цель моего поста выяснить - писать мне рекламации или может я неправильно готовлю ppp ВНИМАНИЕ ВОПРОС! Как это разрулить идеологически правильно? По идее роутинг на VPN сервер должен прописываться туда - куда смотрел старый дефолтроут скриптом устанавливающим соединение. В общем-то винда кушает все без проблем, а тут такой косяк. так и напиши - хочу как в винде и точка! чего воду лить? почему самостоятельно прописать в конфиге маршрут - идеологически неправильно, но если за тебя это делает ОченьУмнаяПрограмма - то всё нормально? Не должен pppd делать больше чем ему предписано в конфиге! Похоже, что в MS косяки создаются специально, чтобы потом продавать лекарства от них в виде одной единственно правильной платформы, набитой костылями от искусственно созданных проблем. +1, и cisco не забудьте При чем тут косяки MS? В данном случае я хожу с линукса на линукс. А вот в варианте с MS на линукс подобных проблем не возникает, потому что там не настолько накосячили чтобы заворачивать трафик vpn сервера в туннель. В общем-то если не получу инфы о том что я не прав и подсказок как эту проблему решить изящно - придется править скрипты.. Хотя вообще крайне странно что в stable дистрибутиве положены скрипты которые ПРИНЦИПИАЛЬНО какой скрипт конкретно имеется ввиду? неправильно поднимают ppp соединение и в большинстве случаев ppp из коробки неработоспособен без плясок с бубном. Надеюсь что я не прав. Олег. -- С уважением, Любимец Андрей Алексеевич -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
