Конфигуратор и интерфейс управления соединениями VPN через PPTP/L2TP/OpenL2TP

Материал из Edumandriva

Содержание

A) Введение

  • Конфигуратор соединений (vpnpptp) и интерфейс управления (ponoff) для VPN через PPTP/L2TP/OpenL2TP - Корбина, Корбина-Билайн и другие.
  • Реализация: Lazarus + FPC.
  • Пакеты для многих дистрибутивов есть в репозиториях различных дистрибутивов и на сайте проекта:
  • http://code.google.com/p/vpnpptp/downloads/list
  • Пакет входит в дистрибутивы: дистрибутивы Edumandriva, Mandriva (иногда), Rosa, MagOS, MiniOS, КСоНоМи, PCLinuxOS Russian Community Edition, Сиалия, Linux Mint Russian Edition от Lazarus, CruduX, Ubuntu от Ruben. Также пакет используется в PCLinuxOS, Ubuntu, Debian, openSUSE, Fedora, Mageia, Kubuntu.
  • Программа представлена в версиях пакетов:
  • 1) vpnpptp-kde-one - в этой версии нет никаких зависимостей, поэтому она работает прямо так в любом дистрибутиве, но только для KDE (или в других DE, но с самостоятельным запуском из-под root или из Центра Управления Mandriva/PCLinuxOS/Mageia).
  • 2) vpnpptp-allde - в этой версии имеются дополнительные зависимости, поэтому она работает в любом дистрибутиве в любых DE, но эти зависимости могут отсутствовать в дистрибутиве, и тогда потребуется интернет, чтобы скачать их.
  • 3) vpnpptp - эти версии пакета собраны для конкретных дистрибутивов, как правило без дополнительных зависимостей, как правило для любых DE, но они как правило не могут быть использованы в другом дистрибутиве, кроме того, для которого они были собраны.
  • Начиная с версии 0.3.4 пакеты vpnpptp-kde-one упразднены, а в vpnpptp-allde отсутствуют какие бы то ни было зависимости.

B) Релизы конфигуратора и интерфейса управления соединениями VPN через PPTP/L2TP/OpenL2TP

I) Возможности версии 0.0.1

  • 1) графика.
  • 2) частичная безопасность - конфигуратор только под root, запуск vpn под любым пользователем и root.
  • 3) автоматическое определение шлюза локальной сети (работает лишь при невыключенной сетевой карте и подключенном кабеле).
  • 4) задание mtu.
  • 5) работа с одним провайдером и с одной сетевой картой (прописав лишь маршруты в rc.local, задав логин, пароль, адрес vpn-сервера), конфигурация одного соединения ppp0 через pptp.
  • 6) шифрование.
  • 7) возможность задания дополнительных маршрутов вида: /sbin/route add -net 'то, что введено в поле ввода маршрутов' (указывать без шлюза).
  • 8) создание необходимых конфигурационных файлов и ярлыка на рабочих столах всех пользователей.
  • 9) поднятие и опускание соединения ppp0 кнопками Подключить/Отключить, а также автозапуск при запуске модуля ponoff, и опускание соединения ppp0 при выходе.
  • 10) автоматическое определение всех IP-адресов VPN-сервера с занесением маршрутов.

замечание: заявлено, но не работает при отсутствии в системе пакета bind-utils.

  • 11) возврат дефолтного маршрута локальной сети при выходе или отключении.
  • 12) генерируется ссылка из /sbin/ip в /bin/ip.
  • 13) файлы route и status.ppp удаляются при выходе (они скрыты).
  • 14) реконнект после аварии частично реализован.
  • 15) поправлена индикация.
  • 16) программа может работать без установки, достаточно скопировать содержимое архива (или пакета) в /opt/vpnpptp.

II) Возможности версии 0.0.2

  • 1) совместимость с live-дистрибутивом полная; никогда еще выход в интернет через vpn без установки операционки не был таким простым.
  • 2) полная безопасность - конфигуратор и интерфейс управления теперь запускаются только под root и под live-пользователем, в них встроена самостоятельная проверка под кем они запускаются.
  • 3) отказ от sudo; в установленной системе теперь при запуске vpnpptp и ponoff через gui запрашивается пароль администратора.
  • 4) после конфигурирования на Рабочем столе появляется ярлык интерфейса управления ponoff; он также как и конфигуратор помещается в Меню, Утилиты, Системные (или в Меню, Интернет).
  • 5) подсказка ponoff о необходимости сначала сконфигурировать соединение стала точнее.
  • 6) отказ от /usr/bin.
  • 7) поправлены все сообщения, индикация, подсказки стали более подробными и исправлены опечатки.
  • 8) отказ от кнопок Отключить/Подключить в ponoff - осталась лишь кнопка Выход.
  • 9) служебные окна спрятаны с экрана.
  • 10) теперь разрешено добавлять маршруты абсолютно любые, даже не относящиеся к настраиваемому соединению, но требующиеся при поднятии vpn, причем они могут быть написаны как угодно лишь бы по правилам linux, в том числе допускаются комментарии.
  • 11) исправлено в связи с изменением в Мандриве 2010.0 идентификатора пользователя создание ссылки на приложение ponoff на рабочих столах пользователей, без поправки ссылка не создавалась.
  • 12) в модуле ponoff поправлен баг путем отказа от пакета bind-utils: вызывалась команда из пакета bind-utils, но в дистрибутиве его может не быть, и получить нельзя без интернета, нет и в зависимостях пакета vpnpptp.
  • 13) исправлен баг: когда вызывается команда pppd call <имя соединения>, то скрипт ip-up выполняется сам, выполнялся же дважды, потому что вызывался в программе.
  • 14) исправлено: ранее убивался pppd и затем выполнялся скрипт ip-down, теперь же сначала выполняется скрипт ip-down, а затем команда killall pppd - в итоге маршруты при опускании vpn практически не страдают.
  • 15) в режиме установленного соединения пишет теперь название соединения из /etc/ppp/peers/имя_соединения, то есть индикация теперь по имени соединения, которое было введено в конфигураторе.
  • 16) исправлен баг поднятия нескольких ppp: теперь при запуске vpn убиваются все иные vpn, поэтому несколько ppp не создастся.
  • 17) при старте ponoff, как и раньше, происходит автоматическое поднятие vpn, но теперь почти мгновенно (скорость поднятия vpn увеличена существенно и зависит лишь от провайдера), если же этого не произошло, то через каждые 20 сек. срабатывает таймер, и vpn все равно поднимется рано или поздно (если провайдер не тормозной и укладывается в 20 секунд).
  • 18) при аварии в сетевом кабеле таймер каждую секунду проверяет наличие технической возможности поднятия vpn, и в случае если сетевой интерфейс, на котором требуется поднять vpn, вновь появится, то vpn будет автоматически поднято.
  • 19) исправлен баг в ponoff: vpn поднималось от простого перемещения мышки на значке ponoff в трее.
  • 20) убраны тормоза при работе приложения ponoff путем отказа от длительного sleep.
  • 21) автоконнект при запуске ponoff работает стабильно и быстро, также стабильно и быстро работает реконнект после аварии.
  • 22) теперь даже при падении иксов и входа в систему с уже поднятым vpn - ponoff его убьет и создаст новое.
  • 23) верная индикация без задержек; индикация значка в трее полностью синхронизирована с NetApplet (с точностью до 1000 мсек.).
  • 24) значек в трее теперь меняется в зависимости от состояния соединения (оранжевый - нет соединения, зеленый - есть соединение).
  • 25) исключена возможность повторных запусков как vpnpptp, так и ponoff.
  • 26) отслеживается state сетевого кабеля.
  • 27) привязка vpn к конкретной сетевой карте: в конфигураторе идет ее автоопределение, как в предыдущей версии было сделано с локальным шлюзом, она запоминается и всегда проверяется ее состояние в ponoff.
  • 28) при запуске ponoff проверяется наличие технической возможности поднятия vpn и в случае явной невозможности его поднятия указывается причина и происходит выход из программы.
  • 29) теперь ponoff откажется поднять vpn на сетевой карте, на которой он не был сконфигурирован.
  • 30) исправлен баг в конфигураторе vpnpptp: если сетевая карта была отключена, то конфигуратор в предудущей версии падал, теперь выводится сообщение с предложением включить сетевую карту, однако даже если она так и не будет включена, то это нормально обработается.
  • 31) теперь жестко следится за тем, чтобы все временные файлы сами удалялись.
  • 32) автоматизация настройки vpn в конфигураторе сведена к практически идеальной: помимо того, чего уже сделано, теперь еще обрабатываются многие нештатные варианты и пользователю сообщается об этом - рассмотрена обработка конфигуратором невозможности правильного определения шлюза локальной сети при поднятом vpn, а также при неподключенном кабеле или ненастроенных сетевых параметрах, если они не автоматически определяются у провайдера, как-то: ип, шлюз, маска, dns-сервер.
  • 33) теперь обрабатывается ситуация когда в системе нет пакета pptp-linux и его не удается установить автоматически - в этом случает конфигуратор прекращает работу, уведомляя о причине.
  • 34) обход по Tab в конфигураторе vpnpptp теперь правильный.
  • 35) при запуске vpnpptp теперь сразу появляется информационное сообщение, и не придется ждать несколько минут в неведении "а запустился ли конфигуратор vpnpptp?".
  • 36) изменено выводимое по окончании работы конфигуратора информационное сообщение: теперь оно более информативное и содержит инструкции для пользователей "что делать дальше".
  • 37) временный отказ от автоматического определения всех IP-адресов VPN-сервера с занесением маршрутов.
  • 38) директорией для временных файлов теперь является /tmp.
  • 39) теперь каждый процесс использует только свой временной файл.
  • 40) исключены ошибки падений программы при запуске от простых пользователей, связанных с отсутствием у них прав на то или иное действие, выполняемое алгоритмом программы.
  • 41) теперь техподдержка проекта осуществляется также разработчиком по адресу: loginov_alex@inbox.ru - принимаются замечания и пожелания.

III) Возможности версии 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.

IV) Возможности версии 0.0.4.1

  • 1) конфигуратор теперь автономен, он вновь пишет скрипт /etc/ppp/ip-down.d/ip-down, его признает ponoff в режиме встроенного в демон pppd реконнекта.
  • 2) добавлен режим встроенного в демон pppd реконнекта (по умолчанию отключен и рекомендуется лишь для одной сетевой карты). ponoff же обрабатывает оба варианта реализации реконнекта.
  • 3) реализация получения маршрутов через DHCP в порядке тестовой возможности программы (включено по умолчанию).
  • 4) добавлено ведение логов pppd в порядке тестовой возможности программы (отключено по умолчанию).
  • 5) заведен каталог /opt/vpnpptp/scripts - для различных скриптов, используемых программой.
  • 6) заведен каталог /opt/vpnpptp/lang - для различных локализаций, используемых программой.
  • 7) встроенный в демон pppd реконнект работает также как и в скрипте Корбины (показания NetApplet в этом случае хотя и верные с запаздыванием, но NetApplet перегружен и может долго не отвечать, а то и зависать; ponoff в этом случае работает лучше, чем NetApplet, не зависая и отвечая на запросы).
  • 8) скрипт /etc/ppp/ip-down.d/ip-down в режиме по умолчанию (в режиме не использования встроенного в демон pppd реконнекта) ponoff прячет от демона pppd, как и раньше подкладывая ему пустышку, но возвращает его на место и все, что в этом скрипте будет записано будет непременно исполнено, поэтому от скрипта /opt/vpnpptp/ip-down отказались.
  • 9) в понятие "время реконнекта" теперь вносится еще смысл "время LCP эхо-запроса" для режима встроенного в демон pppd реконнекта, в этом случае оно не может быть менее 20 сек.
  • 10) проверяется "а есть ли pppd" в процессах, прежде чем убивать pppd.
  • 11) оптимизирована работа ponoff в режиме неконтролирования state сетевого кабеля и в режиме встроенного в демон pppd реконнекта за счет того, что не проверяется в этом случае mii-tool вообще.
  • 12) при выборе режима получения маршрутов через DHCP в конфигураторе происходит рестарт сетевых служб.
  • 13) программа локализована на русский и английский языки (английский язык устанавливается сам если локализация отлична от русской).
  • Примечание: live-пользователь не имеет права рестарта сетевых служб, поэтому перезапускайте под root вручную командой /etc/init.d/network restart если было выбрано получение маршрутов через dhcp.

V) Возможности версии 0.0.5

  • 1) конфигуратор сохраняет все введенные пользователем данные и последующее переконфигурирование стало удобным (логин и пароль для безопасности не хранятся в папке программы в ее config-файле), при повторной конфигурации вводить вновь ничего не надо, в полях ввода предложены ранее введенные значения, их только просто можно поправить - это позволит находить ошибки в конфигурировании и облегчит ввод из-за отсутствия необходимости повторного ввода значений,
  • 2) новая версия файла /opt/vpnpptp/config не совместима с предыдущими его версиями, поэтому при установке программы vpnpptp 0.0.5 удалите файл /opt/vpnpptp/config,
  • 3) теперь конфигуратор добавляет в исключения файервола интерфейсы [ppp0..ppp9] и перезапускает файервол при необходимости (необходимость перезапуска также проверяется), поэтому модуль ponoff сразу же способен выйти в интернет, однако необходимо помнить, что файервол не отключен,
  • 4) поправлены недочеты для live-пользователя, возникающие в связи с необходимостью перезапуска системных служб, на которые имеет права лишь администратор, а также при записи в директории, принадлежащие администратору; в итоге в live-режиме работать стало еще комфортнее,
  • 5) поправлено получение маршрутов через DHCP - если уже настроено, то не перенастраивать вновь, а при отмене выбора - отменять получение маршрутов через DHCP,
  • 6) оформлена wiki на сайте проекта пока на русском языке.
  • Примечание: теперь гарантируется выход в интернет - для этого и настроен файервол, однако в связи с тем, что файервол не отключен /не настроен, невозможно скачивать с хабов сети p2p, нельзя соединиться ни с одним из пользователей, не работает поиск по хабам и т.д.
  • При сборке пакетов обратите особое внимание на необходимость удаления файла /opt/vpnpptp/config, если он существует.

VI) Возможности версии 0.0.6

  • 1) поддержка конфигуратором минимального разрешения: высота 600 точек, ширина - любая,
  • 2) поддержка нетбуков,
  • 3) форма масштабируется, ее шрифт также меняется в зависимости от разрешения,
  • 4) в конфигураторе убраны табы,
  • 5) правильное создание ярлыка на рабочем столе в любом DE, а при неудаче создания ярлыка (в случае отсутствия файла /usr/share/applications/ponoff.desktop и/или нестандартного идентификатора пользователя, и/или нестандартной локализации) - информирование об этом,
  • 6) изменение алгоритма работы с live-пользователем без изменения функционала в live-системе, оптимизация кода,
  • 7) добавлен перевод на украинский язык,
  • 8) добавлена возможность изменять любые языковые ресурсы программы, в том числе и русские ресурсы (путем правки файла /opt/vpnpptp/lang/vpnpptp.ru.po) - это может быть полезно для приведения своих примеров, в частности, адресов vpn-сервера, имени соединения и т.д.
  • 9) поправлено: в одном месте программа пыталась убить уже убитый демон pppd,
  • 10) поправлено: при выходе из ponoff без аварии программа иногда забывала вернуть состояние сети, которое было до поднятия vpn, но подготавливала почву для этого возвращения,
  • 11) поправлено: при входе/выходе из ponoff без аварии/при аварии в какой-то момент программа иногда теряла скрипт ip-down,
  • 12) теперь конфигуратор на всякий случай (хотя это с каждым релизом все менее вероятно) исправляет ошибки за модулем ponoff, поэтому если вдруг стало работать что-то не так как было раньше, то просто переконфигурируйте соединение,
  • 13) поправлено графическое отображение ярлыка ponoff, созданного конфигуратором, в DE, отличных от KDE, так как требования к такому ярлыку предъявляются как к исполняемому файлу, находящемуся в директории, которая по-умолчанию не является директорией, в которой хранятся исполняемые файлы,
  • 14) изменен алгоритм выхода при аварии из модуля ponoff, ведь при выборе этого режима пользователь отдает себе отчет в том, что на линии авария; при выборе этого режима все сетевые интерфейсы перезапускаются (то есть организован конкурс интерфейсов, победитель в этом сражении получает приз - на нем поднимается сеть) - в итоге сеть поднимается по алгоритму, который используется при запуске компьютера и если этот интерфейс действительно аварийный, то и не поднимется на нем; в режиме аварийного выхода нет смысла возврата к интерфейсу, который пользователь считает аварийным; гораздо лучше было организовать конкурс интерфейсов; зато если пользователь по ошибке выберет аварийный выход, а в системе всего одна рабочая и настроенная сетевая карта, а аварии на самом деле нет, то сеть поднимется на ней, и оба эти режима выхода в этом случае становятся почти идентичными с той лишь разницей, что интерфейсы кратковременно перезапускаются; при ошибочном аварийном выходе если сетевая карта, на которой было поднято vpn, имеет наивысший приоритет, то сеть будет поднята на ней при аварийном выходе из ponoff; введением такого алгоритма продолжается идея, реализованная в алгоритмах реконнекта - управление сетью вновь отдается операционной системе, которая неплохо справляется с этой задачей,
  • 15) обеспечена совместимость config-файлов от предыдущих версий программы,
  • 16) добавлено запоминание в config-файле опции "Добавить ярлык на Рабочий стол", но уже созданный ярлык удаляться с рабочего стола не будет,
  • 17) добавлена поддержка шифрования require-mppe-128, поправлены недостатки интерфейса в части шифрования, поправлен алгоритм работы с шифрованием,
  • 18) поправлена работа конфигуратора при поднятом vpn.

VII) Возможности версии 0.0.7

  • 1) поправлено получение маршрутов через dhcp для обеспечения одновременной работы локальной сети и интернета (если провайдер присылает такие маршруты), особое внимание при этом было уделено тому, чтобы при этом не затрагивались иные сетевые интерфейсы, кроме того, на котором настраивается/поднимается vpn,
  • 2) в отсутствие пакета pptp-linux конфигуратор позволит сконфигурировать соединение, но предупредит об этом,
  • 3) поправлена поддержка config-файлов от предыдущих версий программы,
  • 4) теперь введенные пользователем маршруты запоминаются в файле /opt/vpnpptp/route и при последующем переконфигурировании их более вновь вводить не прийдется,
  • 5) запомненные в файле /opt/vpnpptp/route маршруты появляются в таблице маршрутизации при поднятии vpn (через скрипт ip-up) и убираются из таблицы маршрутизации при опускании vpn (через скрипт ip-down), ранее они при опускании vpn не убирались,
  • 6) появилась возможность, используя файл /opt/vpnpptp/route, выпускать региональные сборки,
  • 7) код работы с файерволом переписан, особое внимание, как и прежде, было уделено обратимости внесенных конфигуратором изменений в системные файлы операционной системы - теперь настройку файервола можно отменить в конфигураторе,
  • 8) в файле /etc/ppp/peers/имясоединения логин и пароль хранятся открытым текстом, поэтому были настроены права доступа (chmod 600),
  • 9) версия vpnpptp-0.0.7 обновляется с версии vpnpptp-0.0.6 без необходимости удаления предыдущей версии и при этом все настройки становятся доступными для новой версии программы,
  • 10) теперь при выборе опции получения маршрутов через dhcp в конфигураторе, модуль ponoff перед поднятием vpn пытается получить такие маршруты от провайдера, поэтому подниматься vpn будет либо на доли секунды дольше (либо иногда, крайне редко, дольше на время дозвона),
  • 11) у кого ранее было настроено получение маршрутов через dhcp, то в конфигураторе его надо отменить и при переконфигурировании выбрать вновь,
  • 12) изменены: fpc-src = 2.0.4, fpc = 2.0.4.

