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]
