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_ip<>vpn_ip route add ....
но видимо этого нет, ну да ладно.
почему самостоятельно прописать в конфиге маршрут - идеологически
неправильно, но если за тебя это делает ОченьУмнаяПрограмма - то всё
нормально?
Не должен pppd делать больше чем ему предписано в конфиге!
Вот ему не предписано создавать маршрут до ремотного ip адреса
полученного в результате согласования параметров, однако он
зачем-то его прописывает? Хотя по Вашим словам "не должен".
Дело в том, что задача не прописывать такой маршрут лишена всякого смысла, на
кой тогда
вообще соединение нужно?
Это частный случай - если с той стороны предъявили адрес равный тому с
которым соединяемся - надо использовать
старый маршрут, это-же VPN сервер - если мы создадим маршрут - мы
устроим бесконечную инкапсуляцию, пакет уйдет
в ppp инкапсулируется и капсула опять уйдет в ppp, опять
инкапсулируется, и.т.д. и это будет в 100% случаев если
предъявленный адрес равен тому с которым соединяемся - в общем-то тут не
хватает проверяющего условия в pppd
для обхода этой ситуации.
Хотя по стандарту PPP-интерфейс вообще может не иметь
IP-адреса, но реальных имплементаций, которые этим пользуются я видел только
одну. Но
если IP выдается, то это делать надо.
В общем-то defaultroute создаваемый pppd смотрит в интерфейс ppp и
шлюзом указан 0.0.0.0, адрес предъявленный с той стороны
при создании маршрута не используется. Винда поступает хитрее - она
адресом шлюза указывает локальный ip адрес VPN
интерфейса.
Точно также, поднимая Ethernet интерфейс, у тебя
в таблице маршрутов появляется маршрут в сеть поднятого интерфейса и повлиять
на это
нельзя.
Да, маршрут появляется... но в нем-же не указывается роутер - не так-ли?
Ну видимо все-таки не скрипты, а ppp обладает неким искусственным не
достаточно интеллектом.
Чтобы прописать роутинг до ip полученного на ремотной стороне у него
интеллекта хватает, а для
того чтобы перед этим прописать роутинг до VPN сервера - ему интеллекта
не хватает.
Да PPP вообще знать не знает про какой-либо VPN.
Вот это уже более близко к реальности..... видимо потому и косяк.
В общем-то в лоб я проблему решил убрав defaultroute и
replacedefaultroute из конфига /etc/ppp/provider/xxx
Добавив туда ipparam [EMAIL PROTECTED]
^^^^^^^
Собственно то, с чего тебе предлагали начать. Ты упорно бил себя рукой в
Э.... давайте не путать, мне с этого предложили начать в совсем другом
треде :)
и для того треда это был неправильный совет, там мне помогло unit X для
того чтобы
при соединении с каким-то провайдером я имел конкретный номер pppX
грудь, но в итоге к этому же и пришел. Мне кажется ты просто не умеешь
слушать тех, к кому обращаешься, а предпочитаешь ходить по полю с граблями
с завязанными глазами. Если это действительно так, то всё что мы тебе тут
скажем, ты также пропустишь мимо ушей.
:) - а вот мне кажется что я-то умею слушать, но некоторые пытаются
поучать не выслушав меня и не
вникнув в суть :)
Теперь каждый провайдер требует не только создания скрипта для
подключения но и изменения этих файлов.
Ты можешь применить такой же подход, как и /etc/ppp/ip-up вызывает скрипты
из /etc/ppp/ip-up.d. Создай каталог /etc/ppp/connections.d/ и помещай туда
свои файлы. По одному на провайдера, а потом вызывай их по очереди. А можешь
вообще
значение ipparam использовать как имя скрипта, который надо вызвать. Тебе
придется
создавать файл провайдера и файл скрипта с файерволлом и маршрутами, правки
существующих
файлов можно таким образом избежать, и это Debian-way. В общем подходов масса.
Или тебе
не нравится, что тут два файла, а не один?
Не совсем понял :) Мне не кажется разумным без крайней необходимости
править системные скрипты.
Вызова скриптов из /etc/ppp/connections.d в дистрибутивных скриптах нет
- значит пизать что-то туда это не
Debian-Way. Debian-Way это разместить скрипты в /etc/ppp/ip-up.d и
/etc/ppp/ip-down.d ну или на крайняк написать скрипт
/etc/ppp/ip-up.local который вызывается перед содержимым тех каталогов.
В общем кривой костыль там где винда отрабатывает без проблем.
Покопался в форумах.... от этого
косяка плачет большое количество нубов, они просто не понимают
что такое роутинг, как его настраивать и как он вообще работает.
Не знание законов не освобождает от ответственности. Никакой магии тут нет. А
разобраться в этом только полезно
Это ты мне предлагаешь? Я-то изучу.... но грустно что такие косяки, они
сильно бьют
по репутации системы в качестве системы для конечного пользователя. В
данном случае
косяк на этапе подключения приводящий к замкнутому кругу: "Для решения
проблемы нужен интернет -
пока проблема не решена интернета не будет".
Олег.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