VIII) Возможности версии 0.0.8

  • 1) поддержка беспроводных интерфейсов wlan0..wlan9, что позволяет поднимать vpn не в роутере, а в операционной системе, что особенно важно для роутеров, не поддерживающих pptp,
  • 2) поправлена работа с файерволом для Mandriva 2009,
  • 3) собраны пакеты для 64-битных систем,
  • 4) добавлена проверка на наличие в процессах dhclient, а также на то установлен ли он; добавлено предупреждение при выборе опции получения маршрутов через dhcp о проблемах с dhclient,
  • 5) добавлена кнопка определения IP VPN-сервера, позволяющая также проверить ping VPN-сервера,
  • 6) отказ от опции defaultroute в файле /etc/ppp/peers/имя_соединения,
  • 7) решен вопрос циклически рвущегося и циклически самовосстанавливаемого по механизмам реконнекта соединения (или просто рвущегося соединения в случае невыбранного реконнекта), а также решен вопрос неустанавливаемого соединения - все это было связано с потерей vpn-сервера при поднятом vpn pptp или с несовпадением remote IP address, предоставленного vpn-сервером, с ip-адресом vpn-сервера - эти вопросы решены путем добавления в конфигураторе опции программного добавления маршрута к vpn-серверу,
  • 8) улучшение работы программы с таблицей маршрутизации,
  • 9) улучшен диалог с пользователем - в сообщениях стало содержаться много справочной информации,
  • 10) сохранение резервных копий всех системных файлов, изменяемых программой,
  • 11) исправлено: при выходе из ponoff без аварии иногда для системы не возникало дефолтного шлюза; теперь это событие проверяется, и если дефолтного шлюза нет, то он появляется,
  • 12) время запуска конфигуратора существенно ускорено за счет изменения алгоритма проверки установлен ли пакет pptp-linux и отказа от его установки вообще - пользователю лишь сообщается о проблеме, но проблема автоматически не исправляется, так как на этой стадии интернета часто нет,
  • 13) ускорена работа интернета на порядок за счет добавления параметра --nobuffer,
  • 14) существенно исправлена основополагающая инструкция по настройке vpn в mandriva (http://code.google.com/p/vpnpptp/w/list),
  • 15) ведение базы знаний программы в файле /opt/vpnpptp/hosts о всех ip-адресах vpn-сервера - база знаний ведется и модулем vpnpptp, и модулем ponoff (при выборе опции программного добавления маршрута к vpn-серверу),
  • 16) скрипты /etc/ppp/ip-up.d/ip-up и /etc/ppp/ip-down.d/ip-down при выбранной опции программного добавления маршрута к vpn-серверу и при задании адреса vpn-сервера по имени теперь стали динамическими - модуль ponoff заносит в них новые, вновь открывшиеся ему маршруты о новых появившихся в базе знаний программы ip-адресах vpn-сервера, а также немедленно добавляет в таблицу маршрутизации новый, вновь открывшийся ему маршрут, если его в таблице маршрутизации еще нет,
  • 17) при переконфигурировании база знаний программы в файле /opt/vpnpptp/hosts о всех ip-адресах vpn-сервера пересоздается, так как исключительно редко, но в нее теоретически может попадать спам, это также необходимо при смене провайдера, у которого должна быть создана другая база знаний, или провайдер произвел изменения в сети,
  • 18) уменьшение времени дозвона по-умолчанию до 10 секунд и увеличение времени реконнекта по-умолчанию до 3 секунд,
  • 19) добавлены всплывающие балуны из трея для модуля ponoff: о процессе установления соединения, об установлении соединения, об обрыве соединения,
  • 20) ускорено появление иконки ponoff в трее при первом старте программы.

Примечания:

Адрес vpn-сервера может быть задан как по имени так и по IP. Конфигуратор анализирует этот адрес, и если адрес vpn-сервера задан по IP, то конфигуратор при выборе опции программного добавления маршрута к vpn-серверу добавляет маршрут к нему в скрипт /etc/ppp/ip-up.d/ip-up и в скрипт /etc/ppp/ip-up.d/ip-down, а иначе адрес vpn-сервера признается динамическим, так как имени vpn-сервера могут соответствовать несколько ip-адресов (или в частном случае один ip-адрес).

Для адреса vpn-сервера, заданного по имени, при выборе в конфигураторе опции программного добавления маршрута к vpn-серверу, модуль ponoff будет руководствоваться имеющейся (или созданной конфигуратором) базой знаний ip-адресов vpn-сервера - если она будет достаточна, то соединение установится, а если недостаточна, то база знаний дополнится. Если после дополнения базы знаний устанавливается соединение, то при следующем коннекте, если база знаний для нового соединения окажется недостаточной, то она дополнится и т. д. Таким образом, наступит момент, когда база знаний станет полная и соединение будет устанавливаться сразу. При этом не используются никакие иные зависимости пакетов, кроме тех, которые уже есть в системе.

При уже настроенной локальной сети VPN PPTP поднимается, если в этот момент известен маршрут к vpn-серверу или иначе не поднимается если маршрута нет. Но при уже поднятом VPN PPTP, если в таблице маршрутизации отсутствует маршрут к vpn-серверу, то соединение оборвется и по механизмам реконнекта восстановится вновь (или не восстановится если реконнект не выбран), при этом, естественно, интернета нет. И так циклически. Необходимый служебный маршрут к vpn-серверу при уже поднятом VPN PPTP у пользователей мог отсутствовать в таблице маршрутизации по разным причинам: по вине провайдера, неработающему в операционной системе dhclient, неработающему получению маршрутов через dhcp, несовпадением remote IP address, предоставленного vpn-сервером, с ip-адресом vpn-сервера, незанесением этого маршрута к vpn-серверу в поле ввода маршрутов в конфигураторе и т.д.

Если у Вас циклически рвущееся и самовосстанавливаемое по механизмам реконнекта соединение или неустанавливаемое соединение, и Вы хотите независимости конфигуратора vpnpptp от интерфейса управления ponoff, то задание адреса vpn-сервера по IP и выбор опции программного добавления маршрута к vpn-серверу решит эту задачу лучше всего.

Если у Вас адрес vpn-сервера задан по имени, и выбрана опция программного добавления маршрута к vpn-серверу в связи с необходимостью в этой опции, а алгоритм программного добавления маршрута к vpn-серверу не справляется со своей задачей или не устраивает, но очень необходимо программно добавлять маршрут к vpn-серверу, то решение этой задачи - указание IP vpn-сервера и выбор опции программного добавления маршрута к vpn-серверу или ручная маршрутизация через поле для ввода маршрутов в конфигураторе.

Ведение базы знаний программы о всех ip-адресах vpn-сервера ведется по двум методам: через host (из пакета bind-utils) или, в случае его отсутствия в системе, через ping. Первый метод хорош своей скорострельностью и предоставлением одного или нескольких сразу ip-адресов vpn-сервера за раз, второй метод - чуть менее быстрый и характеризуется предоставлением не более одного ip-адреса vpn-сервера за раз, и база знаний наполняется чуть медленнее. Но постепенно, начиная с какого-то момента база знаний уже наполнена всей необходимой информацией, и разница между этими двумя методами практически стирается (через ping только чуть дольше первый старт модуля ponoff). Модуль ponoff при каждом запуске, при каждом реконнекте, при каждом соединении наполняет базу знаний программы о всех ip-адресах vpn-сервера и чем дольше он сидит в трее, тем лучше. Уменьшение времени дозвона ускоряет наполнение базы знаний программы, ведь при каждом звонке модуль ponoff получает новую информацию об ip-адресах vpn-сервера. Необходимость ведения базы знаний программы о всех ip-адресах vpn-сервера связана с тем, что ни один из этих двух методов не дает полноценную информацию за один проход о всех ip-адресах vpn-сервера. База знаний программы о всех ip-адресах vpn-сервера, естественно, используется только если адрес vpn-сервера задан по имени, а описанные алгоритмы действуют только если выбрана опция программного добавления маршрута к vpn-серверу.

IX) Возможности версии 0.0.9

  • 1) в конфигураторе добавлена опция "Проверять vpn-сервер, шлюз локальной сети и интернет"; при выборе этой опции проверяется пинг vpn-сервера и шлюза локальной сети как при старте ponoff, так и при его работе, эта опция включена по умолчанию; систему она не нагружает, так как проверки выполняются только в моменты отсутствия соединения VPN PPTP по таймеру, и выполняется однократная проверка интернета при первом подключении (примечание: эта проверка согласована с программным добавлением маршрута к vpn-серверу, и vpn-сервер дважды не пингуется; эта проверка интернета основана на пинге yandex.ru),
  • 2) выводятся сообщения ponoff через балуны в трее: добавлены сообщения о получении маршрутов через dhcp, об обнаружении нового ip-адреса vpn-сервера, о том что не пингуется шлюз локальной сети, не пингуется vpn-сервер, о проблемах DNS, о том, что доступ в интернет есть или нет доступа в интернет,
  • 3) добавлена опция отключения всех балунов-сообщений ponoff в конфигураторе, по-умолчанию эта опция не включена, и балуны выводятся; выбор этой опции отключает опцию "Проверять vpn-сервер, шлюз локальной сети и интернет", так как она становится бессмысленной без вывода сообщений,
  • 4) добавлена проверка в конфигураторе присылает ли провайдер маршруты через dhcp, и если не присылает, то конфигуратор отказывает в этой опции, отменяя получение маршрутов через dhcp, - это облегчает работу ponoff, чтобы он впустую не получал того, чего нет,
  • 5) поправлено: конфигуратор не создавал файл /opt/vpnpptp/hosts при использовании метода ping для наполнения базы знаний программы обо всех ip-адресах vpn-сервера (примечание: для предыдущей версии программы просто создайте его сами),
  • 6) в конфигураторе при нажатии на кнопку <Создать подключение> теперь проверяется пинг vpn-сервера и шлюза локальной сети - о проблемах сообщается,
  • 7) в конфигураторе в строке состояния отражаются долгоиграющие происходящие процессы в момент создания подключения,
  • 8) улучшение в конфигураторе кнопочки проверки пинга vpn-сервера и определения его ip, которая теперь изменяется в соответствии с происходящими процессами,
  • 9) конфигуратор откажется настраивать получение маршрутов через dhcp если не установлен dhclient (пакет dhcp-client),
  • 10) в конфигураторе добавлена опция разрешения пользователям управлять соединением: конфигуратор при выборе этой опции проверяет наличие пакета sudo; если он не установлен, то предлагает его установить и не позволяет выбрать эту опцию до тех пор, пока пакет sudo не будет установлен; таким образом конфигуратор может быть запущен только под администратором, лишь с разрешения администратора пользователи получают возможность управлять соединением через модуль ponoff; также пакет sudo не является обязательным для программы как зависимость и устанавливается Вами самостоятельно в случае необходимости - такой принцип был принят и в предыдущих версиях программы; по-умолчанию опция разрешения пользователям управлять соединением не включена - такой подход позволяет также при настройке под администратором выйти в интернет и установить из репозиториев пакет sudo, если он не установлен, и после этого разрешить пользователям управлять соединением,
  • 11) при старте ponoff (а в последствии контроль) добавлено определение текущего шлюза, и если вообще нет никакого дефолтного шлюза, то перезапускается сетевой интерфейс, на котором настроено VPN PPTP - это полезно если настроенный для VPN PPTP сетевой интерфейс недефолтный, то он станет дефолтным при условии, что он работоспособен, также это полезно, например, если убить самому в процессах ponoff, который уже поднял VPN PPTP, или, например, если запустить ponoff при уже поднятом VPN PPTP, то ponoff убьет этот VPN PPTP - тогда может не быть никакого дефолтного шлюза и при массе других вариантов, потому что такое событие в операционной системе бывает, теперь оно правильно обрабатывается программой,
  • 12) в ponoff добавлена проверка на то перевелся ли дефолтный шлюз на поднятый интерфейс pppN - такое бывает при глюках со скриптами из пакета pptp-linux, а также если появился интерфейс не ppp0, а pppN, где N>=1, так как в скрипте поднятия ip-up явно указан именно ppp0 - в этих случаях ponoff сам создаст необходимый дефолтный шлюз на реально появившемся новом сетевом интерфейсе pppN, где N>=0,
  • 13) вызов конфигуратора vpnpptp добавлен в центр управления мандривы; vpnpptp и ponoff добавлены в /usr/bin,
  • 14) изменен порядок вызова dhclient и обработка новых ip-адресов vpn-сервера - сначала вызывается dhclient,
  • 15) ранее был постоянный вызов dhclient по таймеру если соединение pppN никак не устанавливалось, сейчас же вызов dhclient стал однократный при старте программы, а также после падения уже поднятого pppN, если вызов dhclient вновь необходим, - такой подход был особенно необходим тем, кто хочет и может получать маршруты через dhcp, но одновременно необходим программный механизм добавления маршрутов к vpn-серверу, теперь это учтено,
  • 16) поправлен и оптимизирован алгоритм получения новых ip-адресов vpn-сервера - в итоге база знаний ведется точнее, оптимизация коснулась и других фрагментов кода.

Примечание:

Для того, чтобы конфигуратор проверил техническую возможность получения маршрутов через dhcp, то при первом старте обновленного конфигуратора надо отменить получение маршрутов через dhcp, а при повторном старте конфигуратора - выбрать.

X) Возможности версии 0.1.0

  • 1) оптимизирован и улучшен алгоритм программной маршрутизации vpn-сервера для случая когда remote ip adress совпадает с ip-адресом самого vpn-сервера,
  • 2) в конфигураторе добавлена опция разрешения пользователям конфигурировать соединение, которую можно будет выбрать если установлен пакет sudo, иначе будет предложено его установить, и до тех пор пока пакет sudo не будет установлен, эту опцию выбрать будет нельзя; конфигуратор реагирует на установку пакета sudo немедленно и не требует перезапуска конфигуратора,
  • 3) переделан алгоритм работы с /etc/sudoers,
  • 4) при выборе в конфигураторе опции разрешения пользователям управлять соединением разрешен запуск ponoff без пароля не только через иконку на рабочем столе, но и через меню запуска приложений,
  • 5) в конфигураторе добавлена опция автозапуска интернета при старте системы в графике, которую можно будет выбрать если установлен пакет sudo аналогично п.2 (см. выше), а также при одновременном выборе опции разрешения пользователям управлять подключением; эта возможность реализована через помещение ярлыка ponoff в ~/.config/autostart,
  • 6) в конфигураторе добавлена опция автозапуска интернета при старте системы демоном pppd; при выборе этой опции настраивается файл /etc/rc.d/rc.local; при выборе этой возможности также будет настроено через /etc/rc.d/rc.local получение маршрутов через dhcp (если оно будет выбрано), а также будет предложено воспользоваться опцией реализации реконнекта, встроенным в демон pppd методом,
  • 7) опция автозапуска интернета при старте системы в графике и опция автозапуска интернета при старте системы демоном pppd являются взаимоисключающими, конфигуратор это проверяет и корректирует,
  • 8) в конфигураторе добавлена опция, позволяющая запустить VPN PPTP не как дефолтное, а в фоне; в этом режиме скрипт /etc/ppp/ip-up.d/ip-up создается пустым, кроме того модуль ponoff сам способен запустить VPN PPTP в фоне, если этого по каким-то причинам не произошло; в этом режиме интернет не проверяется,
  • 9) в конфигураторе добавлена проверка при старте наличия дефолтного шлюза и если его нет, то сеть перезапускается,
  • 10) установлены права chmod 600 на /opt/vpnpptp/config, так как изменение этого файла означает право на конфигурирование соединения.

Примечание:

Как только соединение ppp0 установилось есть возможность узнать remote ip adress и сравнить его с данными базы знаний программы обо всех ip-адресах vpn-сервера, и если remote ip adress совпадает с ip-адресом самого vpn-сервера, то корректируется скрипт /etc/ppp/ip-up, в который заносится строчка route add -host $5 gw шлюз_локальной сети dev сетевой_интерфейс, и после этого при всех последующих соединениях программная маршрутизация vpn-сервера считается выполненной, и соединение устанавливается мгновенно, а необходимость ведения базы знаний программы обо всех ip-адресах vpn-сервера для этого рассмотренного случая отпадает, и она удаляется модулем ponoff. При конфигурировании (переконфигурировании) считается, что remote ip adress не совпадает с ip-адресом самого vpn-сервера - и задача доказать иное возлагается на модуль ponoff в режиме программного добавления маршрута к vpn-серверу.

XI) Возможности версии 0.1.1

  • 1) если имеет место сетевой интерфейс wlanN, то по-умолчанию выставляется опция "Не контролировать state сетевого кабеля",
  • 2) внесена поправка на возможные ошибки получения маршрутов через dhcp, из-за того, что команда <dhclient сетевой_интерфейс> иногда у некоторых опускает сам сетевой интерфейс,
  • 3) опция программного добавления маршрута к vpn-серверу теперь включена по-умолчанию, так как она универсальна для всех провайдеров, к тому же ненадобность в ней проверяется программой всего за несколько тактов путем выяснения совпадения remote ip address с ip-адресом самого vpn-сервера,
  • 4) в конфигураторе добавлена кнопка "Дополнительно", при нажатии на которую вызываются опции демона pppd, их можно менять, список опций был увеличен; по-умолчанию предлагаются оптимальные значения, которые и были предложены в ранних версиях программы, но в конфигураторе их нельзя было ни изменять, ни добавлять; эти опции сохраняются в провайдерском файле настроек /etc/ppp/peers/имя_соединения, оттуда же и восстанавливаются при переконфигурировании соединения,
  • 5) поправил отображение поля для ввода маршрутов привязкой - поломал в предыдущих версиях,
  • 6) вызов конфигуратора возможен из Центра Управления Mandriva -> Сеть и Интернет -> Настройка VPN-соединений -> MS VPN (PPTP).

