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

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_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 user1@provider1
               ^^^^^^^
Собственно то, с чего тебе предлагали начать. Ты упорно бил себя рукой в
Э.... давайте не путать, мне с этого предложили начать в совсем другом треде :) и для того треда это был неправильный совет, там мне помогло 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 который вызывается перед содержимым тех каталогов.

В общем кривой костыль там где винда отрабатывает без проблем.
Покопался в форумах.... от этого косяка плачет большое количество нубов, они просто не понимают
что такое роутинг, как его настраивать и как он вообще работает.
Не знание законов не освобождает от ответственности. Никакой магии тут нет. А
разобраться в этом только полезно
Это ты мне предлагаешь? Я-то изучу.... но грустно что такие косяки, они сильно бьют по репутации системы в качестве системы для конечного пользователя. В данном случае косяк на этапе подключения приводящий к замкнутому кругу: "Для решения проблемы нужен интернет -
пока проблема не решена интернета не будет".

Олег.


Reply to: