Первый этап предполагает настройку Ethernet-соединения, а точнее настройку интерфейса на получение настроек по DHCP.
Делается это элементарно. В файле /etc/network/interfaces нужно добавить пару строчек:
auto eth0 iface eth0 inet dhcpeth0 - это имя сетевого интерфейса, подключенного к сети Уфанет. Узнать список доступных интерфейсов можно с помощью команды:
$ ifconfig -aДалее установим pptp-клиент и пакет resolvconf:
# aptitude install pptp-linux resolvconfПакет resolvconf добавляет к клиентам dhcp и pptp специальные сценарии, которые перехватывают информацию о DNS-серверах, полученную от dhcp- и pptp-серверов соответственно. Основываясь на перехваченной информации сценарии выполняют корректное обновление списка DNS-серверов в файле /etc/resolv.conf
Процесс настройки состоял из серии проб и ошибок, но в конце концов получилось удачно скомпилировать информацию из разных источников. В результате появился работоспособный набор конфигурационных файлов и скриптов.
Краткие пояснения по файлам конфигурации:
login - логин на соединение (именно логин, а не номер договора)
password - пароль на соединения (пароль на соединение, а не на просмотр баланса)
vpn.ufanet.ru - доменное имя VPN-сервера Уфанет
Теперь сами файлы:
/etc/ppp/peers/ufanet
pty "pptp vpn.ufanet.ru --nolaunchpppd" name login remotename vpn.ufanet.ru file /etc/ppp/options.pptp ipparam ufanet # Этот параметр передаётся в скрипты настройки # маршрутизации, о которых ниже/etc/ppp/chap-secrets
# Secrets for authentication using CHAP # client server secret IP addresses login vpn.ufanet.ru password */etc/ppp/options
asyncmap 0 auth crtscts lock hide-password modem proxyarp lcp-echo-interval 30 lcp-echo-failure 4 noipx/etc/ppp/options.pptp
lock noauth nobsdcomp nodeflate persist # Восстанавливать соединение при обрывеТеперь собственно скрипты для прописывания маршрутов при поднятии линка и для удаления маршрутов при падении линка. Скрипты были почерпнуты в одной из Интернет-конференций и доработаны под наш случай (в исходном виде скрипты, увы не работали).
/etc/ppp/ip-up.d/route
#!/bin/sh case "$PPP_IPPARAM" in ufanet) SERVER=vpn.ufanet.ru GW=`route -n | grep ^0\.0\.0\.0 | awk '{print $2}'` route del $PPP_REMOTE dev $PPP_IFACE route add -host $SERVER gw $GW route add default dev $PPP_IFACE ;; *) echo "No PPP_IPPARAM defined" ;; esac/etc/ppp/ip-down.d/route
#!/bin/sh case "$PPP_IPPARAM" in ufanet) SERVER=vpn.ufanet.ru route del -host $SERVER route del default dev $PPP_IFACE ;; *) echo "No PPP_IPPARAM defined" ;; esacДля того, чтобы сценарии заработали, нужно добавить им бит исполняемости:
# chmod +x /etc/ppp/ip-up.d/route /etc/ppp/ip-down.d/routeПодключение осуществляется с помощью команды:
# pon ufanetОтключение осуществляется с помощью команды:
# poff ufanetКоманды pon и poff нужно выполнять от пользователя root.
Чтобы соединение устанавливалось при старте системы, можно прописать в файл /etc/network/interfaces следующие строки:
auto ufanet iface ufanet inet ppp provider ufanet
9 комментариев:
Доброго времени суток, уважаемый.
возникла следующая проблема: нужно поднять прокси. после длительных размышлений было принято решение инсталлить на нее дэбу (5.0.3). все вроде бы нормально: самс активно рулит доступом к ресурсам в тырнэте, вэбмин спокойно справляется с администрированием самой машинки. грабли засели в подключении РРТР. Ситуация: уфанет выдал статический IP. в том числе и квартальный. все интерфейсы включаются и вроде бы все ок. но не идет разрешение DNS имен. все сделал на основании вышеприведенного howto, маленько по-постил на форуме тех поддержки. результат пока нулевой:
traceroute по DNS упорно выдает:
[b]ya.ru: временный сбой в разрешении имен
Cannot handle "host" cmdline arg `ya.ru' on position 1 (argc 1)
[/b]
если у Вас найдется немного времени, чтобы помочь мне разобраться с этой проблемой, напишите, пожалуйста в daddy_dave@ufamail.ru
заранее спасибо.
Статический IP? Может там и VPN-то не нужен, может прямо на Ethernet-интерфейсе Ваш IP нужно выставить?
Совсем недавно меня попросили настроить Уфанет с VPN-подключением в Debian Squeeze и я попробовал настроить его по своей статье. Хотя статья писалась во времена Etch, в настоящее время она не работает. В точности по статье настроить мне не удалось, много чего пришлось доделать и допроверить.
К сожалению, времени у меня очень мало, поэтому помочь не смогу.
VPN, к сожалению, нужен. и динамический IP не выдается. видемо, в этой подсети нет собственного DHCP сервера.
Самое интересное, что я у себя дома попытался проинсталлировать тот же самый lenny, что и здесь. все настройки из Вашего ховту подцепились слёту и все работает на ура, даже если интерфейс смотрящий в уфанет выставить в статику.
Предположив, что я что-то накосячил в конфигах, притащил их сюда. не работают.
А виндой подключение не пробовали проверить? Может быть проблемы вообще не в настройках, а в сети?
виндой все поднимается на раз. на ней все сейчас и крутится. но, в виду грядущей проверки из (!) Министерства ( :D ), нужно перевести максимальное количество компов под опенсорс. а так как на нормальную проксю (а так же на аппаратный фаер) денег никто не дает, то и ее тоже. вот и строю это ведро...
вроде бы не хватает chmod +x для файлов route
и в конце статьи очепятка "provider unfanet"
p.s. у меня без resolvconf прекрасно работает :)
спасибо за статью, а то Network Manager никак не хотел работать
Аноним, спасибо, исправления в статью внёс.
Без resolvconf может работать, а может и не работать. Если VPN оборвётся, то в файле /etc/resolv.conf останутся DNS-серверы, полученные по VPN. Но через Ethernet-сеть к ним доступ не получишь, поэтому VPN-соединение на адрес vpn.ufanet.ru может и не установиться. Если же ко времени установки соединения VPN по DHCP будет выполнено обновление настроек, то в /etc/resolv.conf окажется нужный DNS-сервер.
Если же обновление по DHCP произойдёт в то время, когда VPN-соединение установлено, то может пропасть возможность открывать сайты по их DNS-адресам.
Лично я всё-же посоветовал бы поставить пакет resolvconf.
resolvconf объединяет оба списка DNS-серверов и своевременно обновляет файл /etc/resolv.conf, чем помогает избежать подобных проблем.
здравствуйте! Пожалуйста, уточните:
В /etc/ppp/options прямо так и писать hide-password или вместо слова password вводить свой пароль?
Так и писать. Эта опция предотвращает отображение пароля в журнале диагностики.
Отправить комментарий