XII) Возможности версии 0.1.2

  • 1) в конфигураторе добавлены два поля: DNS1 до поднятия vpn и DNS2 до поднятия vpn - это dns, которые определяются автоматически из файла /etc/resolv.conf (это есть dns, полученные от DHCP-сервера или вручную указанные в настройках сетевого интерфейса); в конфигураторе эти DNS1 до поднятия vpn, DNS2 до поднятия vpn пока нельзя менять; смысл этих DNS1 до поднятия vpn и DNS2 до поднятия vpn следующий: они используются для поднятия vpn, они предоставляют ip-адрес vpn-сервера если он задан по имени, это локальные dns провайдера, то есть по умолчанию они доступны через локальную сеть, при поднятом vpn эти dns нами не используются, но они могут совпадать с DNS1 при поднятом vpn и/или DNS2 при поднятом vpn,
  • 2) в конфигураторе добавлены еще два поля: DNS1 при поднятом vpn и DNS2 при поднятом vpn - это dns, которые будут использоваться при поднятом vpn если не была выбрана опция usepeerdns в опциях демона pppd, или если была выбрана опция usepeerdns в опциях демона pppd, но vpn-сервер не предоставил никаких других dns; в конфигураторе эти DNS1 при поднятом vpn, DNS2 при поднятом vpn можно менять, и это не отразится на файле /etc/resolv.conf; смысл этих DNS1 при поднятом vpn и DNS2 при поднятом vpn следующий: если не была выбрана опция usepeerdns демона pppd, то на этих DNS1 при поднятом vpn, DNS2 при поднятом vpn поднимается интерфейс pppN (или если опция usepeerdns демона pppd была выбрана, но vpn-сервер не предоставил dns, то на этих DNS1 при поднятом vpn, DNS2 при поднятом vpn поднимается интерфейс pppN), соответственно при выборе опции usepeerdns демона pppd эти DNS1 при поднятом vpn, DNS2 при поднятом vpn использоваться не будут лишь в случае если vpn-сервер предоставит свои dns;
  • 3) DNS1 до поднятия vpn и DNS2 до поднятия vpn сохраняются в файле /opt/vpnpptp/config (также сохраняется и дополнительное DNS3 до поднятия vpn); DNS1 при поднятом vpn и DNS2 при поднятом vpn тоже сохраняются в файле /opt/vpnpptp/config,
  • 4) в конфигураторе добавлена опция, позволяющая программно маршрутизировать dns - при выборе этой опции конфигуратор добавляет маршруты к DNS1 до поднятия vpn, DNS2 до поднятия vpn в шлюз локальной сети если не была выбрана опция запуска VPN PPTP в фоне, а если была выбрана опция запуска VPN PPTP в фоне, то DNS1 до поднятия vpn и DNS2 до поднятия vpn не маршрутизируются, а DNS1 при поднятом vpn и DNS2 при поднятом vpn маршрутизируются в шлюз, предоставленный vpn-сервером; при выборе этой опции если (DNS1 до поднятия vpn или DNS2 до поднятия vpn) совпадает с (DNS1 при поднятом vpn или DNS2 при поднятом vpn), то есть имеет место маршрутизация локального dns в шлюз локальной сети, то скорость открытия сайтов у многих пользователей увеличится; конфигуратор считает локальными лишь максимум 2 первых dns из файла /etc/resolv.conf, которые и определяются автоматически конфигуратором как DNS1 до поднятия vpn, DNS2 до поднятия vpn; то есть эта опция либо полезна (так как позволяет маршрутизировать локальные dns в шлюз локальной сети, а также маршрутизирует dns для работы с VPN PPTP в фоне посредством скриптов поднятия и опускания с использованием переменных в этих скриптах), либо бесполезна, но не вредна,
  • 5) при выходе из ponoff при аварии и без аварии состояние настройки DNS-серверов возвращается к состоянию до поднятия vpn при любом исходе, так как модуль ponoff сохраняет текущее состояние dns при старте и возвращает его обратно при выходе,
  • 6) немного поправлен механизм работы с sudo для случая обновления версий программы с vpnpptp-0.1.1 на более новую версию,
  • 7) немного поправлен выход при аварии для опции встроенного в демон pppd реконнекта,
  • 8) в конфигураторе теперь имеется опция проверки пинга DNS-сервера, и модуль ponoff при выборе этой опции будет проверять пинг DNS-серверов, выводя сообщения о проблеме, но в этой части программа еще не написана, поэтому пока модуль ponoff ничего проверять не будет,
  • 9) конфигуратор при конфигурировании соединения теперь проверяет пинг DNS1 до поднятия vpn, DNS2 до поднятия vpn, о проблемах сообщается - таким образом проверяется техническая возможность поднятия vpn,
  • 10) при старте конфигуратора теперь всегда перезапускается сеть, если не поднят pppN (а не только если нет дефолтного шлюза как было раньше) - это позволяет устранить целый ряд помех и ошибок при конфигурировании, так как многие параметры конфигуратор определяет автоматически на основе текущего состояния сети,
  • 11) подмена /etc/resolv.conf и возможность задания произвольных dns серверов при поднятом pppN основана на особенностях демона pppd, который либо создает файл /var/run/ppp/resolv.conf, либо не создает - конфигуратор заносит в этот файл свои DNS1 при поднятом vpn, DNS2 при поднятом vpn (а также дополнительное DNS3 до поднятия vpn и все остальное, что идет далее в файле /etc/resolv.conf), и они либо изменяются демоном pppd, либо нет, что нам и нужно,
  • 12) если была выбрана опция usepeerdns демона pppd, то файл /etc/resolv.conf изменяется скриптами /etc/ppp/ip-up.d/ip-up и /etc/ppp/ip-down.d/ip-down, используя файл /var/run/ppp/resolv.conf - в итоге при поднятом vpn-соединении адреса DNS-серверов, полученных от vpn-сервера становятся приоритетными; если не была выбрана опция usepeerdns демона pppd, то файл /etc/resolv.conf также изменяется скриптами /etc/ppp/ip-up.d/ip-up и /etc/ppp/ip-down.d/ip-down аналогично - в итоге при поднятом vpn-соединении становятся приоритетными DNS1 при поднятом vpn, DNS2 при поднятом vpn, заданные в конфигураторе,
  • 13) возможность использования детских dns при поднятом vpn - они прямым текстом рекомендуются конфигуратором, чтобы их ввели,
  • 14) самое главное - бесполезная ранее опция usepeerdns стала полезной, она сама по себе бесполезна до тех пор, пока программист не решит иначе,
  • 15) в скрипте /etc/ppp/ip-up.d/ip-up строка /sbin/route add default dev ppp0 заменена на более универсальную строку /sbin/route add default dev $PPP_IFACE,
  • 16) программа теперь работает с переменными в скриптах /etc/ppp/ip-up.d/ip-up, /etc/ppp/ip-down.d/ip-down, и это позволяет наиболее полно использовать информацию, поступающую от демона pppd, без необходимости задумываться об этой информации, и это позволяет увеличить точность алгоритма, а местами упростить сам код,
  • 17) в конфигураторе добавлена кнопка, позволяющая скрывать и показывать пароль; по умолчанию пароль не показывается,
  • 18) в конфигураторе добавлена кнопка Справка, вызывающая справку в картинках в формате doc.

Примечания:

Принято допущение при программной маршрутизации DNS1 до поднятия vpn и/или DNS2 до поднятия vpn в шлюз локальной сети, что настраиваемый провайдер имеет либо DNS1 до поднятия vpn, либо (DNS1 до поднятия vpn и DNS2 до поднятия vpn), однако то, что мы считаем DNS2 до поднятия vpn настраиваемого провайдера может принадлежать другому провайдеру, а наш провайдер может иметь лишь только одно DNS1 до поднятия vpn. Такое допущение допустимо, так как маршрутизация DNS-серверов действует лишь в период выхода в сеть через настроенное соединение, и эти маршруты убираются из таблицы маршрутизации как только пользователь выйдет из интернета, и таким образом это допущение практически не скажется на другом провайдере. К тому же конфигуратор позволяет не выбирать опцию программной маршрутизации DNS-серверов, и есть возможность в поле для ввода маршрутов для этого случая задать самостоятельно лишь маршрут DNS1-сервера до поднятия vpn в шлюз локальной сети, а также можно воспользоваться опцией usepeerdns демона pppd, поэтому принятое допущение допустимо для всех существующих провайдеров и их сочетаний.

Как следствие, исправлены недостатки работы операционной системы с dns-серверами - сейчас программа при поднятом pppN жестко привязана к введенным в конфигураторе DNS1 при поднятом vpn и DNS2 при поднятом vpn или при поднятом vpn реально использует dns-сервера, полученные от vpn-сервера, а потому ей все равно когда операционная система некорректно с ними работает - у программы теперь своя собственная реализация работы с /etc/resolv.conf.

Как следствие, если не была выбрана опция usepeerdns демона pppd (или была выбрана, но vpn-сервер не предоставил своих dns), то в конфигураторе можно задать в частности DNS1 при поднятом vpn:81.176.72.82, DNS2 при поднятом vpn:81.176.72.83 (http://netpolice.ru/filters/dns-filter/connect/) и таким образом все запросы к Интернет-ресурсам автоматически будут обрабатываться фильтром.

XIII) Возможности версии 0.1.3

  • 1) исключена проверка на то, перевелся ли текущий интерфейс на pppN, где N>=1 для случая если появился интерфейс не ppp0 - этим уже занимается скрипт поднятия; вместо этой проверки добавлена проверка на то перевелся ли вообще интерфейс на pppN, где N>=0 и если нет, то модуль ponoff сам переводит pppN из фона и постоянно контролирует эту ситуацию,
  • 2) кнопка <Справка> отображается неактивной в случае если вывод справки невозможен,
  • 3) опция "Проверять vpn-сервер, dns-сервер, шлюз локальной сети и интернет" по умолчанию отключена,
  • 4) обеспечена совместимость перехода с версии vpnpptp-allde на vpnpptp-kde-one и с версии vpnpptp-kde-one на vpnpptp-allde через spec-файл,
  • 5) при старте ponoff а также в момент его работы если сетевой интерфейс для поднятия vpn недоступен (неактивен), то делается попытка поднять его - этим продолжена идея поднятия vpn из любого текущего состояния сети и обеспечен контроль сетевого интерфейса, к которому привязано vpn,
  • 6) отслеживается факт невыполнения демоном pppd скриптов поднятия/опускания, и тогда в провайдерский файл настроек добавляется строка welcome /etc/ppp/ip-up.d/ip-up - это последствие происходит в связи с применением различных скриптов настройки типа скриптов Корбины, которые не думая затирают важнейшие файлы /etc/ppp/ip-up и /etc/ppp/ip-down; тем не менее не гарантируется нормальная работа программы после применения такого рода скриптов,
  • 7) внесены поправки на одновременную работы программы с NetworkManager,
  • 8) обрабатывается событие падения vpn при использовании dns, отличных от стартовых, - при новом поднятии vpn dns становятся стартовыми,
  • 9) внесена поправка для mandriva 2010.1 на работу справочной системы программы,
  • 10) опции аутентификации и шифрования mppe переписаны; теперь чтобы задать шифрование require-mppe-128, которое в мандриве не поддерживается, необходимо выбрать опции no40 и no56 (но не выбирая опцию no128), часто в сочетании с опциями required и stateless (протестировано на провайдере "ТВОЙнэт", www.tvoynet.ru),
  • 11) в конфигураторе возвращен механизм самостоятельного рестарта сети при старте конфигуратора лишь в случае если нет дефолтного шлюза, а также в конфигураторе добавлена кнопка принудительного рестарта сети по моему алгоритму, так как системный рестарт не всегда устраивает.

XIV) Возможности версии 0.1.4

  • 1) добавлена поддержка протокола VPN L2TP без IPSec, конфигуратор откажется конфигурировать соединение по этому протоколу если не установлен пакет xl2tpd, конфигуратор просто не позволит выбрать эту опцию,
  • 2) теперь файл секретов /etc/ppp/chap-secrets очищается с сохранением резервной копии, этот файл секретов не используется ни при выборе опции VPN PPTP, ни при выборе опции VPN L2TP,
  • 3) по умолчанию для нового имени соединения или первого созданного теперь включены опции демона pppd: nopcomp и noaccomp,
  • 4) при выборе опции VPN L2TP за аутентификацию отвечает демон pppd; демон xl2tpd не передает демону pppd никаких параметров, более того в /etc/xl2tpd/xl2tpd.conf отсылает к pppoptfile = /etc/ppp/peers/имя_соединения, что позволяет упростить настройку соединения VPN L2TP поверх VPN PPTP, не используя файл /etc/ppp/options.l2tp, и он создается пустым с сохранением резервной копии,
  • 5) реконнект встроенным в демон xl2tpd методом реализован, но по факту может не работать,
  • 6) отказ от изменения скрипта /etc/ppp/ip-up для случая совпадения remote IP adress vpn-сервера с ip-адресом самого vpn-сервера - в этом случае теперь изменяются скрипты /etc/ppp/ip-up.d/ip-up и /etc/ppp/ip-down.d/ip-down с занесением в них маршрута к $PPP_REMOTE, то есть используется переменная для задания маршрута,
  • 7) в конфигураторе опции для VPN PPTP и VPN L2TP динамические и зависят от выбора пользователя из этих типов vpn,
  • 8) при выборе опции встроенного в демон pppd реконнекта теперь используется время дозвона - это параметр holdoff в провайдерском файле настроек,
  • 9) учитывается, что для VPN L2TP значение mtu меньше, чем для VPN PPTP,
  • 10) при выборе опции VPN L2TP шифрование mppe отключается и становится неактивным, запрещенным к выбору,
  • 11) в зависимости добавлен пакет xl2tpd,
  • 12) файл /etc/ppp/options.pptp более не трогается,
  • 13) добавлено поле для ввода mru.

Примечание:

При переконфигурировании введите другое имя соединения или выберите опции демона pppd по кнопке <Дополнительно> - noaccomp, nopcomp.

XV) Возможности версии 0.1.5

  • 1) норма mtu для VPN L2TP принята 1460 байт вместо 1400 байт,
  • 2) убрана зависимость mru и mtu друг от друга,
  • 3) запрет конфигурирования соединения при поднятом VPN PPTP/L2TP: пользователю предлагается на выбор либо выйти из конфигуратора, либо продолжить, убив VPN PPTP/L2TP и перезапустив сеть,
  • 4) добавлена проверка используется ли пакет xl2tpd из репозитория EduMandriva, и если он использутся из другого репозитория, то встроенный в демон xl2tpd механизм реконнекта нельзя будет выбрать,
  • 5) в конфигураторе добавлена кпопка "Тестовый запуск", при нажатии на которую происходит тестовое установление соединения VPN PPTP/L2TP, при котором логи отображаются в удобном виде; предусмотрен тестовый запуск в графике и без графики (при выходе из конфигуратора соединение VPN PPTP/L2TP остается установленным),
  • 6) так как фактически часто используется пакет vpnpptp-kde-one в разных DE, то в программу внесены дополнительные подсказки, возникающие контекстно, о том как пользоваться программой, делающие возможным использование пакета vpnpptp-kde-one в разных DE, так как, в частности, вполне возможно конфигурировать соединение из Центра Управления, а запускать сконфигурированное соединение под пользователем, предварительно разрешив пользователям управлять подключением в конфигураторе (модуль ponoff теперь можно запустить также через "Тестовый запуск" в конфигураторе),
  • 7) опция ведения логов теперь включена по-умолчанию, ведение логов немного поправлено,
  • 8) так как в дистрибутиве MagOS DNS1 до поднятия VPN принято 127.0.0.1, но ввиду возможной системной ошибки в операционной системе, связанной с исчезновением интерфейса lo, были внесены поправки как в модуль vpnpptp, так и в модуль ponoff - теперь программа будет делать всё возможное, чтобы интерфейс lo всегда существовал,
  • 9) внесены поправки в конфигураторе в отображение строки состояния.

XVI) Возможности версии 0.1.6

  • 1) добавлена поддержка виртуальной машины VMWare, в связи с чем были внесены поправки: так как на виртуальной машине при настройках по-умолчанию не приходят ниоткуда никакие маршруты, ни через dhcp, ни от vpn-сервера, поэтому и соединение с vpn-сервером, заданным по имени, не всегда устанавливается с первого раза (если у vpn-сервера более одного ip-адреса), так как в базе знаний программы еще может не быть сведений об ip-адресе vpn-сервера, с которым установилось соединение, поэтому может не быть и маршрута к нему, не работает контроль state сетевого кабеля на виртуальном сетевом адаптере, то это всё было обработано в программе более корректно,
  • 2) добавлена поддержка дистрибутива PCLinuxOS, в связи с чем были внесены поправки: так как в PCLinuxOS опция usepeerdns по-умолчанию использовалась таким образом, что dns, полученные от vpn-сервера, становились при поднятом vpn-соединении приоритетными сами, то поправки приводят PCLinuxOS к тому, как сеть в этой части реализована в Mandriva, также в PCLinuxOS по-умолчанию не настроен автозапуск для пользователей, поправка настраивает его, и, следовательно, в PCLinuxOS перешел весь уже реализованный функционал программы,
  • 3) пакет xl2tpd был также пересобран и для PCLinuxOS для реализации встроенного в демон xl2tpd механизма реконнекта; всем пакетам для PCLinuxOS был присвоен суффикс edmpclos,
  • 4) в индикацию ponoff в трее добавлена информация о типе установленного соединения - VPN PPTP или VPN L2TP, а также улучшена индикация для выхода без аварии и для выхода при аварии,
  • 5) исправлен английский перевод и правильное отображение его на экране, которое поломалось в предыдущих версиях из-за получающихся более коротких фраз при переводе с русского на английский,
  • 6) ведение логов переписано, продолжена идея вынесения логов в отдельные логи: лог для xl2tpd ведется теперь в /var/log/xl2tpd.log, отказ от использования скрипта pppdlog, реализована отмена ведения логов, отказ от одновременного ведения логов pppd и xl2tpd, так как они оказываются идентичными,
  • 7) добавлена обработка события когда модуль ponoff уже убил VPN PPTP/L2TP, но еще не завершил свою работу и в этот момент произошел запуск конфигуратора vpnpptp - в этом случае будет выведено информационное сообщение и отказано в запуске конфигуратора,
  • 8) учтено при создании ярлыка подключения на Рабочем столе, что Рабочий стол в любой локали может называться "Desktop", что считается нормальным явлением в PCLinuxOS,
  • 9) отказ от очистки конфигуратором файла /etc/ppp/chap-secrets, так как его содержимое, даже если оно неверное, не влияет на соединение - продолжение идеи изменения как можно меньшего числа файлов системы.

XVII) Возможности версии 0.1.7

  • 1) индикация ponoff в трее при наведении мышкой оформлена по аналогии с NetApplet, добавлена информация о скорости закачки/отдачи, о времени, прошедшем с момента установления соединения, об объеме загруженного и отданного с момента установления соединения (счетчик работает до 4Gib, если объем больше, то более не считается и выводится ">4Gib") - вся эта информация при обрыве обнуляется, и, таким образом, можно легко выяснить насколько стабильно работает соединение,
  • 2) имя соединения может содержать в себе лишь латинские буквы (маленькие и заглавные) и цифры, но имя соединения не может начинаться с цифры, все остальные символы недопустимы; прежний механизм, позволяющий недокументированно следом за именем соединения в поле имени соединения через пробел указывать дополнительные параметры для pppd, таким образом отменен,
  • 3) внесена поправка для Edumandriva LXDE для работы файла справки с приложением openoffice.org*, а не только с приложением oowriter*,
  • 4) добавлена опция, позволяющая лучше маршрутизировать vpn-сервера, заданные по имени, и быстрее устанавливать соединение если vpn-серверов много, путем использования файла /etc/hosts; эта опция включена по-умолчанию, и работает как через команду ping, так и через команду host (приоритетно), поэтому наличие в системе пакета bind-utils необязательно, но конфигуратор рекомендует,
  • 5) добавлена опция default-mru в дополнительных опциях демона pppd,
  • 6) встроенный MessageBox полностью заменен - это позволило использовать кнопки в соответствии с языком, использовать любой шрифт, в том числе отличный от системного, придерживаться единообразного интерфейса проекта и др.,
  • 7) ревизия кода, переводов.

Примечание:

