а может мне кто нибудь пояснить к чему весь этот сырбор.... и чем не устраивает стандартный способ настройки??
Какой стандартный? В GUI Мандривы нет настроек MS VPN вещей и нормальной настройки pptp. NetworkManager в Mandriva не живет.
гм..... поставил pptp-linux..... центр управления -> настройка нового интерфейса .... выбрал pptp и фсе.... потом только исправил точку доступа в /etc/ppp/peers/ppp0....
а может мне кто нибудь пояснить к чему весь этот сырбор.... и чем не устраивает стандартный способ настройки??
Какой стандартный? В GUI Мандривы нет настроек MS VPN вещей и нормальной настройки pptp. NetworkManager в Mandriva не живет.
гм..... поставил pptp-linux..... центр управления -> настройка нового интерфейса .... выбрал pptp и фсе.... потом только исправил точку доступа в /etc/ppp/peers/ppp0....
В конфигураторе сетевая карта определилась вначале правильно, это видно по вашему файлу config. Но теперь если запустить конфигуратор повторно ее больше нет? она не определяется? попробуйте.
При запуске vpnpptp
В консоле пишется ERROR: User name does not exist.
После настройки пробую запустить ponoff в консоле опять появляется ERROR: User name does not exist. а также pppd: процесс не найден (хотя ppp стоит). При этом соединение отсутствует.
Какой пользователь нужен vpnpptp?
При запуске vpnpptp
В консоле пишется ERROR: User name does not exist.
После настройки пробую запустить ponoff в консоле опять появляется ERROR: User name does not exist. а также pppd: процесс не найден (хотя ppp стоит). При этом соединение отсутствует.
Какой пользователь нужен vpnpptp?
При запуске vpnpptp
В консоле пишется ERROR: User name does not exist.
После настройки пробую запустить ponoff в консоле опять появляется ERROR: User name does not exist. а также pppd: процесс не найден (хотя ppp стоит). При этом соединение отсутствует.
Какой пользователь нужен vpnpptp?
root или live
какой именно пакет и какая ось?
Прогу запускал от root.
Mandriva 2010 One
Пакет vpnpptp-kde-one-0.0.2-2mdv2010.0.i586.rpm
Прогу запускал от root.
Mandriva 2010 One
Пакет vpnpptp-kde-one-0.0.2-2mdv2010.0.i586.rpm
попробуй патчи Нужна помощь в тестировании настроек MS VPN в Drakconnect
я так понял - соединение сконфигурировалось, но не поднимается лишь vpn. если провайдер тормозной, то это возможно, поэтому пробуй патчи. твой провайдер предположительно не отзывается за 5 секунд, а в патчах время уже может быть любым.
У меня в консоле тоже самое пишет, но при этом работает.
Прогу запускал от root.
Mandriva 2010 One
Пакет vpnpptp-kde-one-0.0.2-2mdv2010.0.i586.rpm
попробуй патчи Нужна помощь в тестировании настроек MS VPN в Drakconnect
я так понял - соединение сконфигурировалось, но не поднимается лишь vpn. если провайдер тормозной, то это возможно, поэтому пробуй патчи. твой провайдер предположительно не отзывается за 5 секунд, а в патчах время уже может быть любым.
У меня в консоле тоже самое пишет, но при этом работает.
Попробовал с патчами. Тоже самое.
Из под винды соединяется нормально.
Выдает MessageBox "Произведена попытка VPN PPTP"
Время ожидания ставил аж 120 сек.
У меня на работе поднят VPN шлюз вот к нему и пытаюсь подключиться.
программа работает, значит, не пускает не она. она вызывает pppd, об этом свидетельствует сообщение "Произведена попытка VPN PPTP".
выясните причину - сообщите. посмотрите логи pppd.
и поиграйте настройками http://www.opennet.ru/man.shtml?topic=pppd&category=8 - может и заработает.
Проблемы же с инетом возможны по следующим причинам (если все установлено правильно):
- закрыт фаерволл,
- не работает инет на стороне провайдера
- проблемы с роутингами
- возможно еще мешается network manager.
Более редкая проблема, когда не может подняться VPN: помогает удаление и поднятие всех сетевых интерфейсов. pptp не знает, куда коннектиться, но пытается создать интерфейс ppp0, после чего отваливаются все другие интерфейсы, но VPN не поднимается.
Готовы патчи, особенно для тех, у кого конфигуратор отработал нормально, но vpn так и не поднялось из-за того, что сетевая карта не поддерживала некоторые команды. При этом пишет "No Ethernet...". В этом случае в Конфигураторе поставьте галочку "Не контролировать state сетевого кабеля".
скопировать оба файла под root в /opt/vpnpptp http://narod.ru/disk/15607012000/vpnpptp.html http://narod.ru/disk/15607028000/ponoff.html
но учтите, что в этом случае вы лишаетесь привязки к конкретной сетевой карте (для одной сетевой карты некритично вообще), утрачиваете скоростную индикацию и увеличиваете нагрузку на систему при обрыве связи.
romkaromka - сделай версию 0.2.1 к примеру с этими изменениями в исходниках. Я пакеты в субботу обновлю.
Я только что залил на google релиз 0.0.3, Вы только spec-файл там в исходниках обновите, потому что у меня старая его версия. И сделайте ярлычок для Конфигуратора VPN PPTP на Рабочий стол пользователя live для версии vpnpptp-kde-one.
romkaromka - сделай версию 0.2.1 к примеру с этими изменениями в исходниках. Я пакеты в субботу обновлю.
Я только что залил на google релиз 0.0.3, Вы только spec-файл там в исходниках обновите, потому что у меня старая его версия. И сделайте ярлычок для Конфигуратора VPN PPTP на Рабочий стол пользователя live для версии vpnpptp-kde-one.
В субботу приеду из Перми и сделаю. Релиз пакетов значит в воскресенье.
==Возможности версии 0.0.3==
* 1) проверка корректности вводимых пользователем в конфигураторе данных.
* 2) разрешено пользователям самим задавать время дозвона (максимальное время ожидания ответа провайдера на звонок при отсутствующем соединении) в пределах от 5 до 255 сек.
* 3) разрешено пользователям самим задавать время реконнекта (время реакции на пропадание соединения, время контроля за состоянием поднятого соединения) в пределах от 1 до 255 сек.
* 4) разрешены 10 сетевых карт от eth0 до eth9.
* 5) теперь для mtu разрешен диапазон [576..1460..1492..1500], рекомендуется 1460.
* 6) поправлен недочет автоматического определения сетевого интерфейса и шлюза локальной сети в конфигураторе, если пытаться настроить vpn на ethN, где 0<N>10 (то есть если сетевой интерфейс отличен от eth0, то есть имеет меньший приоритет).
* 7) реконнект теперь опционален, на выбор пользователя предложено 2 варианта:
* a) при пропадании vpn выйти из программы и при выходе падать до тех пор, пока какой-нибудь следующий по приоритету интерфейс самостоятельно не примет на себя задачу дефолтного интерфейса (в том числе и тот интерфейс, на котором упало vpn, также будет участвовать в конкурсе на роль дефолтного интерфейса опционально), то есть делается попытка вернуть состояние системы в состояние до момента запуска vpn, а при неудаче - на ближайшем по приоритету интерфейсе, при отсутствии же последнего сеть будет считаться опущенной на всех интерфейсах.
* b) при пропадании vpn, как и в предыдущих версиях программы, ждать появления технической возможности поднятия vpn, но пока происходит такое ожидание - временно поднять сеть на каком-нибудь следующем по приоритету интерфейсу, который самостоятельно примет на себя задачу дефолтного интерфейса (в том числе и тот интерфейс, на котором упало vpn, также будет участвовать в конкурсе на роль дефолтного интерфейса опционально), то есть делается попытка вернуть состояние системы в состояние до момента запуска vpn, а при неудаче - на ближайшем по приоритету интерфейсе, при отсутствии же последнего сеть будет считаться опущенной на всех интерфейсах. Однако, в отличии от первого варианта реконнекта программа будет ждать появления технической возможности поднятия vpn, на том интерфейсе, на котором он был сконфигурирован, и при ее появлении поднимать vpn, покидая временный интерфейс, если он был активирован.
* 8) теперь сколько бы в системе не было сетевых интерфейсов, программа бережно обращается с ними со всеми, сама их не задевает, а если их задевает сам процесс pppd (а именно он их и задевает, так как самостоятельно выполняет скрипты ip-up, ip-down), то программа исправит за ним его ошибки, поэтому в любой момент времени сеть на чем-нибудь будет поднята (если только реально есть на чем поднять сеть).
* 9) появилась возможность автоматического переключения на другого провайдера, идущего в порядке очередности по приоритету сетевого устройства, на котором он был закреплен.
* 10) улучшилась индикация NetApplet, стала быстрее, индикация ponoff полностью с ней синхронна.
* 11) падение ppp0 при аварии теперь определяется и обрабатывается мгновенно (кроме случаев падения vpn-сервера - обработка теоретически с задержкой и dns-серверов неизвестно как обрабатывается).
* 12) попытка вновь поднять vpn происходит мгновенно как только сетевушка поднялась после аварии или отключения.
* 13) с легкостью временно переключается на другого провайдера и также легко переключается обратно.
* 14) сетевые карты больше не отключаются вообще сколько аварий не делай.
* 15) необходимость в базе учета интерфейсов отпала и сеть отдана на самостоятельное течение системы, которая неплохо с этим справляется.
* 16) ppp0 полностью привязан к конкретной сетевой карте, на которой он был настроен.
* 17) скрипт /etc/ppp/ip-down.d/ip-down теперь пустой, в него ничего не пишите, вместо него можно будет использовать скрипт /opt/vpnpptp/ip-down - в нем и будут теперь маршруты при отключении ppp0; на практике скрипт /opt/vpnpptp/ip-down будет выполняться лишь при выходе из программы, по есть по кнопке Выход (у нас он пустой за неимением таких маршрутов).
* 18) самое главное: программа полностью исправила 2 бага в pppd: 1) баг, связанный с неучитыванием state сетевого интерфейса, на котором поднималось vpn, и, как следствие, нарушение целостности сетевых интерфейсов, 2) баг крайне медленной реакции на аварийную ситуацию, как следствие не учитывания того же самого state, и наша программа научилась управлять pppd как по часовому механизму.
* 19) теперь необходимы 2 Выхода из программы: с выполнением скрипта опускания и без выполнения скрипта опускания, потому что на момент выхода из программы ponoff может либо не быть аварии, а может и быть авария; то есть возвращать сеть в состояние до поднятия vpn или нет.
* 20) для тех, у кого конфигуратор отработал нормально, но vpn не поднимается из-за того, что сетевая карта не поддерживает некоторые команды (когда не поддерживаются MII запросы - но это должна быть очень древняя сетевая карта,или очень дешевая)- в этом случае в Конфигураторе поставьте галочку "Не контролировать state сетевого кабеля", но учтите, что в этом случае вы лишаетесь привязки к конкретной сетевой карте (для одной сетевой карты некритично вообще), утрачиваете скоростную индикацию и увеличиваете нагрузку на систему при обрыве связи.
* Примечания: Оба варианта реконнекта удобны тем, что при падении vpn, если авария не критическая, то локальная сеть на сет. устройстве, где упало vpn, должна продолжить свою работу (планирую опцию возможности отключения для этого случая и локальной сети), но если критическая, то прекратят работать и vpn, и локальная сеть, при этом начнут работать другие сетевые интерфейсы, а значит в этом случае появляется возможность автоматического переключения на другого провайдера.
* Аксиома1: сетевые интерфейсы (ethN) eth0-eth9 различаются по приоритету. Чем больше N, тем меньше приоритет у сетевого устройства. Система самостоятельно решает в какой момент времени какой сет. интерфейс будет дефолтным исходя из его приоритета и его state. Это правило одного дефолтного интерфейса (в системе может быть лишь один дефолтный шлюз).
* Имеется состояние системы А. Мы переводим его из состояния А в состояние Б посредством демона pppd. При переводе из А в Б демон pppd самостоятельно использует инструкцию АБ, а при переводе из Б в А – самостоятельно инструкцию БА. Демон pppd также самостоятельно обнаруживает падение поднятого им же vpn и при этом переводит состояние системы из Б в А через инструкцию БА. Но а что если теперь состояние интерфейса А изменилось? В этом случае демон pppd сделает грубые ошибки – это критический баг демона pppd – походу он не умеет отслеживать state.
* Решение: подсунуть демону pppd такую инструкцию БА, при выполнении которой никаких изменений не произойдет (обычную пустышку) и самостоятельно в программе обработать корректный перевод из Б в А с учетом state интерфейса А. Система же, потеряв интерфейс ppp, самостоятельно найдет ближайший подходящий интерфейс, учитывая аксиому1. От нас лишь требуется запомнить и бережно хранить инструкцию БА.
Инструкция АБ - это скрипт ip-up, а инструкция БА - это скрипт ip-down.
==Идеи и нерешенные проблемы конфигуратора и интерфейса управления соединениями VPN через PPTP==
* 1) нет логов соединения pppd.
решение: возможно будет добавлено.
* 2) ppp0 плохо интегрирован в NetAplet.
решение: практически он может лишь запускаться из Настройки Сети, дальнейшая интеграция зависит от разработчиков ОС мандрива.
* 3) улучшить занесение пользователем маршрутов в конфигураторе.
решение: предложить пользователю таблицу с графами host, net, netmask, gw, dev с подсказками что означает каждая графа и предложить выпадающие списки для каждой из граф с имеющимися в данной конкретной системе значениями.
* 4) не обеспечена возможность задания и одновременной работы двух и более pptp-подключений, в том числе не только на разных сетевых картах, но и на одной.
решение: идея пока преждевременная.
* 5) не обеспечена база провайдеров, для которых тест пакета прошел успешно, и установка простым выбором из списка по этой базе.
решение: найдено, возможно постепенно база будет увеличиваться, а возможно это и лишнее.
* 6) не обеспечен автозапуск vpn при старте системы.
решение: можно добавить, но смысла особого в этом нет.
* 7) недостаточно крепко закреплен в трее. в случае падения plasma значек ponoff пропадает из трея, а другие значки других приложений остаются, то же самое происходит при рестарте графического сервера.
решение: в поиске.
* 8) необходимость ручного указания маршрутов до vpn - серверов и до dns - серверов.
решение: в поиске.
* 9) стоит проверять все dns из resolf.conf и предупреждать пользователя при падении любого из них всплывающим сообщением - это при запущенном в трее ponoff; уже при первом запуске ponoff если ни один из dns-серверов из resolf.conf не отвечает, то нет смысла поднимать ppp0 - сейчас же в этом случае пакет ведет себя произвольно.
решение: в разработке.
* 10) попробовать прикрутить логику из последнего скрипта с Корбины (особенно в части динамического определения dns).
решение: при возникновении потребности в этом будет реализовано.
* 11) в конфигураторе DSL в drakconnect 2010 появился pptp туннель - подумать как его задействавать в пакете vpnpptp.
решение: особой надобности в этом нет.
* 12) подумать над тем, что кодировка у пользователей может отличаться от utf8.
решение: особой надобности в этом нет.
* 13) оптимизировать код; меньше вызывать shell если можно иначе написать.
решение: в разработке.
* 14) сделать чтобы vpnpptp и ponoff могли работать и без установки.
решение: особой надобности в этом нет.
Ребята, напишите, пожалуйста, скрипт, настраивающий ведение логов pppd. К примеру так: http://sysoev.ru/pppd/logs.html.
Должен вестись общий и единственный лог для всего - /var/log/pppd.log.
При запуске скрипт должен проверять если уже есть файл /var/log/pppd.log, то естественно не выполняться.
Скрипт требуется для встраивания в нашу программу.
Ребята, напишите, пожалуйста, скрипт, настраивающий ведение логов pppd. К примеру так: http://sysoev.ru/pppd/logs.html.
Должен вестись общий и единственный лог для всего - /var/log/pppd.log.
При запуске скрипт должен проверять если уже есть файл /var/log/pppd.log, то естественно не выполняться.
Скрипт требуется для встраивания в нашу программу.
Так и не заставил работать модуль ponoff, зато конфигуратор работает великолепно! После его работы остаётся только выбрать активный интефейс в NetApplet. Посему прошу не выносить правку скриптов ip-up/ip-down и иже с ними в отдельный каталог с программой
Так и не заставил работать модуль ponoff, зато конфигуратор работает великолепно! После его работы остаётся только выбрать активный интефейс в NetApplet. Посему прошу не выносить правку скриптов ip-up/ip-down и иже с ними в отдельный каталог с программой