Если у vpn-сервера много ip-адресов, и он задан по имени, то потребуется время прежде чем удастся получить их все, занести в базу знаний программы, маршрутизировать их. При таком подходе бывает ситуация когда соединение установилось, но установилось с таким ip-адресом vpn-сервера, которого еще нет в базе знаний программы, следовательно, так как не будет маршрута к нему, то соединение само разорвется, а перебор и пополнение базы знаний программы продолжится после разрыва. Но такой подход может быть достаточно долгим несмотря на то, что стабильное соединение в конечном итоге все же установится, а при следующем запуске соединения времени потребуется все меньше, так как база знаний уже будет более-менее наполнена. Если в таблице маршрутизации нет вообще никаких маршрутов, например, провайдер не присылает или работа на виртуальной машине, то времени может потребоваться еще больше на такой классический подход. Задачу можно решить программно так, чтобы никогда не существовало неизвестного ip-адреса vpn-сервера, соединялось только с известными ip-адресами - этого удалось достичь, используя файл /etc/hosts, в который модулем ponoff заносятся ip-адреса vpn-сервера. Но так как у файла /etc/hosts есть особенность - сколько бы записей в нем не было об одном и том же имени, то берется первая, остальные игнорируются, то в целях регулирования нагрузки на vpn-сервера провайдера файл /etc/hosts используется модулем ponoff динамически. При совпадении remote IP address с ip-адресом самого vpn-сервера необходимость в дальнейшем использовании файла /etc/hosts отпадает, и он очищается от сделанных записей, а vpn-сервер становится постоянно маршрутизированным. При таком подходе соединение всегда устанавливается мгновенно с первого раза. Механизм использования файла /etc/hosts - это дополнительный опциональный механизм к уже существующей программной маршрутизации vpn-сервера, и он не существует отдельно от нее.

XVIII) Возможности версии 0.1.8

  • 1) при двойном запуске ponoff трей 2-го экземпляра программы работал ранее некорректно - исправлено,
  • 2) исправлен обход по Tab в конфигураторе,
  • 3) добавлена защита от отсутствия некоторых необходимых файлов в директории /opt/vpnpptp,
  • 4) поправлена иконка в трее до 22*22 пикселей вместо 24*24,
  • 5) ошибка получения маршрутов через DHCP в модуле ponoff теперь возникает только после повторной проверки через 3 сек, учитывая возможную инертность сети,
  • 6) по умолчанию на виртуальной машине VmWare отключается получение маршрутов через DHCP,
  • 7) сообщения теперь визуально объемнее, так как на некоторых темах отображались притемненными и утопленными,
  • 8) вся справочная информация в конфигураторе вынесена во всплывающие подсказки-хинты, шрифт которых сам меняется при масштабировании формы и соответствует шрифту программы,
  • 9) отказ при запуске ponoff от убирания формы в отрицательные координаты, так как на Compiz Fusion это иногда поворачивает куб на другую грань куба, перепрятал ее по другому,
  • 10) из зависимостей сборки убран upx, убран compile.sh.

XIX) Возможности версии 0.1.9

  • 1) продолжена интеграция программы в сетевые инструменты мандривы и ее аналогов: конфигуратор настраивает ведение статистики для $PPP_IFACE через скрипт поднятия, модуль ponoff по таймеру способствует более быстрому обновлению статистики, чем системное по-умолчанию 5 минут, а также выводит ее на экран, вызывая net_monitor - при нажатии правой кнопки в трее на значке ponoff в меню добавлен пункт "Наблюдать", который активен лишь если такое наблюдение возможно; не в мандриве, не в ее аналогах этот пункт не появляется, а статистика не ведется,
  • 2) добавлена поддержка дистрибутива Ubuntu, программа определяет факт запуска в Ubuntu (в общем случае если не один из поддерживаемых проектом дистрибутивов не отзовется, то будет признана мандрива или ее аналоги),
  • 3) в Ubuntu используется собственная реализация работы с usepeerdns - я принял ее как есть, так как она вписывается в проект как один из допустимых вариантов такой реализации с незначительными поправками, которые эту реализацию лишь расширяют, позволяя использовать только для ponoff при поднятом VPN PPTP/L2TP любые DNS и не действуя сделанными поправками на Network-Manager и его работу с сетью, который не будет использовать DNS, настроенные конфигуратором vpnpptp и модулем ponoff,
  • 4) настроена одновременная работа с Network-Manager: Network-Manager не трогает ни при каких обстоятельствах соединение, поднятое модулем ponoff, а модуль ponoff имеет право убить соединение VPN, поднятое Network-Manager'ом, и установить свое; так как конфигуратор создает скриты поднимания и опускания, то они используются и Network-Manager'ом при установлении соединения, нисколько не влияя на соединение, установленное Network-Manager'ом, так как их смысл соответствует природе работы Network-Manager'а с VPN, маршрутизация в этих скриптах поднятия и опускания годится и для Network-Manager; использование модулем ponoff любых DNS, реализованных через скрипты поднятия и опускания не влияет на Network-Manager, так как он используется свои DNS уже после выполнения этих скриптов; дополнительные маршруты, написанные в конфигураторе, следовательно будут выполняться и Network-Manager'ом при установлении соединения VPN - таким образом удалось достичь взаимной полной совместимости и при этом достаточной независимости друг от друга,
  • 5) исправлено отображение иконки ponoff на Рабочем столе в GNOME, связанное с chown и с общими правилами расположения таких иконок в директории /usr/share/pixmaps,
  • 6) опция autodial = yes для настройки VPN L2TP теперь используется только при выборе опции автозапуска интернета при старте системы демоном xl2tpd (без графики), в остальных случаях модуль ponoff сам дает команду демону xl2tpd для дозвона, так как для Ubuntu указание опции autodial = yes является достаточным для установления соединения VPN L2TP сразу при старте системы без необходимости иной настройки автозапуска демоном xl2tpd (без графики),
  • 7) для Ubuntu: подробные логи будут вестись в /var/log/syslog, тестовый запуск сконфигурированного соединения временно отключен, конфигуратор откажется настраивать файервол shorewall по причине его отсутствия, конфигуратор откажется настраивать получение маршрутов через DHCP, так как оно уже настроено в дистрибутиве, также отсутствует /etc/rc.d/rc.local,
  • 8) автозапуск интернета при старте системы демоном pppd (без графики) реализовывается через /etc/rc.local, если отсутствует /etc/rc.d/rc.local,
  • 9) за счет отката на шаг назад реализации всплывающих сообщений-балунов из трея удалось достичь более легкого и быстрого установления соединения,
  • 10) специфично при работе программы с NetworkManager?'ом, что при опускании pppN пропадает дефолтный шлюз, и скрипт опускания не способен его вернуть, поэтому при выходе при аварии рестарт сети решает эту задачу, а при выходе без аварии для работы с NetworkManager?'ом предусмотрено создание дефолтного маршрута модулем ponoff, если он отсутствует, аналогично при старте ponoff тоже проверяется наличие дефолтного шлюза и происходит его создание при необходимости - это было и ранее, но сейчас эти алгоритмы были многократно усилены,
  • 11) при портировании программы на Ubuntu были выявлены и исправлены неизвестные ранее недостатки и баги, что безусловно положительно сказалось на работе программы во всех поддерживаемых ею дистрибутивах.

Примечания:

В Ubuntu перешел весь важнейший функционал, достаточный для настройки и выхода в интернет через VPN PPTP/L2TP (кроме тестового запуска и раздельного ведения логов). Ubuntu облегчает задачу получения маршрутов через DHCP, они быстрее получаются средствами дистрибутива, они существуют еще до поднятия VPN, облегчает использование usepeerdns, облегчает настройку файервола, так как он просто не требует настройки для выхода в интернет через VPN PPTP/L2TP.

Тест программы проводился на виртуальной машине VmWare? в ubuntu-10.10-desktop-i386 при настройках сети NAT и Bridge.

XX) Возможности версии 0.2.0

  • 1) отменено раздельное ведение логов, ведется общий лог как то принято во всех дистрибутивах в /var/log/syslog,
  • 2) вопрос использования правильных DNS всегда при любых условиях (в том числе DNS всегда будут работать правильно если установить отсутствующий по-умолчанию в Ubuntu пакет resolvconf) если есть Network-Manager был решен рестартом Network-Manager'а: добавлен рестарт Network-Manager'а при выходе из ponoff без аварии если запуск ponoff происходил, а при этом соединение VPN уже было установлено неважно какой программой,
  • 3) в Ubuntu включен ранее отключенный тестовый запуск в конфигураторе,
  • 4) многократное выполнение скрипта опускания отменено, так как при повторном выполнении скрипта опускания эффекта нет никакого, кроме удаления еще одного default, если их более одного, вместо этого в скрипты поднятия и опускания внесены коррективы о необходимости удаления default многократно в зависимости от числа интерфейсов в системе, модуль ponoff тоже учитывает это обстоятельство; ошибочное понимание, написанное во всех инструкциях, того что default может быть только один, а команда route del default не оставит в системе ни одного default, отвергнуто согласно практическим фактам, которые показывают, что если в системе 2 default, то команда route del default оставит в системе оставшийся второй default, и на нем будет поднята сеть если еще нет интерфейса pppN, метрика же не влияет на этот факт вообще; то есть либо теория была неверна, либо в самом дистрибутиве баги от неверной реализации теории, но при любом исходе программа должна учитывать факты и работать верно с несколькими default, что и было сделано; для одного сетевого интерфейса всё осталось как и прежде - так как это частный случай рассматриваемой ситуации, поправки направлены лишь на работу с несколькими сетевыми интерфейсами.

Примечания:

В Ubuntu быстрее, чем в Mandriva и ее аналогах устанавливается соединение, быстрее рестарт сети, быстрее выход без аварии.

В Ubuntu вполне возможно настроить в Network-Manager сколько угодно соединений (или ни одного), в том числе и массу соединений VPN PPTP, а в конфигураторе vpnpptp может быть, к примеру настроено только VPN L2TP или более функциональный, чем встроенный в Network-Manager, VPN PPTP. При этом соединение, настроенное через vpnpptp, может быть запущено попеременно с настроенным в Network-Manager; при одновременном запуске Network-Manager имеет наименьший приоритет, поэтому его соединение будет убиваться модулем ponoff, а соединение, установленное модулем ponoff, Network-Manager не имеет права трогать вообще, и он сообщит о невозможности его установки, если ponoff уже установил свое соединение.

Так как NAT в VirtualBox не пропускает трафик GRE, необходимый для функционирования VPN PPTP, а для VPN L2TP фильтрация пакетов GRE не помеха, то пакет vpnpptp работает в VirtualBox при условии выбора VPN L2TP, однако, потребовалось в обязательном порядке указать MTU. В VirtualBox можно отказаться от NAT и поставить соединение типа мост.

Относительно многократного выполнения скриптов поднятия и опускания ip-up и ip-down. Допустим у нас один default. Допустим, что уже установлено соединение на интерфейсе pppN, и этот шлюз дефолтный, тогда команда route del default удалит этот дефолтный шлюз, но следующая команда route add default dev pppN тут же вернет его обратно. Допустим, что соединение на интерфейсе pppN уже опущено, и стал дефолтным шлюз локальной сети. Тогда команда route del default, удалит этот дефолтный шлюз локальной сети, но следующая команда route add default gw шлюз_локальной_сети тут же вернет его обратно. Повторное добавление в таблицу маршрутизации уже имеющихся там маршрутов, равно как и удаление из таблицы маршрутизации уже отсутствующих маршрутов будет иметь лишь нулевой эффект. Многократное выполнение сохранения текущего состояния /etc/resolv.conf и возврат к нему уже после второго подряд выполнения скрипта ip-up станет невозможным, но при этом скрипт ip-down может выполняться подряд сколько угодно раз без негативных последствий. Следовательно, многократное выполнение этих скриптов допустимо и безвредно при условии, что проект, разрешающий такое многократное их выполнение, справится с задачей использования DNS.

Фрагмент таблицы маршрутизации, в которой более одного default:

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ... link-local * 255.255.0.0 U 5 0 0 eth0 link-local * 255.255.0.0 U 10 0 0 eth1 default 10.213.72.1 0.0.0.0 UG 5 0 0 eth0 default ip1.net201.n37. 0.0.0.0 UG 10 0 0 eth1

или

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ... link-local * 255.255.0.0 U 1002 0 0 eth0 link-local * 255.255.0.0 U 1003 0 0 eth1 default ip1.net201.n37. 0.0.0.0 UG 0 0 0 eth1 default 10.213.72.1 0.0.0.0 UG 0 0 0 eth0

Таким образом, наличие нескольких default не зависит от метрики, факт наличия нескольких default не влияет на работоспособность сети, но мешает правильно обрабатывать поднятие и опускание VPN для нескольких сетевых интерфейсов (особенно в фоне), максимальное количество default равно числу интерфейсов, выводимых командой: ifconfig |grep eth & ifconfig |grep wlan.

Допустим, до поднятия VPN в системе было 2 default, при поднятии VPN кол-во default станет 2, включая pppN (можно достичь и цифры 3 при определенных настройках демона pppd, но этот аспект временно пропустим):

Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface ... default * 0.0.0.0 U 0 0 0 ppp0 default ip1.net201.n37. 0.0.0.0 UG 10 0 0 eth1

Через скрипт поднятия, выполняющийся при уже появившемся интерфейсе pppN, необходимо будет удалить 2 default и перевести дефолт на интерфейс pppN. У нас станет только один default, и это будет pppN, через скрипт опускания следовательно тогда достаточно удалить только один default и перевести дефолт на шлюз локальной сети, который вновь будет один default.

XXI) Возможности версии 0.2.1

  • 1) добавлена поддержка Debian,
  • 2) в Debian'е потребовалось явное указание опции logfile /var/log/syslog в провайдерском файле настроек, без этой опции при VPN L2TP логи pppd не попадали в /var/log/syslog, поэтому эта опция была добавлена для всех дистрибутивов как полезная и универсальная, если выбрано ведение логов,
  • 3) настройка сети в Debian'е сделана как в Mandriva с учетом общего и отличий: дефолтная настройка сети в части, требующейся для работы с VPN, очень похожа на Mandriva, кроме того, что вместо сервиса network используется сервис networking, а команда ifup не создает дефолтного шлюза на поднимаемом ею сетевом интерфейсе, если этот сетевой интерфейс уже поднят,
  • 4) в Debian'е не требуется настройка shorewall ввиду отсутствия, не требуется настройка получения маршрутов через DHCP, так как оно уже настроено в дистрибутиве и прекрасно работает, Network-Manager по-умолчанию не установлен, поэтому работа программы с Network-Manager в Debian'е не проверялась,
  • 5) в зависимости к пакетам для Debian добавлен пакет sysvconfig, так как без него не работает команда service, и возникают сложности управления сервисами,
  • 6) работа с usepeerdns реализована в Debian'е как в Ubuntu, поэтому и в программе работа с usepeerdns сделана так, как то уже было реализовано для Ubuntu,
  • 7) учтено, что в Debian'е команда gksu -u root -l <приложение> не работает, а работает команда gksu <приложение>,
  • 8) автозапуск интернета при старте системы демоном pppd(xl2tpd) сделан в Debian'е как в Ubuntu,
  • 9) тест интернета в Debian сразу после появления интерфейса pppN невозможен, так как скрипт поднятия /etc/ppp/ip-up.d/ip-up выполняется спустя примерно 30 секунд: перед проверкой интернета добавлена задержка в 30 секунд,
  • 10) в Debian'е выводится предупреждающий балун, что интернет появится лишь через 30 секунд после установления соединения, но при этом задержки не делается, кроме случая проверки интернета.

Примечания:

Тест проводился в debian-506-i386-CD-1 в виртуальной машине VmWare при настройках сети NAT. В Debian'е часто слишком много времени проходит между появлением интерфейса pppN и до выполнения скрипта /etc/ppp/ip-up.d/ip-up.

XXII) Возможности версии 0.2.2

  • 1) добавлена поддержка openSUSE,
  • 2) в openSUSE в скрипты директории /etc/ppp/ip-up.d/ и директории /etc/ppp/ip-down.d/ передаются переменные IFNAME вместо PPP_IFACE, IPREMOTE вместо PPP_REMOTE, вместо пакета pptp-linux используется пакет pptp, учтено,
  • 3) переписан алгоритм определения произошел ли запуск при поднятом VPN, так как ранее проверялось есть ли pppN и дефолтный ли он, то теперь проверяется лишь наличие pppN, так как он может и не быть дефолтным,
  • 4) в openSUSE встроенная в дистрибутив реализация работы с usepeerdns не устроила, так как полученные от VPN-сервера DNS1 при поднятом VPN, DNS2 при поднятом VPN имели низкий приоритет для не dsl-соединений, а наше VPN-соединение не является dsl-соединением, так как используется интерфейс pppN, а не dslN, поэтому я внес дополнения:

если дистрибутив openSUSE, то в скрипт /etc/ppp/ip-up.d/ip-up вписывается:

cp -f /var/run/ppp/resolv.conf.copy /var/run/ppp/resolv.conf #эта строчка вписывается только если не выбрана опция usepeerdns
if [ $USEPEERDNS = "1" ]
then
    [ -n "$DNS1" ] && rm -f /var/run/ppp/resolv.conf
    [ -n "$DNS2" ] && rm -f /var/run/ppp/resolv.conf
    [ -n "$DNS1" ] && echo "nameserver $DNS1" >> /var/run/ppp/resolv.conf
    [ -n "$DNS2" ] && echo "nameserver $DNS2" >> /var/run/ppp/resolv.conf
fi

потом уже следующими действиями файл /etc/resolv.conf заменяется файлом /var/run/ppp/resolv.conf с сохранением копии файла /etc/resolv.conf для возврата назад,

  • 5) в скрипт /etc/ppp/ip-down.d/ip-down для openSUSE независимо от выбора опции usepeerdns дописывается для возврата DNS до поднятия VPN:
netconfig update -f
if [ -a /etc/resolv.conf.netconfig ]
then
    cp -f /etc/resolv.conf.netconfig /etc/resolv.conf
    rm -f /etc/resolv.conf.netconfig
fi

Если в момент выполнения скрипта /etc/ppp/ip-down.d/ip-down окажется, что в файле /etc/resolv.conf произошли изменения нами, то команда netconfig update -f создаст файл /etc/resolv.conf.netconfig, которым нами будет заменен файл /etc/resolv.conf,

  • 6) ранее при старте конфигуратора проверялось наличие дефолтного шлюза, и если его не было, то исправлялось автоматически, но автоматическое исправление в самом конфигураторе не всегда возможно, что бывает для openSUSE, поэтому добавлена обработка ошибки автоматического создания дефолтного шлюза при старте конфигуратора, и выводятся советы пользователю по решению этой задачи - предлагается вручную указать сетевой интерфейс и шлюз локальной сети, а конфигуратор сам добавит необходимый дефолтный маршрут,
  • 7) получение маршрутов в openSUSE через DHCP уже реализовано в дистрибутиве,
  • 8) учитывая, что в дистрибутиве openSUSE не настроен корректный запуск графических программ, требующих административных привилегий, через sudo, а также то, что используется отличная от других дистрибутивов работа с sudo, то отключена опция разрешения пользователям конфигурировать соединение, отключена опция разрешения пользователям управлять соединением, с вытекающими последствиями из-за sudo - отключена и не разрешается к выбору опция автозапуска интернета при старте системы в графике,
  • 9) в openSUSE автозапуск демоном pppd(xl2tpd) без графики настраивается через /etc/init.d/after.local,
  • 10) в openSUSE конфигуратор vpnpptp откажется конфигурировать соединение, если будет обнаружено dsl-соединение, а модуль ponoff откажется устанавливать соединение если будет обнаружено dsl-соединение,
  • 11) в openSUSE вопрос использования любых DNS при поднятом VPN-соединении был решен специфически, иначе системой затирался бы файл /var/run/ppp/resolv.conf: при невыборе опции usepeerdns конфигуратор создает 2 идентичных файла /var/run/ppp/resolv.conf и /var/run/ppp/resolv.conf.copy - это позволяет модулю ponoff и модулю vpnpptp иметь свою собственную локальную реализацию работы с любыми DNS при поднятом соединении, в скрипт /etc/ppp/ip-up.d/ip-up добавляется: cp -f /var/run/ppp/resolv.conf.copy /var/run/ppp/resolv.conf, а у системы иметь другую глобальную реализацию работы с DNS, но заставляя систему использовать независимо от того dsl-соединение или нет приоритетно полученные от VPN-сервера DNS, что по сути правильно и необходимо если соединение с интернет реализовывается через демон pppd(xl2tpd) автозагрузкой при старте системы (или если не используется модуль ponoff для установления соединения),
  • 12) добавлена возможность изменять размер шрифта, так как дефолтные настройки не всегда достаточны для слабозрячих: на пустом месте в окне конфигуратора нажатие левой кнопки мыши увеличивает шрифт, нажатие правой кнопки мыши уменьшает шрифт, шрифт сохраняется и при последующем конфигурировании будет измененный, во всплывающий хинт добавлена информация об этом,
  • 13) добавлена поддержка дистрибутивов, родственных из числа поддерживаемых проектом - если дистрибутив не определился автоматически, то будет предложено его выбрать из выпадающего списка, если же дистрибутив определился, то выбор из списка будет запрещен во избежание шелудивых рук, так как неверный выбор многое собьет,
  • 14) исправлен ряд недочетов, ускорен выход без аварии за счет улучшенной процедуры создания дефолтного шлюза,
  • 15) если было введено хотя бы одно из детских DNS, то опция usepeerdns отключается автоматически, так как при этом имеются все разумные основания полагать желание пользователя настроить интернет для детей.

Примечания:

Тест проводился в openSUSE-11.3-DVD-i586 в виртуальной машине VmWare при настройках сети NAT и Bridge. Конфигуратор vpnpptp для openSUSE изменяет настройку сети на более прогрессивное и правильное использование DNS для любых VPN-соединений, а не только для dsl-соединений, по своей сути vpnpptp является дополнительным инструментом к встроенным в дистрибутив openSUSE средствам настройки VPN, но может использоваться и автономно, и в сочетании с qinternet, kinternet. После выполнения изменений с помощью vpnpptp встроенное в openSUSE VPN будет работать лишь лучше и функциональнее - в дистрибутив перейдут для использования все настройки, сделанные vpnpptp, причем настройки затрагивают лишь файлы /etc/ppp/ip-up.d/ip-up, /etc/ppp/ip-down.d/ip-down, и создается директория /var/run/ppp/, которая вне зависимости от ее существования никак не влияет на openSUSE. В openSUSE из-за политики дистрибутива был отключен некоторый второстепенный функционал программы, затрагивающий работу программы без пароля администратора, но отключенный функционал отключен временно и нисколько не мешает основной цели программы - настроить интернет и выйти в интернет.

XXIII) Возможности версии 0.2.3

  • 1) конфигуратор проверяет поддержку вызовов mii-tool сетевой картой, и в случае если она их не поддерживает, и еще не существует файл /opt/vpnpptp/config, то конфигуратор самостоятельно включает опцию "Не контролировать state сетевого кабеля",
  • 2) настроен многократный, ранее запрещенный, запуск модуля ponoff - новый запущенный экземпляр программы убивает предыдущий экземпляр, наследует все свойства и текущее состояние предыдущего экземпляра, после этого в процессах будет находиться лишь один модуль ponoff с pid нового экземпляра, то есть с точки зрения пользователя если многократно запускать ponoff, то визуально ничего не произойдет, изменится лишь pid и кратковременное пропадание иконки из трея и быстрое ее появление, но при этом будет корректно работать графический автозапуск интернета при старте системы при переключении между пользователями с таким автозапуском ponoff, а также вновь запущенный ponoff поудаляет, если вдруг таковые будут, подвисшие предыдущие экземпляры, посылая им сигнал kill -9,
  • 3) команда запуска sudo /opt/vpnpptp/ponoff изменена на xsudo /opt/vpnpptp/ponoff, команда запуска sudo /opt/vpnpptp/vpnpptp изменена на xsudo /opt/vpnpptp/vpnpptp; если не установлен пакет xsudo, то конфигуратор vpnpptp выполнит сам все действия, выполняемые пакетом xsudo,
  • 4) исправлено создание иконки на Рабочем столе,
  • 5) существенно улучшена работа программы с DNS, полный отказ от использования /etc/resolv.conf.old; смысл улучшений был основан на идее о том, что конфигуратор vpnpptp создает текущий снимок сети, и чтобы модуль ponoff наиболее полно руководствовался этим снимком сети; в этот снимок сети было добавлено текущее состояние DNS в момент конфигурирования и сохранено в виде файла /opt/vpnpptp/resolv.conf; таким образом модуль ponoff до установления VPN приводит состояние DNS к состоянию, которое было в момент конфигурирования соединения (при необходимости как и прежде поднимает также предварительно сетевой интерфейс, на котором было настроено VPN), а при выходе без аварии сеть возвращается к сетевому интерфейсу, на котором было сконфигурировано VPN, и к DNS, на которых было сконфигурировано VPN; прежний механизм возврата к текущим системным DNS, которые были до поднятия VPN, таким образом был отменен, так как это часто мусор,
  • 6) во многих дистрибутивах, в которых используется ifup, в частности в Mandriva и в ее аналогах, соединение теперь будет устанавливаться еще быстрее, выход без аварии станет еще быстрее - это все следствия введения долгожданного улучшенного механизма работы с DNS, при котором тормозной ifup более не нужен, и он теперь реже используется, и испольуется не для целей работы с DNS; если включить блокирование вывода всплывающих сообщений из трея, то будет еще быстрее, так как на вывод сообщений тратится время,
  • 7) в Mandriva и в ее аналоги в этой версии программы было перенесено путем закономерного обобщения всё лучшее, чего удалось достичь проекту, работая с другими дистрибутивами,
  • 8) полный отказ в модуле ponoff от команды resolvconf -u, так как не во всех дистрибутивах она есть, и она потеряла актуальность в связи переводом модуля ponoff на улучшенную автономную работу с DNS; resolvconf -u используется теперь лишь однократно в конфигураторе в PCLinuxOS,
  • 9) NetApplet станет реже сигнализировать об изменениях в сети, выводя кучу балунов, а если не требуется получать маршруты через DHCP, то NetApplet почти совсем не будет сигнализировать, перекрытие сообщений NetApplet и ponoff, следовательно, было максимально устранено.

Примечания:

Введение механизма улучшенной работы с DNS стало возможно когда удалось побороть многочисленные default, если сетевых интерфейсов в системе более одного, исправить многократное выполнение скриптов поднятия и опускания на однократное.

В разных дистрибутивах разные механизмы формирования /etc/resolv.conf, подстраиваться под эти механизмы неэффективно для проекта, проект не должен зависеть от таких особенностей дистрибутивов, он должен продолжать становиться как можно более автономным. На данный момент он достаточно автономный, и его автономия в будущем будет лишь усиливаться.

В программу заложена база для дальнейшего развития дистрибутива Mandriva и его аналогов, основанная на допущении, что в новых версиях дистрибутива получением маршрутов через DHCP будет заниматься сам дистрибутив.

Скорость работы модуля ponoff для всех поддерживаемых дистрибутивов стала сравнима со скоростью его работы в Ubuntu.

Эта версия программы сделана для Mandriva и ее аналогов. Для других дистрибутивов заложенные новые механизмы работы с DNS будут переноситься постепенно в следующих версиях.

XXIV) Возможности версии 0.2.4

  • 1) в openSUSE включены отключенные ранее опции разрешения пользователям управлять подключением, разрешения пользователям конфигурировать соединение, автозагрузка интернета при старте системы в графике - все это было реализовано через xsudo, которое теперь используется во всех поддерживаемых дистрибутивах,
  • 2) в openSUSE, Ubuntu, Debian и др. модуль ponoff теперь тоже работает с улучшенной системой работы с DNS со всеми вытекающими отсюда положительными последствиями,
  • 3) добавлена возможность переназначать пингуемый внешний сайт для проверки интернета с yandex.ru на любой другой путем правки /opt/vpnpptp/config - эта возможность не выносится в конфигуратор за исключительно редкой надобностью,
  • 4) исправлена прорисовка иконки в трее как сразу при старте ponoff, так и при многократном его запуске, она появляется теперь настолько быстро, насколько это возможно,
  • 5) в конфигураторе добавлен для VPN PPTP выбор параметра nobuffer; если nobuffer не выбран, то pptp будет обрабатывать сам потерянные пакеты, накапливая пакеты в буфере до полной закачки потерянных пакетов,
  • 6) исправлено наследование трафика новым экземпляром ponoff при превышении 4 Gb,
  • 7) при выборе в конфигураторе опции проверки VPN-сервера, DNS-сервера, шлюза локальной сети и интернета модуль ponoff плюсом до поднятия VPN проверяет DNS1 и DNS2 до поднятия VPN, а при поднятом VPN проверяет DNS3 и DNS4 при поднятом VPN, выводя при неполадках балуны,
  • 8) Debian был протестирован также при настройках сети Bridge в VMware, в этот дистрибутив была внесена поправка, ускоряющая поднятие VPN на порядок - существующий в дистрибутиве по-умолчанию скрипт /etc/ppp/ip-up.d/exim4 перемещается конфигуратором в /opt/vpnpptp/scripts, а на месте этого скрипта формируется инструкция куда делся exim4.

XXV) Возможности версии 0.2.5

  • 1) добавлена поддержка дистрибутива Fedora,
  • 2) в Fedora вместо gksu используется beesu,
  • 3) в Fedora директории /etc/ppp/ip-up.d, /etc/ppp/ip-down.d создаются конфигуратором, так как они отсутствуют, а так как они напрямую не используются, то создаются символические ссылки /etc/ppp/ip-up.local на /etc/ppp/ip-up.d/ip-up и /etc/ppp/ip-down.local на /etc/ppp/ip-down.d/ip-down,
  • 4) в Fedora будет использоваться стандартная для проекта работа с usepeerdns, которая изначально была разработана проектом для Mandriva, плюс будет использоваться файл resolv.conf.copy - это позволило как и в openSUSE иметь свою собственную локальную реализацию работы с usepeerdns, независимую от системы; файл resolv.conf.copy хранится теперь в /opt/vpnpptp/resolv.conf.copy, так как после перезагрузки директория /var/run может очищаться; этот подход по использованию файла resolv.conf.copy был перенесен также в Mandriva, где он ранее не использовался,
  • 5) так как в Fedora используется также как и в openSUSE пакет pptp вместо pptp-linux, то соответственно в скрипты директории /etc/ppp поступят такие же переменные как и в openSUSE: DNS1, DNS2, IFNAME, IPREMOTE и др,
  • 6) работа программы с NetworkManager'ом в Fedora аналогична работе программы с ним в Ubuntu, но сервис network тоже будет задействован вспомогательно с меньшим приоритетом, поэтому в Fedora наличие установленного NetworkManager'а необязательно,
  • 7) в Fedora получение маршрутов через DHCP реализовывается через директорию /etc/dhcp, а не через директорию /etc, поэтому создаются соответствующие символические ссылки, кроме того в Fedora перед получением маршрутов через DHCP требуется убивать dhclient, если dhclient уже запущен,
  • 8) в Fedora автозапуск интернета при старте системы демоном pppd(xl2tpd) реализован как в Mandriva,
  • 9) для всех дистрибутивов работа с сервисами, управляющими сетью, обобщена: приоритет управления отдается NetworkManager'у; следовательно наличие NetworkManager'а будет обязательно если только нет иных управляющих сетью сервисов, причем модуль ponoff и модуль vpnpptp независимы друг от друга в определении текущего приоритетного сервиса, управляющего сетью - это позволяет удалять или устанавливать NetworkManager без необходимости переконфигурирования соединения.

Примечания:

Как то видно из описания работы программы в Fedora, в этом дистрибутиве не используется ничего нового, чего не было бы уже сделано проектом для других дистрибутивов; Fedora просто поглотила в себя уже реализованные алгоритмы от других поддерживаемых проектом дистрибутивов по чуть-чуть от каждого из них.

В Fedora в соответствии с алгоритмом приоритета сервисов, управляющих сетью, управлять сетью будет сервис NetworkManager, а если его нет, то сервис network, а в Ubuntu - сервис network-manager, а если его нет, то сервис networking.

Так как в Mandriva и в ее аналогах все чаще используется NetworkManager, то был заложен фундамент для его преимущественного управления сетью как только он станет отвечать этим высоким требования, а до тех пор управлять сетью будет как и прежде сервис network.

XXVI) Возможности версии 0.2.6

  • 1) улучшен интерфейс модуля ponoff: всплывающие балуны из трея, хинты при наведении мышкой на трей сделаны в едином стиле программы, одного цвета, объемнее, они масштабируются в зависимости от размера шрифта, запомненного конфигуратором, а так как они теперь самописные, то устранен ряд глюков встроенных в Lazarus балунов и хинтов: a) неубирание хинта когда мышка из трея уже была убрана, b) появление на панели задач вместе с балуном кнопки, c) обрезание текста балуном, прячущимся за системный лоток,
  • 2) файл /opt/vpnpptp/resolv.conf переименован в /opt/vpnpptp/resolv.conf.before, а файл /opt/vpnpptp/resolv.conf.copy переименован в /opt/vpnpptp/resolv.conf.after для придания им более ясного смысла,
  • 3) временные файлы, которые должны быть временными, но не зависеть от перезагрузки компьютера и стирания тем самым /tmp, вынесены в директорию /opt/vpnpptp/tmp,
  • 4) добавлена поддержка сетевых интерфейсов brN, где 0<=N<=9,
  • 5) так как файл /opt/vpnpptp/resolv.conf.after создается конфигуратором лишь тогда, когда необходимо при поднятом VPN использовать DNS без получения их от VPN-сервера, то есть при незадании опции usepeerdns, то есть использовать DNS1 при поднятом VPN и DNS2 при поднятом VPN, заданные в конфигураторе, то так как эти DNS могут быть заданы с целью родительского контроля, то такой контроль был усилен для всех дистрибутивов - модуль ponoff при поднятом VPN, если существует файл /opt/vpnpptp/resolv.conf.after, проверяет по таймеру действительно ли используются DNS1 при поднятом VPN, DNS2 при поднятом VPN, и если это не так, то модуль ponoff немедленно приводит состояние DNS к требуемому; в Fedora модуль ponoff сам создает файл /opt/vpnpptp/resolv.conf.after если его нет, заполняя его по возможности полученными от VPN-сервера DNS, а после этого начинает работать для Fedora вышеизложенное в этом п. 5 даже для опции usepeerdns, так как в Fedora имеет место п. 6,
  • 6) в Fedora dhclient имеет право изменять файл /etc/resolv.conf, поэтому получение маршрутов через DHCP в этом дистрибутиве было реализовано в предыдущей версии через сначала разрешение dhclient'у изменить файл /etc/resolv.conf, то есть подождать, а лишь затем устанавливать соединение VPN, приводя состояние DNS при поднятом VPN к требуемому реализованными ранее алгоритмами после ожидания, но ожидание - не есть хорошее решение, поэтому сейчас согласно п.5 модуль ponoff не ждет dhclient, а корректирует за ним сам состояние DNS при поднятом VPN,
  • 7) учитывая вышеизложенное, в Fedora не рекомендуется одновременно использовать получение маршрутов через DHCP и осуществлять автозапуск интернета при старте системы демоном pppd(xl2tpd) без графики, о чем конфигуратор выводит предупреждающее сообщение, так как dhclient изменяет файл /etc/resolv.conf, поэтому в скрипт /etc/rc.local для Fedora после dhclient добавлена задержка sleep 10, что замедлит начальную загрузку системы на 10 секунд, если пользователь проигнорирует предупреждение конфигуратора,
  • 8) родительский контроль также был улучшен путем смягчения требования указать хотя бы одно из детских DNS, а не оба как ранее, - будет использоваться только оно, конфигуратор сконфигурирует соединение на одном детском DNS; родительский контроль также был усилен путем добавленного игнорирования недетских DNS в момент конфигурирования соединения, если хотя бы одно из них детское.

XXVII) Возможности версии 0.2.7

  • 1) демон xl2tpd модулем ponoff более не перезапускается, так как это в корне неправильно для линейной программы без задержек, а приемлемо лишь для консоли, для которой пользователь пока введет следующую команду пройдет время; иначе часто получалось, что демон xl2tpd еще не успел рестартануть до конца, а команда на установление соединения поступила; демон xl2tpd должен быть демоном и висеть в процессах постоянно, но если его нет, то программой его запускать, после его запуска немного подождать и дать команду на установление соединения;
echo "c имя_соединения" > /var/run/xl2tpd/l2tp-control #соединение,
echo "d имя_соединения" > /var/run/xl2tpd/l2tp-control #отключение",
  • 2) при старте конфигуратора если отсутствует дефолтный шлюз, то если в системе всего один сетевой интерфейс, то по возможности дефолтный шлюз создается,
  • 3) учитывая, что проект поддерживает аналогичные дистрибутивы, а при сборке пакетов невозможно учесть потребуется ли дополнительный пакет как то было для Debian - пакет sysvconfig, для того, чтобы работала команда service, а может это вообще другой пакет, это же неизвестно, то программа сама проверяет существует ли файл /sbin/service или файл /usr/sbin/service, и если он существует, то будет использоваться команда service иначе - команда /etc/init.d/; такой подход позволяет отказаться для Debian от зависимости sysvconfig, свести сборку пакетов для Debian и для Ubuntu к однообразной, и будет полезен аналогичным дистрибутивам,
  • 4) в скрипты (в их начало) /etc/ppp/ip-up.d/ip-up, /etc/ppp/ip-down.d/ip-down были добавлены строки:
if [ ! -f /opt/vpnpptp/ponoff ]
then
 exit 0
fi

это позволяет не выполнять скрипты /etc/ppp/ip-up.d/ip-up, /etc/ppp/ip-down.d/ip-down, если отсутствует файл /opt/vpnpptp/ponoff, то есть при удалении программы или только модуля ponoff, что удобно,

  • 5) в тестовый запуск добавлено получение маршрутов через DHCP, если оно было настроено, следовательно, можно будет протестировать не только интернет, но и одновременную работу интернета и локальной сети,
  • 6) алгоритм, примененный в предыдущей версии только для Fedora о контроле DNS1, DNS2 при поднятом VPN независимо от опции usepeerdns, распространен на все дистрибутивы, так как он направлен на защиту уже установленного соединения, в частности DNS, от любых внешних воздействий.

XXVIII) Возможности версии 0.2.8

  • 1) в провайдерский файл настроек /etc/ppp/peers/имя_соединения добавлена строчка unit X, а в скрипты /etc/ppp/ip-up.d/ip-up, /etc/ppp/ip-down.d/ip-down добавлены строки (в начало):
if [ ! $PPP_IFACE = "pppX" ] #if [ ! $IFNAME = "pppX" ]
then
    exit 0
fi

и таким образом скрипты поднятия и опускания стали привязаны к X, и они не будут выполняться для других соединений,

  • 2) добавлением дополнительного параметра unit X и его обработки скриптами проект стал еще более автономным от системы, но и были заложены основы профилей подключений, то есть теоретически в /etc/ppp/peers/ можно хранить сколько угодно различных имен соединений (модулей, профилей подключений), и для каждого из этих профилей подключений могут выполняться различные скрипты поднятия и опускания, причем все эти скрипты для различных профилей подключений можно смело хранить в /etc/ppp/ip-up.d/ и в /etc/ppp/ip-down.d/ - из них выполнятся лишь те, которые соответствуют номеру модуля; если использовать интерфейсы pppX, где X будет выбираться из числа неиспользуемых в дистрибутиве, то каждый профиль подключения будет запускаться автономно, то есть если исключить X=0, то для ppp0 наши скрипты поднятия и опускания не будут выполняться; проще говоря программа не использует интерфейс ppp0, а начинает использовать ppp1 или выше и таким образом, например, Network-Manager работает с ppp0, а скрипты поднятия и опускания не будут выполняться для ppp0 (для dslN логично тоже самое).
  • 3) добавлены дистрибутивы: Russian Fedora, Rosa,
  • 4) для всех дистрибутивов сделана одинаковая работа с usepeerdns, с DNS при поднятом VPN: файл /var/run/ppp/resolv.conf более не используется, используется только файл /opt/vpnpptp/resolv.conf.after; конфигуратор vpnpptp теперь всегда при любых условиях создает файл /opt/vpnpptp/resolv.conf.after и заполняет его DNS1, DNS2 и др. при поднятом VPN, указанными в конфигураторе; после этого в скрипте /etc/ppp/ip-up.d/ip-up проверяется используется ли опция usepeerdns; если опция usepeerdns используется, и VPN-сервер предоставил свои DNS, то файл /opt/vpnpptp/resolv.conf.after изменяется этим скриптом (если не предоставил, то не изменяется); если опция usepeerdns выбрана не была, то файл /opt/vpnpptp/resolv.conf.after не изменяется этим скриптом; затем скрипт /etc/ppp/ip-up.d/ip-up копирует файл /opt/vpnpptp/resolv.conf.after в /etc/resolv.conf; таким образом этот механизм работает даже без графики, не пересекается с системным механизмом, так как действует п. 1, наиболее полно учитывает поступающие в скрипты директории /etc/ppp/ переменные $DNS1, $DNS2, $USEPEERDNS, которые во всех поддерживаемых дистрибутивах одинаковые,
  • 5) файл /etc/resolv.conf.lock более не создается, вместо этого скрипт /etc/ppp/ip-down.d/ip-down копирует файл /opt/vpnpptp/resolv.conf.before в файл /etc/resolv.conf, приведя то, что уже было сделано ранее для графики, одинаково для работы без графики,
  • 6) отменена поддержка тех, кто пользовался скриптами от mr.Peabody, так как сам автор их больше не поддерживает,
  • 7) в конфигураторе внесены поправки на определение шлюза локальной сети при отсутствии дефолтного шлюза и на ручное изменение определенного автоматически шлюза локальной сети - он становится дефолным,
  • 8) внесены поправки в модуль ponoff на подсчет трафика и времени в сети даже если скрипт /etc/ppp/ip-down.d/ip-down не выполняется.

Примечания:

В этой версии программы я постарался свести все дистрибутивы к общему знаменателю во всем, чтобы в коде для них было как можно меньше отличий, проведя ревизию кода. Впервые зачатки такой работы с DNS при поднятом VPN были использованы только для openSUSE, но именно они оказались наиболее простыми и универсальными для всех поддерживаемых дистрибутивов. Профили подключений возможны, но еще не реализованы. То, что файл /var/run/ppp/resolv.conf более не используется, позволяет сделать программу энергонезависимой. Число аналогичных дистрибутивов, в которых программа будет работать в связи с внесенными поправками возрастет, так как уже неважно как в том или ином дистрибутиве реализована работа с DNS при поднятом VPN, и неважно есть ли в дистрибутиве свои методы настройки VPN, так как программа более с ними практически не пересекается.

XXIX) Возможности версии 0.2.9

  • 1) в программу был включен патч peermodify.sh (от 769218589@qq.com), который путем сверки с man pppd приводит шифрование mppe к правильному и корректирует провайдерский файл настроек на основании man pppd,
  • 2) изменения в модуле ponoff: многие важнейшие аспекты работы с сетью, как-то вызов dhclient, опускание и поднятие сетевых интерфейсов, рестарт сети вынесены в процессы, а программа больше не ждет окончания этих процессов; ранее если эти процессы были долгие, особенно в аварийных ситуациях, то модуль ponoff с трудом отзывался, так как ждал их окончания, теперь же программа продолжает выполняться и отвечать на действия пользователя во многих таких ситуациях; как следствие ускорился выход при аварии из программы,
  • 3) модуль ponoff не ждет dhclient, дает ему минимум 3 секунды на получение маршрутов через DHCP, но максимум 6 секунд,
  • 4) в конфигураторе vpnpptp при тестовом запуске и в модуле ponoff (однократно при старте и после установления соединения) проверяется фактическое mtu, и если оно больше чем 1460 байт, то выводится предупреждение,
  • 5) в конфигураторе vpnpptp добавлена опция маршрутизации remote IP address в шлюз локальной сети (по-умолчанию не выбрана), который будет маршрутизирован даже если remote IP address не совпадает с IP-адресом VPN-сервера, следовательно, модуль ponoff при выборе этой опции не проверяет совпадение remote IP address с IP-адресом VPN-сервера за ненадобностью; если remote IP address совпадает с IP-адресом VPN-сервера, то эта опция будет являться отличным методом маршрутизации VPN-сервера,
  • 6) переход для всех дистрибутивов в скриптах поднятия и опускания к единым переменным $IFNAME, $IPREMOTE (переменные $PPP_IFACE, $PPP_REMOTE более вообще не используются),
  • 7) отказ от суффикса edm, разрешение выбрать встроенный в демон xl2tpd механизм реконнекта независимо от версии xl2tpd, предупреждение лишь хинтом о необходимости пропатченной версии xl2tpd,
  • 8) изменены директории программы, отказ от директории /opt/, используются директории: /var/lib/vpnpptp/ (этот каталог создает конфигуратор, и он используется для хранения всех файлов, созданных в процессе функционирования программы, которые живут после перезагрузки системы), /tmp/vpnpptp/ (основной временной каталог программы, его создает и ponoff, и vpnpptp), /usr/share/vpnpptp/ (этот каталог создается при установке программы, в него помещаются все файлы из пакета, кроме исполняемых файлов), /usr/bin/ (стандартный каталог для исполняемых файлов),
  • 9) отказ от удаления /var/run/ppp/resolv.conf в PCLinuxOS,
  • 10) переход на приоритетный сервис networkmanager для Mandriva и ее аналогов,
  • 11) добавлена проверка модулем ponoff при старте размера файла-лога /var/log/syslog, и если он больше 1 Гб, то выводится информационный балун,
  • 12) исправлен баг по блокированию всплывающих сообщений из трея.

Примечания:

При обновлении с более старой версии программы на версию 0.2.9 произойдет эффект будто только что впервые установленной программы, кроме случая если обновляется пакет из репозитория Russian Fedora, в котором изменение путей уже было произведено. Конфигуратор сам удалит ранее использовавшуюся директорию /opt/vpnpptp.

При нечистой установке (или при обновлении со старой версии) настоящей версии программы возможны проблемы с работой этой новой версии программы (это проявится в отсутствии в меню для запуска приложений картинок и в отсутствии исполняемых файлов ponoff и vpnpptp программы в основном в дистрибутивах Ubuntu, Debian и в их аналогах) - тогда удалите эту новую версию программы и установите заново. К сожалению полная совместимость пакетов с предыдущими версиями во всех дистрибутивах невозможна.

XXX) Возможности версии 0.3.0

  • 1) если выбрано шифрование mppe, то если man pppd неполный или отсутствует, то конфигуратором выводится информационное предупреждение,
  • 2) автоматизирована сборка rpm-пакетов и deb-пакетов для различных архитектур, помещение пакетов в репозитории Russian Fedora, Mandriva,
  • 3) исправлен вызов конфигуратора vpnpptp из Центра Управления Mandriva - поломал в предыдущей версии,
  • 4) улучшения в модуле ponoff, половина кода переписана: значительное уменьшение необходимости обращения к жесткому диску путем перехода от shell к popen,
  • 5) исправлен ранее работавший запрет двойного запуска конфигуратора vpnpptp - поломал в предыдущих версиях,
  • 6) рассмотрен вариант запуска под root и не под root одновременно,
  • 7) модуль ponoff более не влияет на vnstat, модуль ponoff более не порождает зомби-процессы dhclient, net_monitor, исправлен расчет скорости загруженного/отданного, также исправлены другие ошибки,
  • 8) переписана работа справки в конфигураторе, офисное приложение ищется:
for i in {,/usr,/usr/local}{/bin,/lib} /opt /home;  do   find  $i  -name oowriter -type f 2>/dev/null; done;
for i in {,/usr,/usr/local}{/bin,/lib} /opt /home;  do   find  $i  -name soffice -type f 2>/dev/null; done;

и берется последнее из найденных с приоритетом для oowriter, а если ничего не найдено, то выводится сообщение,

  • 9) для dhclient дается время тактом из расчета: время дозвона, разделенное нацело на 3, но не более 2-х тактов (то есть получение маршрутов через DHCP занимает либо 1/3 времени дозвона, либо 2/3 времени дозвона, а на поднятие туннеля, если выбрано получение маршрутов через DHCP, остается соответственно либо 2/3 времени дозвона, либо 1/3 времени дозвона),
  • 10) улучшения в модуле ponoff позволили снять ряд ограничений на время дозвона,
  • 11) возвращен выход при аварии из предыдущей версии программы, так как ускоренный такой выход показал свою непригодность,
  • 12) минимальное MTU для VPN L2TP принято 1460 байт, вместо ранее принятых 1400 байт,
  • 13) конфигуратор vpnpptp теперь работает даже в том случае если кроме его исполняемого файла вообще ничего нет; модуль ponoff откажется работать если не найдет одного из файлов: /var/lib/vpnpptp/имясоединения/resolv.conf.before, /var/lib/vpnpptp/имясоединения/resolv.conf.after,
  • 14) для модуля ponoff предусмотрена дефолтная черно-белая иконка, которая встроена в исполняемый файл и которая используется, если не найдены /usr/share/vpnpptp/off.ico или /usr/share/vpnpptp/on.ico, отсутствие которых считается теперь нормальным явлением,
  • 15) отказ от записи в провайдерский файл настроек /etc/ppp/peers/имясоединения параметра unit и отказ от принятого ранее различения соединений по номеру получившегося сетевого интерфейса pppN; теперь сетевые интерфейсы как и ранее начинаются с ppp0, а различаются соединения в скриптах поднятия и опускания по параметру linkname, указанному в провайдерском файле настроек /etc/ppp/peers/имясоединения, значение которого равно имени соединения, также в скриптах поднятия и опускания теперь используется переменная $LINKNAME, то есть каждое соединение имеет имя,
  • 16) конфигуратор создает дефолтное соединение /var/lib/vpnpptp/default/default, которое по сути является простым файлом с информацией какое из имеющихся соединений использовать в качестве дефолтного; самое первое настроенное соединение автоматически становится дефолным, а новое настраиваемое соединение конфигуратор предлагает сделать дефолтным, если оно еще таковым не является и есть иное дефолтное соединение; дефолтное соединение используется модулем ponoff в случае его запуска без параметров; модуль ponoff умеет, если нет дефолтного соединения, но есть хотя бы одно недефолтное, то при старте спросить пользователя выпадающим списком соединений как поступить, и с согласия пользователя любое имеющееся недефолтное соединение модуль ponoff сделает дефолтным,
  • 17) модуль ponoff запускается теперь либо без параметров, либо в качестве первого параметра ему передается имя соединения, а конфигуратор vpnpptp создает на Рабочем столе ярлыки для различных соединений при условии, что для конкретного имени соединения создание ярлыков предусмотрено его конфигом, аналогично и с конфигуратором - его запуск без параметров означает создание нового соединения если еще не было настроено ни одного соединения, а если было настроено уже хотя бы одно соединение, то конфигуратор предлагает выпадающий список таких соединений и возможность создания нового соединения, его запуск с параметрами позволяет изменить или удалить соединение, или создать соединение с именем-параметром, если оно еще не создано, также на Рабочем столе создаются ярлыки настройки для каждого соединения для их настройки,
  • 18) в каталоге /var/lib/vpnpptp/ создаются подкаталоги с именем соединения, а скрипты поднятия и опускания теперь имеют префикс имени соединения, например, /etc/ppp/ip-up.d/beeline-ip-up, /etc/ppp/ip-down.d/beeline-ip-down, но конфигуратор не пишет больше скрипт опускания /etc/ppp/ip-down.d/beeline-ip-down; конфигуратор создает директорию /etc/ppp/ip-down.l/, в которую пишет прежний скрипт опускания, например, /etc/ppp/ip-down.l/beeline-ip-down, а скрипт опускания /etc/ppp/ip-down.d/beeline-ip-down пишется скриптом поднятия /etc/ppp/ip-up.d/beeline-ip-up,
  • 19) разрешен как и прежде повторный запуск ponoff, но теперь лишь это разрешение распространяется на повторный запуск идентичного соединения по имени соединения, не удастся запустить 2 разных соединения одновременно, в целях чего используется директория /var/run/vpnpptp/, в которой учитывается работающее соединение,
  • 20) улучшенное управление скриптом опускания позволило отказаться в модуле ponoff от изменения местоположения скрипта(ов) опускания,
  • 21) отказ от команды echo "d имясоединения" > /var/run/xl2tpd/l2tp-control, так как при этом не выполняется самостоятельно скрипт опускания, эта команда заменена на killall pppd для VPN L2TP, при которой скрипт опускания выполняется самостоятельно, а эффект такой же - соединение VPN L2TP опускается и не мешает соединению с другим именем поднять соединение VPN L2TP,
  • 22) в директории соединений /var/lib/vpnpptp/имясоединения для VPN L2TP добавлены файлы xl2tpd.conf.lac, содержащие секцию LAC этого соединения,
  • 23) ведется файл /var/lib/vpnpptp/profiles, содержащий имена всех соединений,
  • 24) в конфигураторе vpnpptp добавлена кнопка, позволяющая удалить соединение, она активна лишь если активное соединение можно удалить,
  • 25) в конфигураторе вынесены отдельно настройки, общие для всех соединений - при изменении этих настроек изменяется конфиг сразу всех соединений - /var/lib/vpnpptp/general.conf; в конфигураторе вынесены отдельно взаимоисключающие настройки - при изменении этих настроек изменяются конфиги сразу всех соединений, такие взаимоисключающие опции устанавливаются для текущего соединения и отменяются для всех других соединений,
  • 26) для Fedora конфигуратор создает скрипт /etc/ppp/ip-up.local следующего содержания:
#!/bin/sh
if [ -d /etc/ppp/ip-up.d/ -a -x /usr/bin/run-parts ]; then   
    /usr/bin/run-parts /etc/ppp/ip-up.d/
fi

и скрипт /etc/ppp/ip-down.local следующего содержания:

#!/bin/sh
if [ -d /etc/ppp/ip-down.d/ -a -x /usr/bin/run-parts ]; then   
    /usr/bin/run-parts /etc/ppp/ip-down.d/
fi
  • 27) снят запрет на одновременный выбор автозапуска интернета демоном pppd(xl2tpd) без графики и выбор автозапуска интернета в графике - это позволяет, даже если иксы не стартанули, пользоваться интернетом, а если стартанули, то это не препятствует переходу на графический автозапуск интернета.

Примечания:

Libreoffice тоже теперь имеет возможность работать со справкой.

В случае выбора опции получения маршрутов через DHCP если dhclient не уложился даже во время дозвона в окончании 3-го такта, то ponoff будет дожидаться завершения работы dhclient'а, увеличив время 3-го такта до фактического завершения работы dhclient'а.

Если получение маршрутов через DHCP не выбрано, то такт всего один, и он равен времени дозвона - в этом первом такте устанавливается туннель. Если получение маршрутов через DHCP выбрано, то туннель устанавливается либо во-втором, либо в третьем такте.

Для того, чтобы модуль ponoff работал с черно-белой иконкой, необходимо удалить (переименовать) один из файлов /usr/share/vpnpptp/off.ico или /usr/share/vpnpptp/on.ico, либо собрать пакет без файлов on.ico, off.ico - это может быть полезно в черно-белых темах оформления как в Ubuntu, но у такой иконки всегда одно состояние, и различить есть соединение или нет соединения можно будет по всплывающему хинту при наведении мышкой на иконку в трее. Соответственно индикация становится цветной при наличии одновременно /usr/share/vpnpptp/on.ico и /usr/share/vpnpptp/off.ico.

В пункте 20 изложен механизм, по которому скрипт опускания теперь фактически состоит из двух частей - одна часть пишется конфигуратором vpnpptp и модулем ponoff, а другая его часть пишется только исключительно скриптом поднятия. В скрипт поднятия поступают переменные, которые экспортируются так, чтобы они всегда поступали в скрипт опускания, и этот экспорт происходит через файл-скрипт /etc/ppp/ip-down.d/имясоединения-ip-down, из которого потом после экспорта фактически вызывается скрипт опускания /etc/ppp/ip-down.l/имясоединения-ip-down. Такой подход позволяет в неизменном виде передать по назначению все переменные и важную переменную $LINKNAME, без которой различение имен соединений было бы невозможно. В скрипт /etc/ppp/ip-up.d/имясоединения-ip-up в конец добавлено:

echo "#!bin/sh" > /etc/ppp/ip-down.d/$LINKNAME-ip-down
export >> /etc/ppp/ip-down.d/$LINKNAME-ip-down
echo "/etc/ppp/ip-down.l/$LINKNAME-ip-down" >> /etc/ppp/ip-down.d/$LINKNAME-ip-down
chmod +x /etc/ppp/ip-down.d/$LINKNAME-ip-down

Файл-конфиг /etc/xl2tpd/xl2tpd.conf создается на основе данных из /var/lib/vpnpptp/profiles, из которого читаются имена соединений и формируется единый файл-конфиг /etc/xl2tpd/xl2tpd.conf из xl2tpd.conf.lac, взятых в каждой директории соединения.

Если настроено и используется всего одно соединение, то дополнительный функционал работы программы с множественными соединениями будет незаметен для пользователя. Общее число соединений ничем не ограничено.

Уделено огромное внимание, чтобы созданные конфигуратором vpnpptp соединения работали без иксов.

XXXI) Возможности версии 0.3.1

  • 1) добавлена поддержка Ubuntu 11.04, Mageia,
  • 2) добавлена проверка использовался ли скрипт mr. Peabody в конфигураторе vpnpptp, и если он использовался, то конфигуратор предложит самостоятельно восстановить скрипт поднятия /etc/ppp/ip-up, скрипт опускания /etc/ppp/ip-down, и прекратит свою работу до исправления пользователем последствий применения скрипта mr. Peabody,
  • 3) учитывая, что NetApplet? используется не во всех дистрибутивах, то в индикацию модуля ponoff в трее добавлены: интерфейс, ip-адрес, шлюз, DNS1, DNS2 - они отражают параметры сетевого интерфейса, на котором поднято VPN,
  • 4) для модуля ponoff установлен приоритет хинта над балуном (ранее было наоборот), так как если пользователь наводит в момент, когда должен показаться хинт, мышкой на иконку в трее, то он ожидает всё же увидеть хинт, а не балун,
  • 5) в конфигураторе vpnpptp ограничена длина имени соединения до 15 символов, изменена привязка элементов на последней странице настройки,
  • 6) в конфигураторе vpnpptp при выходе из него если удалось поднять VPN, то появляется информация о возможности пожертвований на разработку; в модуле ponoff добавлен пункт "Пожертвования", вызывающий информацию о возможности пожертвований на разработку, этот пункт становится активным в случае если удалось поднять VPN,
  • 7) снято ограничение, действовавшее ранее, на неподсчитывание более 4 Gb загруженного/отданного; улучшены подсчет трафика и подсчет скорости загрузки/отдачи,
  • 8) модуль ponoff определяет максимальную пропускную способность сети, и если скорость загрузки/отдачи три раза подряд превышает максимальную пропускную способность сети, то выводится предупреждающий баллун,
  • 9) если конфигуратору не удалось определить ни DNS1 до поднятия VPN, ни DNS2 до поднятия VPN, то конфигурирование прекращается в случае, если адрес VPN-сервера задан по имени; но конфигурирование в этом случае продолжается, если адрес VPN-сервера задан по ip с диалогом информационного замечания,
  • 10) допускается не задавать в конфигураторе DNS1 при поднятом VPN, DNS2 при поднятом VPN, конфигуратор при этом будет всячески рекомендовать включить опцию usepeerdns; ситуация, при которой не введены DNS1 при поднятом VPN, DNS2 при поднятом VPN, и при этом опция usepeerdns не выбрана, допускается, но не рекомендуется конфигуратором,
  • 11) лог-файл вынесен в /var/log/vpnlog,
  • 12) для Fedora при выборе VPN L2TP конфигуратор vpnpptp не разрешает выбрать опцию ведения лога pppd(xl2tpd) в /var/log/vpnlog.

Примечания:

В Ubuntu Software Center в Ubuntu 11.04 обнаружен баг, проявляющийся в невозможности удаления программ через Ubuntu Software Center, поставленных через Ubuntu Software Center, но не из репозитория, поэтому, если нужно удалить такую программу, то используйте dpkg, например: sudo dpkg -r vpnpptp-allde.

Если скорость отдачи превышает пропускную способность сети, то это свидетельствует о том, что интернет перестал работать, то есть сетевой интерфейс ppp0 всё еще числится, но он более неработоспособен, связь вот-вот оборвется, а интерфейс ppp0 исчезнет.

В этой версии по просьбе учителя одной из школ рассмотрен один из частных случаев подключения, при котором адрес VPN-сервера задается по ip, провайдер не дает вообще никаких DNS ни до поднятия VPN, ни после поднятия VPN, при этом провайдер через опцию usepeerdns присылает свои DNS, которые используются при поднятом VPN. В предыдущих версиях программы конфигуратор для этого частного случая заставлял вводить DNS1 и/или DNS2 при поднятом VPN, которые так и так при выбранной опции usepeerdns не использовались бы, если бы провайдер прислал свои, поэтому сейчас их можно не вводить. Также в частном случае провайдер не дает ни логина, ни пароля для подключения, однако pppd требует в этом случае произвольных непустых значений, поэтому в этой части программа изменений не требует.

В Fedora 15 SElinux не позволяет для VPN L2TP использовать опцию logfile, поэтому была внесена поправка на запрет ведения лога для Fedora для VPN L2TP.

XXXII) Возможности версии 0.3.2

  • 1) добавлено приложение vpnmandriva, которое выполняет функции отсутствующего в mcc (Центр Управления Mandriva) настройки VPN PPTP (mcc находится в пакете drakconf), но которое наиболее полно использует интеграцию в дистрибутивы, основанные на Mandriva,
  • 2) вызов приложения vpnmandriva происходит через Центр Управления->Сеть и Интернет->Настройка VPN->VPN PPTP или из аналогичного раздела в net_applet, также можно просто запустить из любой директории исполняемый файл приложения,
  • 3) в vpnmandriva создаются новые сетевые интерфейсы pppN, где N из диапазона [0..100] без возможности их отредактировать повторно, удаляются такие соединения через Центр Управления->Сеть и Интернет->Удалить подключение,
  • 4) файервол для vpnmandriva настраивается через Центр Управления, работа с DNS реализована исключительно так, как она реализована в дистрибутиве,
  • 5) приложение vpnmandriva основано на недоделанной в Mandiva возможности настройки VPN PPTP, поэтому конфиги используются, предложенные разработчиками Mandiva, кроме: а) в провайдерский файл настроек добавлена опция linkname vpnmandriva, б) в провайдерский файл настроек добавлена опция unut N, в) vpnmandriva использует скрипт /etc/ppp/ip-down.d/vpnmandriva-ip-down, в котором просто происходит рестарт сети, но этот скрипт реагирует лишь на linkname vpnmandriva, г) метрика для pppN предлагается 1, вместо 25, д) опция nobuffer предложена включенной по-умолчанию с возможностью изменения, е) добавлена возможность настройки аутентификации и шифрования, ё) файл /etc/ppp/chap-secrets не используется, пароль пишется в провайдерский файл настроек /etc/ppp/peers/pppN, ж) при выборе шифрования mppe опция noccp не используется,
  • 6) vpnmandriva автоматически предлагает настроить сетевой интерфейс pppN, подбирая ближайший еще ненастроенный из диапазона [0..100], создавая в итоге /etc/sysconfig/network-scripts/ifcfg-pppN, также создается /etc/ppp/peers/pppN и скрипт /etc/ppp/ip-down.d/vpnmandriva-ip-down, больше никаких изменений не производится, у vpnmandriva отсутствует даже свой собственный конфиг за ненадобностью,
  • 7) опции разрешения пользователям управлять подключением, установления соединения при загрузке, подсчет трафика реализованы через /etc/sysconfig/network-scripts/ifcfg-pppN,
  • 8) из достоинств vpnmandriva стоит выделить также работу с различными сетевыми интерфейсами pppN многопрофильно, возможность настройки pppN без учета текущего состояния сети и имеющихся сетевых интерфейсов, без привязки к сетевым интерфейсам, исключительную легкость настройки, но при этом из-за отсутствия привязки к конкретному сетевому интерфейсу и из-за ошибок маршрутизации в различных дистрибутивах при отключении pppN будет происходить рестарт сети,
  • 9) у программы vpnmandriva нет зависимостей, есть только исполняемый файл, который включает в себя все необходимые программе ресурсы; при запуске не под root программа запустится, но предложит запуск под root; при запуске под root программа сама установится (обновится) если она была запущена не из директории /usr/bin/ (скопирует свой исполняемый файл в /usr/bin/ и создаст файл /usr/lib/libDrakX/network/vpn/vpnmandriva.pm),
  • 10) разрешен многократный запуск vpnmandriva; поддерживаются языки: русский, украинский, английский,
  • 11) в vpnmandriva имеется опция ведения лога pppd в /var/log/ppp/vpnmandriva.log,
  • 12) для Белоруссии язык установлен русский для всех приложений проекта,
  • 13) модуль ponoff, определяя будет ли сервис Network Manager управлять сетью, учитывает теперь наличие его в процессах, а не только наличие исполняемого файла для Network Manager,
  • 14) в конфигураторе vpnpptp лог вынесен в /var/log/ppp/vpnlog, а для Fedora при VPN L2TP вновь разрешено ведение лога через команду restorecon -R -v /var/log/ppp/, которую выполняет конфигуратор vpnpptp (https://bugzilla.redhat.com/show_bug.cgi?id=710565),
  • 15) конфигуратор vpnpptp запрещает также использовать в любом регистре имя соединения "vpnmandriva", а также в любом регистре имя соединения, начинающееся с "ppp",
  • 16) добавлена поддержка сетевых интерфейсов emN, где 0<=N<=9,
  • 17) разрешены любые сетевые интерфейсы, но поддерживаются на 100% лишь ethN, wlanN, brN, emN, где N в диапазоне [0..9].

Примечания:

Несмотря на миграцию Mandriva, начиная с версии 2011 года, на NetworkManager, остается возможность использовать пакет drakx-net и приложение из него net_applet, не говоря уже о том, что в версиях Mandriva до 2011 года по-умолчанию сеть настраивается через mcc и net_applet. Также в дистрибутивах PCLinuxOS, Mageia работа с сетью осталась прежней. Поэтому, приложение vpnmandriva будет полезно во всех дистрибутивах, в которых так или иначе используется net_applet.

При вызове vpnmandriva или при вызове vpnpptp из Центра Управления предлагается ввести имя соединение, но оно не играет никакой роли.

Приложение vpnmandriva является по сути урезанной версией более продвинутой программы vpnpptp, а vpnmandriva является приложением зависимым от дистрибутива и компонентов в этом дистрибутиве. В частности, трафик считается через vnstat (пакет vnstat), а просматривается через net_monitor (пакет net_monitor), файервол настраивается в дистрибутиве, соединения удаляются в дистрибутиве, управление соединениями осуществляется через net_applet. Но эти зависимости от дистрибутива не очень жесткие, ведь трафик необязателен, удалить соединение можно, удалив /etc/sysconfig/network-scripts/ifcfg-pppN, вместо net_applet могут использоваться команды ifup pppN, ifdown pppN и т. д.

Программа сделана для новичков, которые могут просто скачать из интернета один исполняемый файл и просто запустить его, но в тоже время программа может быть установлена обычным образом через rpm-пакет (тогда исполняемый файл vpnmandriva должен ложиться в /usr/bin/, а патч vpnmandriva.pm в /usr/lib/libDrakX/network/vpn/).

XXXIII) Возможности версии 0.3.3

  • 1) теперь для всех приложений при опции useepeerdns имеет приоритет /etc/resolvconf/resolv.conf.d/head, что актуально для MagOS,
  • 2) для vpnmandriva теперь используется скрипт /etc/ppp/ip-up.d/mandriva-ip-up, задача которого при опции usepeerdns (она у vpnmandriva включена по-умолчанию всегда) при поднятом VPN создать такой файл /etc/resolv.conf, на первом месте в котором будут DNS из /etc/resolvconf/resolv.conf.d/head (если vpn-сервер предоставил свои DNS), а затем пойдут DNS, полученные от VPN-сервера, то есть подход очень близкий к использованному в проекте vpnpptp,
  • 3) в модуле ponoff исправлен тест Интернета,
  • 4) в утилите vpnmandriva после создания подключения предлагается установить тестовое соединение VPN PPTP и проверить Интернет в режиме диалога, vpnmandriva предлагает повторную проверку Интернета; проверка основана на пинге yandex.ru (а для тестовых параметров соединения - на пинге swissvpn.net), при этом каким бы долгим не был пинг, программа выводит таймер, таймер выводится при любых долгих процессах,
  • 5) vpnmandriva, проверяя Интернет, если находит, что соединение VPN PPTP поднято на настраиваемом интерфейсе, но внешние сайты не пингуются, то проверяет кол-во дефолтных маршрутов с одинаковой метрикой, сообщая если находит несколько дефолтных маршрутов с одинаковой метрикой,
  • 6) исправлено определение модулем ponoff и конфигуратором vpnpptp сетевого интерфейса, на котором поднято VPN, за основу взят /var/run/ppp-имясоединения.pid, создаваемый демоном pppd и лишь затем наличие pppN в ifconfig,
  • 7) ускорен перезапуск net_applet в утилите vpnmandriva,
  • 8) в vpnmandriva при нажатии левой кнопкой мыши на картинке с пингвином вводятся тестовые параметры, работоспособные если интернет уже настроен:
VPN server: connect.swissvpn.net
Username: swissvpntest
Password: swissvpntest
  • 9) vpnmandriva если находит, что соединение уже поднято на настраиваемом интерфейсе, а пользователь хочет вновь поднять соединение на настраиваемом интерфейсе, то происходит ifdown pppN; vpnmandriva предлагает убивать pppd если находит его(их) в процессах, но при этом своего pppd vpnmandriva не убивает,а предпочитает ifdown, убиваются лишь pppd неизвестного происхождения и то с согласия пользователя,
  • 10) все приложения проекта переведены на TAsyncProcess вместо использованного ранее TProcess, демон xl2tpd тоже запускается через TAsyncProcess, поэтому соединение VPN L2TP теперь устанавливается без задержки, которая требовалась ранее для полного запуска демона xl2tpd, и составляла 3 секунды, если демон xl2tpd еще не запущен,
  • 11) также ponoff был ускорен тем, что теперь отдельный модуль занимается выводом балунов, балуны теперь имеют приоритет над всеми другими системными балунами, они перекрывают их собой; ускорение происходит за счет того, что ponoff лишь дает задачу выводить сообщение, а модуль самостоятельно организует очередь поступивших сообщений и вывод их по очереди с учетом времени показа сообщения,
  • 12) BuildRequires: fpc-src >= 2.4.2, fpc >= 2.4.2, lazarus >= 0.9.29,
  • 13) добавлена поддержка протокола VPN OpenL2TP: конфигуратор vpnpptp создает файл-конфиг /var/lib/vpnpptp/имясоединения/openl2tpd.conf, создаются также /var/lib/vpnpptp/имясоединения/openl2tp-start, /var/lib/vpnpptp/имясоединения/openl2tp-stop, /var/lib/vpnpptp/default/openl2tp-stop; таким образом используются уже существующие конфиги, созданные VPN PPTP и/или VPN L2TP с небольшими этими дополнениями,
  • 14) реализация всплывающего хинта из трея у ponoff переписана и сделана отдельным модулем, хинт также как и ранее имеет приоритет над балунами, но теперь он исчезает всегда сам,
  • 15) в ponoff добавлены пункты при нажатии правой кнопкой мыши на иконке в трее, позволяющие увеличить размер иконки, уменьшить размер иконки, изменить ее с цветной на черно-белую и наоборот, при этом имеются 2 черно-белые дефолтные иконки, отражающие есть соединение или нет, черно-белые иконки вшиты в исполняемый файл ponoff, они также как и прежде используются если нет цветных иконок (ранее черно-белая иконка была одна), изменение размеров иконки происходит через обычное растяжение/сжатие; конфигуратор vpnpptp сбрасывает настройки размера и цвета иконки для ponoff на дефолтные при переконфигурировании соединения с этим именем,
  • 16) улучшен тестовый запуск в конфигураторе,
  • 17) для Fedora для VPN OpenL2TP выводится предупреждение о необходимости selinux-policy>=3.9.16-33,
  • 18) разрешено масштабировать окно конфигуратора vpnpptp и окно утилиты vpnmandriva,
  • 19) при настройке VPN L2TP в xl2tpd.conf в секцию lac добавлена опция tx bps и опция tunnel rws = 8, а в зависимостях пакета теперь xl2tpd >= 1.2.7,
  • 20) при настройке VPN OpenL2TP выбор в конфигураторе vpnpptp опции автозапуска интернета при старте системы демоном openl2tp(d) без графики запрещен,
  • 21) поправлено создание иконок на Рабочем столе конфигуратором vpnpptp для LXDE.

Примечание:

Соединение VPN OpenL2TP поднимается скриптом /var/lib/vpnpptp/имясоединения/openl2tp-start, задача которого создать /etc/ppp/options, добавив в него call имясоединения, скопировать файл /var/lib/vpnpptp/имясоединения/openl2tpd.conf в /etc/openl2tpd.conf, перезапустить сервис portmap (rpcbind), а затем перезапустить сервис openl2tp(d). Соединение VPN OpenL2TP опускается скриптом /var/lib/vpnpptp/имясоединения/openl2tp-stop, задача которого создать чистый /etc/ppp/options, удалить /etc/openl2tpd.conf, а затем остановить сервис openl2tp(d). Скрипт /var/lib/vpnpptp/default/openl2tp-stop используется для отключения любых соединений. Добавление в файл /etc/ppp/options строки call имясоединения позволяет использовать опции из файла /etc/ppp/peers/имясоединения, в том числе опцию linkname, позволяющую различать соединения и выполнять различные скрипты поднятия и опускания. Таким образом /etc/openl2tpd.conf и /etc/ppp/options стали динамическими. При этом такой подход позволяет работать с OpenL2TP как в графике, так и без графики. К тому же алгоритм работы VPN OpenL2TP получился достаточно простой и прозрачный.

За отсутствием на данный момент работоспособного неурезанного пакета openl2tp для OpenSuse программа может, но не обязана работать с VPN OpenL2TP в OpenSuse.

В Fedora 15 необновленный SELinux не позволяет работать с VPN OpenL2TP: https://bugzilla.redhat.com/show_bug.cgi?id=718465.

XXXIV) Возможности версии 0.3.4

  • 1) добавлено определение дистрибутивов Linux Mint, Kubuntu, BackTrack,
  • 2) собраны универсальные инсталляторы vpnpptp_setup, позволяющие устанавливать пакет vpnpptp/vpnpptp-allde для архитектур x86, x86_64 (amd64) для всех поддерживаемых проектом дистрибутивов,
  • 3) пакеты vpnpptp-kde-one упразднены,
  • 4) все утилиты: vpnpptp, ponoff теперь умеют сами требовать пароль root, запускаясь через xroot/kdesu/beesu/gksu,
  • 5) пакеты vpnpptp/vpnpptp-allde более не зависят ни от чего, а пакеты pptp-linux(pptp), xl2tpd, openl2tp рассматриваются как различные плагины и подлежат самостоятельной отдельной установке на выбор,
  • 6) добавлен скрипт /usr/bin/vpnlinux для работы с созданными конфигуратором vpnpptp соединениями в консоли, в том числе без графики:
   /usr/bin/vpnlinux имясоединения #для соединения 
   /usr/bin/vpnlinux stop #для отключения всех VPN-соединений 
  • 7) исправлено шифрование mppe,
  • 8) в интерфейс модуля ponoff добавлен виджет как в программах multiget, fdm, который может быть использован в качестве альтернативы трею, а в конфигураторе vpnpptp имеется соответствующая опция.
  • 9) добавлена задержка для отображения иконки в трее при автозапуске ponoff,
  • 10) обработана ошибка отображения иконки в трее для модуля ponoff, возникающая в Unity: в случае невозможности отобразить иконку ponoff в трее происходит автоматическое переключение на виджет,
  • 11) в ponoff устранены утечки памяти, а также снижена нагрузка на процессор при отображении хинтов,
  • 12) более не используются файлы /var/lib/vpnpptp/имясоединения/nocolor, /var/lib/vpnpptp/имясоединения/ponoff.conf,
  • 13) у модуля ponoff теперь свой конфиг, общий для всех соединений - /var/lib/vpnpptp/ponoff.conf.ini,
  • 14) если ни один из плагинов-пакетов: pptp-linux(pptp), xl2tpd, openl2tp не установлен, то конфигуратор откажется работать; теперь конфигуратор конфигурирует соединение только при условии наличия того или иного плагина-пакета,
  • 15) конфигуратор vpnpptp теперь сам проверяет версию xl2tpd (раньше это регулировалось при сборке пакетов), в будущем он будет проверять и версии других пакетов-плагинов если это необходимо,
  • 16) добавлен приоритетный запуск vpnpptp и ponoff через xroot,
  • 17) улучшения в Тестовом запуске в конфигураторе vpnpptp.

Примечания:

Начиная с этой версии vpnpptp-allde не зависит даже от gksu, программа сама определяет какое средство запуска под root использовать из списка xroot/kdesu/beesu/gksu - из этого списка они перебираются по очереди из доступных.

Чтобы модуль ponoff отображался в виде виджета надо в его конфиге /var/lib/vpnpptp/ponoff.conf.ini указать Widget=true. Если Widget=false, то ponoff использует иконку в трее.

Чтобы иконка у модуля ponoff была черно-белой надо в его конфиге /var/lib/vpnpptp/ponoff.conf.ini указать black_and_white_icon=true. Если black_and_white_icon=false, то ponoff использует цветную иконку в трее.

Для Ubuntu по-умолчанию предлагается использовать виджет, но использовать трей тоже можно (если ponoff не докажет обратного и не переключится на виджет автоматически, о чем сообщит).

При сборке в репозиторий стоит добавить все зависимости к пакету vpnpptp по всем правилам, убрав комментарии в spec-файле и поправив файл control.

XXXV) Возможности версии 0.3.5

  • 1) внесена поправка на изменившийся ifconfig в Fedora 17,
  • 2) если шлюз локальной сети в конфигураторе vpnpptp не пингуется или теряются пакеты, то считается, что это не всегда влияет на поднятие VPN,
  • 3) для Fedora конфигуратор vpnpptp всегда выводит предупреждение о возможной необходимости настройки SELinux,
  • 4) если отсутствует файл /etc/resolv.conf, то конфигуратор vpnpptp создает его сам и заносит в него nameserver 127.0.0.1 и Google Public DNS, о чем выводится предупреждение,
  • 5) для VPN L2TP/OpenL2TP теперь разрешен выбор шифрования mppe,
  • 6) исправлена настройка получения маршрутов через DHCP в конфигураторе vpnpptp,
  • 7) исправлено падение конфигуратора vpnpptp при настройке файервола в Mageia,
  • 8) в vpnmandriva адрес connect.swissvpn.net изменен на адрес connect.lb.swissvpn.net,
  • 9) sh заменен везде на bash.

Примечания:

В Fedora 17 для работы VPN OpenL2TP требуется установить пакет kernel-modules-extra, так как в него были вынесены необходимые модули ядра. Аналогичная ситуация в Fedora с ядерным xl2tpd.

XXXVI) Возможности версии 0.3.6

  • 1) если отсутствует /etc/resolv.conf, то при проверке пинга DNS серверов до поднятия VPN конфигуратор не пингует Google Public DNS,
  • 2) RX bytes и TX bytes теперь берутся из /proc/net/dev,
  • 3) улучшена поддержка шифрования mppe: а) признана необходимость указания только опции required для задания шифрования mppe в самом простейшем случае, б) при этом нельзя выбрать ни одну из опций stateless/no40/no56/no128 без выбора опции required, в) если выбрать опцию required для шифрования mppe, то нельзя выбрать опцию refuse-mschap одновременно с опцией refuse-mschap-v2, запретив MS-CHAP и MS-CHAPv2,
  • 4) нельзя запретить все виды аутентификации, поэтому нельзя одновременно выбрать опции: refuse-chap, refuse-eap, refuse-pap, refuse-mschap, refuse-mschap-v2,
  • 5) теперь опция no56 не отображается если в pppd ее нет,
  • 6) нельзя указывать required для шифрования mppe и при этом одновременно запретить и 40-битное, и 56-битное (если оно доступно в pppd), и 128-битное шифрования,
  • 7) отказ от скрипта peermodify.sh; вместо него настройка шифрования mppe сверяется с /usr/bin/strings /usr/sbin/pppd, в случае отсутствия /usr/bin/strings сверка идет по man pppd, если же в man нет про pppd, то сообщается о проблеме, а настройка шифрования mppe производится по дефолту,
  • 8) добавлена опция dump при нажатии на кнопку "Дополнительно",
  • 9) если mtu больше, чем 1472, то выводятся предупреждения (ранее было больше, чем 1460),
  • 10) добавлена проверка при выборе шифрования mppe на наличие модуля ppp_mppe,
  • 11) ревизия .po-файлов,
  • 12) при тестовом запуске приложение ponoff остается запущенным при выходе из vpnpptp,
  • 13) добавлен скрипт /usr/share/vpnpptp/whitelist.sh, позволяющий добавить приложение в трей Unity; таким образом в Ubuntu ponoff вернулся в трей по-умолчанию,
  • 14) улучшен перезапуск ponoff в виде виджета, если возникает ошибка отображения иконки в трее,
  • 15) разрешен одновременный запуск с vpnpptp_setup,
  • 16) в ponoff добавлен modbrobe ppp_generic перед поднятием VPN, иначе бывает ругается на отсутствие /dev/ppp, без которого VPN не поднимется.

Примечания:

В этой версии была сделана полная ревизия работы с шифрованием mppe, код переписан на примере провайдера ТВОЙнэт (http://www.tvoynet.ru), хотя предыдущие версии vpnpptp также умели настраивать mppe, но сейчас настройка более точная, больше подсказок, вероятность неверной настройки значительно снижена.

Скрипт whitelist.sh работает только в Ubuntu не ниже 12.04 (или возможно в более ранних версиях, но после обновления системы).

Шифрование mppe было протестировано также на vpn-сервере, доступном через внешку:

vpn-сервер: connect.lb.swissvpn.net
логин: swissvpntest
пароль: swissvpntest

На VPN-сервере, доступном через внешку (http://www.usaip.eu/en/free_vpn.php), были протестированы: VPN PPTP, VPN L2TP, VPN OpenL2TP, VPN PPTP+mppe, VPN L2TP+mppe, VPN OpenL2TP+mppe:

vpn-сервер: vpn15.usaip.eu
логин: demo
пароль: demo

Повторить тесты можно на VmWare Player при настройке сети NAT.

XXXVII) Возможности версии 0.3.7

  • 1) поправлен возврат сети после dhclient в конфигураторе vpnpptp для Network Manager,
  • 2) в хинт модуля ponoff добавлено MTU,
  • 3) в vpnmandriva перенесены наработки из vpnpptp по шифрованию mppe и по аутентификации,
  • 4) в vpnmandriva добавлена возможность редактирования ранее созданных интерфейсов,
  • 5) в vpnmandriva добавлены поля MTU и MRU,
  • 6) изменились языки у всех проектов:
украинский язык: для украинской локали, 
русский язык: для белорусской, башкирской, болгарской, чеченской, церковнославянской, чувашской, казахской, коми, молдавской, татарской локалей, 
английский язык: для всех остальных локалей, 
  • 7) в vpnmandriva при запуске производится очистка ранее удаленных интерфейсов,
  • 8) в vpnmandriva добавлена возможность задать команды, выполняющиеся после поднятия VPN и после опускания VPN, при этом после опускания VPN по умолчанию предлагается рестарт сети, но можно задать иное поведение,
  • 9) в vpnmandriva решен вопрос применения изменений без перезапуска net_applet командой:
kill -s 1 pidof -x net_applet 
  • 10) добавлен патч от ism, исправляющий отображение хинтов и балунов в oxygen-gtk (проявляется в Mageia 2).

XXXVIII) Возможности версии 0.3.8

  • 1) переход на lazbuild, улучшен процесс сборки пакетов,
  • 2) исправлены ошибки с правами, в частности на /usr/share/vpnpptp/lang.

C) Описание структуры файла конфигурации /var/lib/vpnpptp/имясоединения/config конфигуратора и интерфейса управления соединениями VPN через PPTP/L2TP/OpenL2TP

  • 0) имя соединения. любое значение, требования к имени соединения как к имени файла.
  • 1) адрес vpn-сервера. значение: ip-адрес (вида xxx.xxx.xxx.xxx, где x - любой из квадрантов - число от 0 до 255) или символьный адрес.
  • 2) шлюз локальной сети. значение вида xxx.xxx.xxx.xxx, где x - любой из квадрантов (октетов) - число от 0 до 255.
  • 3) сетевой интерфейс. значение вида ethN, где N - число от 0 до 9.
  • 4) время реконнекта. значение: число от 1000 до 255000 - время в миллисекундах или значение 0 - отсутствие реконнекта.
  • 5) время дозвона. значение: число от 5000 до 255000 - время в миллисекундах.
  • 6) опция контроля state сетевого кабеля. может принимать значения mii-tool-yes (контролировать state) и mii-tool-no (не контролировать state).
  • 7) опция механизма реконнекта. может принимать значение noreconnect-pptp (механизм реконнекта, не встроенный в демон pppd) и значение reconnect-pptp (механизм реконнекта, встроенный в демон pppd).
  • 8) опция ведения логов pppd. может принимать значение pppd-log-yes (лог pppd ведется) и значение pppd-log-no (лог pppd не ведется).
  • 9) опция получения маршрутов через DHCP. может принимать значение dhcp-route-yes (имеет место получение маршрутов через DHCP) и значение dhcp-route-no (не имеет места получение маршрутов через DHCP).
  • 10) опция mtu. может принимать цифровое значение mtu или значение mtu-none (mtu не задано).
  • 11) до версии программы 0.1.3: опция наличия шифрования. может принимать значение shifr-yes (имеет место шифрование) и значение shifr-no (не имеет места шифрование).
  • 11) начиная с версии программы 0.1.3: опция наличия шифрования required. может принимать значение required-yes и значение required-no.
  • 12) опция наличия шифрования refuse-chap. может принимать значения rchap-yes и rchap-no.
  • 13) опция наличия шифрования refuse-eap. может принимать значения reap-yes и reap-no.
  • 14) опция наличия шифрования refuse-mschap. может принимать значения rmschap-yes и rmschap-no.
  • 15) опция наличия шифрования stateless. может принимать значения stateless-yes и stateless-no.
  • 16) опция наличия шифрования no40. может принимать значения no40-yes и no40-no.
  • 17) опция наличия шифрования no56. может принимать значения no56-yes и no56-no.
  • 18) none.
  • 19) опция создания ярлыка на рабочем столе. может принимать значения link-desktop-yes и link-desktop-no.
  • 20) до версии программы 0.1.3: опция наличия шифрования require-mppe-128. может принимать значения require-mppe-128-yes и require-mppe-128-no.
  • 20) начиная с версии программы 0.1.3: опция наличия шифрования no128. может принимать значения no128-yes и no128-no.
  • 21) опция имени vpn-сервера или его IP. может принимать значения IPS-yes (адрес vpn-сервера задан IP) и IPS-no (адрес vpn-сервера задан именем).
  • 22) опция программного добавления маршрута к vpn-серверу. может принимать значения routevpnauto-yes и routevpnauto-no.
  • 23) опция проверки vpn-сервера, шлюза локальной сети и есть ли интернет. может принимать значения networktest-yes (выполнять проверки) и networktest-no (не выполнять проверки).
  • 24) опция блокирования всплывающих сообщений. может принимать значения balloon-yes (блокировать) и balloon-no (не блокировать).
  • 25) none.
  • 26) none.
  • 27) опция автозапуска интернета при старте системы в графике. может принимать значения autostart-ponoff-yes и autostart-ponoff-no.
  • 28) опция автозапуска интернета при старте системы демоном pppd. может принимать значения autostart-pppd-yes и autostart-pppd-no.
  • 29) опция неизменения дефолтного шлюза. может принимать значения pppnotdefault-yes и pppnotdefault-no.
  • 30) DNS1 до поднятия vpn. значение вида xxx.xxx.xxx.xxx, где x - любой из квадрантов (октетов) - число от 0 до 255 или none.
  • 31) DNS2 до поднятия vpn. значение вида xxx.xxx.xxx.xxx, где x - любой из квадрантов (октетов) - число от 0 до 255 или none.
  • 32) дополнительное DNS3 до поднятия vpn. значение вида xxx.xxx.xxx.xxx, где x - любой из квадрантов (октетов) - число от 0 до 255 или none.
  • 33) опция программного добавления маршрута к dns-серверам. может принимать значения routednsauto-yes и routednsauto-no.
  • 34) опция использования dns, полученных от vpn-сервера. может принимать значения usepeerdns-yes и usepeerdns-no.
  • 35) DNS1 при поднятом vpn. значение вида xxx.xxx.xxx.xxx, где x - любой из квадрантов (октетов) - число от 0 до 255 или none.
  • 36) DNS2 при поднятом vpn. значение вида xxx.xxx.xxx.xxx, где x - любой из квадрантов (октетов) - число от 0 до 255 или none.
  • 37) опция наличия аутентификации refuse-pap. может принимать значения rpap-yes и rpap-no.
  • 38) опция наличия аутентификации refuse-mschap-v2. может принимать значения rmschapv2-yes и rmschapv2-no.
  • 39) опция типа vpn. может принимать значения pptp, l2tp, openl2tp.
  • 40) опция mru. может принимать цифровое значение mru или значение mru-none (mru не задано).
  • 41) опция использования файла /etc/hosts динамически. может принимать значения etc-hosts-yes и etc-hosts-no.
  • 42) none.
  • 43) none.
  • 44) адрес пингуемого внешнего сайта. по-умолчанию yandex.ru.
  • 45) опция использования параметра nobuffer. может принимать значения nobuffer-yes и nobuffer-no.
  • Также может присутствовать опция none, показывающая, что соответствующий параметр еще не определен.
  • Ранее вместо /var/lib/vpnpptp/имясоединения/config использовался /opt/vpnpptp/config.

D) Описание структуры файла конфигурации /var/lib/vpnpptp/general.conf конфигуратора и интерфейса управления соединениями VPN через PPTP/L2TP/OpenL2TP

  • 0) опция добавления интерфейсов [ppp0..ppp9] в исключения файервола. может принимать значения shorewall-yes и shorewall-no.
  • 1) опция разрешения пользователям управлять подключением. может принимать значения sudo-yes (разрешить) и sudo-no (не разрешать).
  • 2) опция разрешения пользователям конфигурировать соединение. может принимать значения sudo-configure-yes (разрешить) и sudo-configure-no (не разрешать).
  • 3) размер шрифта приложения.
  • 4) дистрибутив. может принимать значения none, ubuntu, mandriva, debian, suse, fedora.

E) Ссылки проекта конфигуратора и интерфейса управления соединениями VPN через PPTP/L2TP/OpenL2TP

Со времени появления этого пакета некоторые проблемы были решены альтернативными методами - подробнее можно ознакомиться и уточнить непонятные вопросы на форумах:

Страница проекта:

F) История создания конфигуратора и интерфейса управления соединениями VPN через PPTP/L2TP/OpenL2TP

1 апреля 2009 года на http://unixforum.org (изначально адрес был http://linuxforum.ru) было опубликовано сообщение: "Так как мы явно не дождемся что французы добавят возможность использования VPN MS (самый у нас распространенный способ) то будем действовать сами".

Долгожданный проект был похож на первоапрельскую шутку - на тот момент юзер практически не мог выйти в интернет через VPN PPTP в GUI в Mandriva/PCLinuxOS, так как приходилось настраивать VPN PPTP через скрипты, вручную доводить до ума файлы конфигурации и из консоли запускать сконфигурированное соединение. Однако оказалось, что новый проект реален. И появилась первая программа, способная поднимать VPN PPTP в GUI. В Mandriva/PCLinuxOS это был один из немногих простых вариантов в GUI настраивать VPN PPTP, а имеющийся в GUI Mandriva/PCLinuxOS туннель pptp требовал доработки.

Проект встретил потребность в нем пользователей, он прижился в массах сначала в России, но в связи с потребностью в нем и у иностранных пользователей, проект был переведен на многоязыковую поддержку.

В KDE была и есть программа KVpnc, однако она много весит (что критично, так как надо скачать из интернета то, что поднимет интернет, да еще и с зависимостями), у нее чрезмерно много опций, она сложна в понимании для новичков, слишком универсальна для всех видов VPN (в том числе для очень редких видов VPN) и потому для рядового пользователя непростая, к тому же ограничена лишь KDE, не умеет настраивать VPN L2TP/OpenL2TP, не работает без иксов.

Для Mandriva 2010.0 и ниже после плясок с бубном иногда удается запустить Network Manager и через него настроить VPN PPTP, что для большинства пользователей неприемлемо, так как требует углубленных знаний предметной области. В Mandriva 2010.1 и выше Network Manager научился настраивать VPN PPTP, но пользователи предпочли vpnpptp из-за интеграции программы в сетевые инструменты Mandriva, в ее Центр Управления, а также из-за того, что Network Manager не всегда способен поднять соединение, не умеет восстанавливать соединение, настройка его для работы без иксов не каждому понятна, соединение VPN PPTP часто получается у Network Manager'а низкоскоростное. В 2011 году Network Manager научился настраивать VPN L2TP (разработка в этом направлении едва теплится), но с теми же проблемами, что были свойственны VPN PPTP, кроме проблем со скоростью соединения для VPN L2TP.

Также существуют множественные скрипты, в частности, скрипт pptp-command, а также другие скрипты - но новичкам командная строка сложна - им нужен GUI.

В Центре Управления Mandriva/PCLinuxOS/Mageia была и есть возможность настроить сеть через pptp, но эта возможность недоделана.

Программа vpnpptp - одна из немногих программ, которая легко умеет настраивать VPN по протоколу L2TP/OpenL2TP без IpSec.

Программа vpnpptp простая, графическая, дружелюбная, многоязыковая, работает в любом DE, в различных дистрибутивах, мало весит, зависимости либо минимальны, либо отсутствуют, по-умолчанию сама предлагает оптимальные настройки, работает с несколькими VPN-соединениями, и это при том, что ее функционал успешно конкурирует с другими аналогами - поэтому пользователи по достоинству оценили ее.

Почти одновременно с этим проектом родился проект besbashvpn, в котором разработчик предлагал программу для настройки VPN PPTP, написанную на Lazarus. Эта программа была написана для OpenSuse 11.1, и разработчик пытался выяснить как эта программа будет вести себя в других дистрибутивах, так как он использовал при написании программы универсальную инструкцию по настройке VPN PPTP для всех существующих дистрибутивов линукса. Однако, несмотря на универсальность используемой им инструкции, ему не удалось создать универсальный GUI и исполняемый файл для всех существующих дистрибутивов линукса, проблему зависимостей разрешить не удалось. Он не захотел сотрудничать с настоящим проектом vpnpptp и ни грамма внимания не уделил Мандриве/PCLinuxOS - операционной системе, которой такой проект был нужнее других линуксов. Разработчик besbashvpn знал о разработке vpnpptp, а разработчик vpnpptp мог не знать о проекте besbashvpn - в итоге наработки проекта besbashvpn не были учтены в проекте vpnpptp. Превратив программу в испытательный полигон, проект besbashvpn был обречен. Очень сложно написать конфигуратор сети игнорируя или в обход принятого в дистрибутиве решения. Однако, в попытке объять необъятное, причем сразу, рубя с плеча, проект besbashvpn умер через 3 месяца после своего рождения, так и оставшись программой для тестовых целей.

Проект vpnpptp пошел иным путем в отличии от besbashvpn - несмотря на использование им универсальной инструкции по настройке VPN для всех существующих дистрибутивов линукса в сочетании с авторскими новациями, проект принимает во внимание решения, принятые в том или ином дистрибутиве линукса, поэтому vpnpptp способен работать в различных дистрибутивах линукса.

В начале 2011 года разработчик besbashvpn присоединился к проекту vpnpptp, принимая участие в его развитии.