VPN — (с англ. Virtual Private Network) Виртуальная Частная Сеть. Это один из методов соединения компьютера или нескольких клиентов с сервером, предоставляющим доступ в интернет или другую сеть. Само соединение с помощью VPN может быть реализовано с использованием различных средств сетевой безопасности (т.н. IPSec), и/или с использованием других протоколов (таких как IPX), и, как правило, с использованием средств сжатия данных (т.н. MPPE-MPPC от Microsoft для совместимости с клиентами, использующими операционную систему Windows).
Введение
На практике, чаще всего, встречается ситуация, когда пользователь, воспользовавшись услугами провайдера для доступа в сеть Интернет, имеет доступ в локальную сеть, но для выхода в интернет, ему необходимо воспользоваться VPN-соединением, использующим PPTP-протокол.
Установка
Следовательно, для установления данного соединения, нам необходимо установить на нашу систему пакет pptp-linux (PPTP Client), имеющий в зависимостях стандартные библиотеки libc6 (libpcap0.8, Packet CAPture) и службу, реализующую протокол точка-точка, ppp (Протокол PPP, Point-to-Point Protocol - точка-точка):
# aptitude install pptp-linux
Внимание! mppe-mppc нужен только для старых ядер, 2.6.15 <, в более новых выпусках дистрибутивов, начиная с выпуска Debian GNU/Linux 4.0 Etch, это шифрование уже входит в ядро. Вы можете посмотреть версию вашего ядра, набрав команду:
# uname -r
Так же, возможно, у вас уже установлена служба ppp, в обратном же случае, ?APT подхватит ppp, как зависимость pptp-linux, и установит службу.
Настройка
У вас должны быть следующие данные, которые вам должен предоставить ваш провайдер, предоставляющий вам доступ по VPN, как администратор сервера PPTP. Значения данных, приведённые для более наглядного примера, будут являться стандартными значениями для провайдера beeline, Корбина Телеком:
($SERVER), IP-адрес или hostname сервера, vpn.internet.beeline.ru
($TUNNEL), название туннеля; название подключения, придуманное вами произвольно для удобства, используется для обращения к туннелю, beeline, corbina
- ($DOMAIN), доменное имя для авторизации, используется только в системе с организацией доступа доменных имён
($USERNAME), имя пользователя, ваш логин, который вы должны использовать для подключения к Интернет, по VPN, десятизначный уникальный номер вида 08xxxxxxxx
($PASSWORD), ваш пароль, который вы должны использовать в паре с логином , очень длинный и сложный
- требуется ли шифрование?
В приведёном ниже, контексте, замените вручную значения в скобках на свои значения. Например, в том месте, где находится $PASSWORD, подразумевается, что Вы замените $PASSWORD своим паролем. 
доступ к серверу VPN
Также подразумевается, что вы имеете доступ по сети к серверу VPN, т.н. через локальную сеть. Если ваша локальная сеть не настроена и доступа к серверу VPN нет, то первый этап будет предполагать настройку Ethernet-соединения, а точнее настройку интерфейса на получение настроек по DHCP. Делается это элементарно. В файл /etc/network/interfaces
# nano /etc/network/interfaces
нужно добавить пару строчек:
auto eth0 iface eth0 inet dhcp
где eth0 - это имя сетевого интерфейса, подключённого, через локальную сеть, к серверу DHCP. В случае, если в локальной сети не используется сервер DHCP, ввести параметры соединения требуется вручную:
auto eth0
iface eth0 inet static
address 10.x.x.x
netmask 255.255.255.0
broadcast 10.x.x.255
gateway 10.x.x.1Возможно, eth0 потребуется заменить на другой интерфейс (т.н. eth1, eth2), в том случае, если у вас имеется более одного интерфейса и локальная сеть подключена к другому Ethernet-интерфейсу. Узнать список доступных интерфейсов можно с помощью команды:
# ifconfig -a
а для того, чтобы узнать к какой сетевой карточке относится интерфейс можно посмотреть вывод команды
# dmesg | grep eth
После окончательных настроек файла /etc/network/interfaces вам потребуется перезапустить сеть командой:
# /etc/init.d/networking restart
и проверить правильность настройки интерфейсов:
# ifconfig -a
Самим подключением управляет демон pppd, настроить который можно с помощью, как минимум, двух конфигурационных файлов.
настройка основных файлов
Основные файлы настройки находятся в каталоге /etc/ppp/, а если вы находитесь на терминале, логично будет для удобства перейти в каталог командой:
# cd /etc/ppp/
Настройка соединения по VPN заключается в редактировании следующих файлов:
- /etc/ppp/chap-secrets
- /etc/ppp/options.pptp
- /etc/ppp/peers/$TUNNEL
Настройка каждого из файлов подробно описана ниже:
/etc/ppp/options.pptp
Разумно сохранить, на всякий случай, файл /etc/ppp/options.pptp, т.к. скорее всего, немногим позже, он вам потребуется и пригодится. Вы всегда можете посмотреть значения параметров по-умолчанию из исходного файла.
# cp /etc/ppp/options.pptp /etc/ppp/options.pptp.src
Файл /etc/ppp/options.pptp устанавливает параметры, которые будут применяться ко всем туннелям. В большинстве случаев, можно воспользоваться только этими параметрами:
lock noauth nobsdcomp nodeflate
для проверки работоспобности оставьте незакомментированными только эти параметры, закомментировав двумя символами решётки (##), для удобства в будущем, остальные параметры. Более детальное описание настроек смотрите здесь ?options.pptp.
/etc/ppp/chap-secrets
PAP (англ. Password Authentication Protocol) — протокол простой проверки подлинности, предусматривающий отправку имени пользователя и пароля на сервер удалённого доступа открытым текстом (без шифрования). Протокол PAP крайне ненадежён, поскольку пересылаемые пароли можно легко читать в пакетах PPP (англ. Point-to-Point Protocol), которыми обмениваются стороны в ходе проверки подлинности. На практике, обычно PAP используется только при подключении к старым серверам удалённого доступа на базе UNIX, которые не поддерживают никакие другие протоколы проверки подлинности. Использование PAP строго не рекомендуется.
CHAP (англ. Challenge Handshake Authentication Protocol) — широко распространённый алгоритм проверки подлинности, предусматривающий передачу не самого пароля пользователя, а косвенных сведений о нём. При использовании CHAP, сервер удалённого доступа отправляет клиенту строку запроса. На основе этой строки и пароля пользователя, клиент вычисляет MD5 (англ. Message Digest-5) hash и передаёт его серверу. Функция hash является алгоритмом одностороннего (необратимого) шифрования (преобразования), поскольку значение функции hash для блока данных вычислить легко, а определить исходный блок по hash, с математической точки зрения, невозможно за приемлемое время. Сервер, которому доступен пароль пользователя, выполняет те же самые вычисления и сравнивает результат с hash, полученным от клиента. В случае совпадения, учётные данные клиента удалённого доступа считаются подлинными и клиент проходит авторизацию на сервере.
MS-CHAP (англ. Microsoft Challenge Handshake Authentication Protocol) — протокол, разработанный корпорацией Microsoft для выполнения процедур проверки подлинности удалённых рабочих станций под управлением Windows. Протокол поддерживает функциональные возможности, привычные пользователям локальных сетей, и интегрирует алгоритмы шифрования и хеширования, действующие в сетях под управлением Windows. Для проведения проверки подлинности без передачи пароля протокол MS-CHAP, как и CHAP, использует механизм «вызов-ответ».
Вызов-ответ (англ. Challenge-response authentication) — способ аутентификации, при котором секрет (а в данном случае — пароль) не передаётся по каналу связи.
Простейший способ такой аутентификации (при хранении паролей в открытом виде):
Клиент, желающий пройти аутентификацию, даёт запрос на начало сеанса связи, и в ответ на это вызываемая сторона (сервер) посылает произвольную, но всякий раз разную информацию (например, текущие дату и время в формате unixtime) клиенту.
- Клиент дописывает к полученному запросу пароль, и от этой строки вычисляет какой-либо hash (т.н. MD5) и отправляет его серверу.
- Сервер у себя проделывает с отправленным значением аналогичные действия и сравнивает результат. Если значения hash совпадают, то авторизация считается успешной.
Протокол MS-CHAP генерирует запрос и ответ с помощью алгоритма хеширования MD4 (англ. Message Digest 4) и алгоритма шифрования DES (англ. Data Encryption Standard); предусмотрены также механизмы возврата сообщений об ошибках подключения и возможности изменения пароля пользователя. Ответный пакет использует специальный формат, предназначенный для использования сетевыми средствами систем Windows 95, Windows 98, Windows Millennium Edition, Windows NT, Windows 2000 Server и Windows XP..
CHAP аутентификация происходит следующим образом - при установлении PPP-соединения, удалённая сторона предлагает вам аутентификацию CHAP. Вы соглашаетесь, и удалённая сторона высылает вам ключ (challenge), состоящий из случайной последовательности символов, и своё имя. Вы берёте ваш пароль и присланный ключ и прогоняете их через алгоритм MD5. Получившийся результат высылаете вместе со своим именем. Удалённая сторона, зная ваш пароль и высланный её ключ, в свою очередь, проделывает то же самое и у себя, и если её результат совпадает с присланным вами, то аутентификация считается успешной. Таким образом, пароль не передается в открытом виде, но удалённая сторона должна хранить ваш пароль в открытом виде.
Первое, на что надо обратить внимание в методах авторизации PAP и CHAP - то, что они разработаны, чтобы опознавать компьютерные системы, а не пользователей. Разница заключается в том, что как только ваш компьютер (client) создал PPP (Point-to-Point Protocol) соединение с сервером (server), ЛЮБОЙ пользователь вашей системы может использовать это соединение - не только вы. Именно поэтому вы можете устанавливать WAN связь, которая соединяет между собой две LAN, используя PPP. PAP может требовать (а CHAP ТРЕБУЕТ) двунаправленного установления подлинности, то есть компьютер на каждом конце соединения, и клиент, и сервер, должен иметь правильные имя и пароль другой стороны. Однако, большинство PPP серверов с доступом по коммутируемым линиям, использующие PAP, этим способом НЕ пользуются.
Файл /etc/ppp/chap-secrets содержит данные для авторизации, в частности, пары логин и пароль, используемые при авторизации через протокол проверки пароля CHAP. В данном файле вам необходимо указать логин, пароль, а иногда и название PPTP-сервера, к которому будет происходить подключение. Формат записи данных в этот файл следующий:
# client server secret IP addresses
$DOMAIN\\$USERNAME PPTP $PASSWORD *
ваш_логин имя_подключения ваш_пароль *Четыре поля с разделителем между значениями параметров - символом табуляции или пробелом.
Пару ваш_логин и ваш_пароль вам обязан предоставить ваш провайдер (как администратор сервера PPTP на принимающей стороне), чтобы позволить вам соединяться с их системой, и выходить дальше в Интернет, через VPN, используя предоставленные провайдером ресурсы.
Первое поле (client) содержит значение вашего логина, для доступа в Интернет, как имя вашего компьютера.
CHAP требует, чтобы вы (client) и PPTP-сервер (server) имели взаимно опознавательные методы - вы должны позволить: и вашей машине (client) опознать удалённый сервер (server), и удалённому серверу (server) опознать вашу машину (client). На практике, обычно, вашего провайдера (server) не интересует имя вашего компьютера (client) вообще, так что, вы, скорее всего, должны будете использовать ваш логин, предоставленный провайдером, как имя вашего компьютера (client).
Второе поле (server) содержит значение имени удалённого компьютера (PPTP-сервера).
Так как методы PAP/CHAP могут служить для опознания компьютеров, технически вы должны также указать имя удалённого компьютера (server). Однако, поскольку большинство людей работает только с одним провайдером, то вы можете использовать в файле секретов (/etc/ppp/chap-secrets), вместо имени удалённого хоста (server), групповой символ звёздочки для значения поля Server. На практике, обычно, если заранее это не оговорено, используется произвольное значение, т.н. "PPTP" или "bee".
Также стоит заметить, что многие провайдеры применяют модемные пулы, соединённые с различными терминальными серверами - каждый со своим именем, но ДОСТУПНЫЙ с одного (циклически переключаемого) входного номера. Следовательно, может быть очень сложно, при некоторых обстоятельствах, узнать заранее имя удаленного компьютера (server), поскольку это зависит от того, к какому терминальному серверу вы подсоединились.
Третье поле (secret) содержит секрет, а в данном случае значение пароля, из пары к значению логина (первое поле client), для авторизации на PPTP-сервере, при запуске VPN-подключения клиентом.
Четвёртое поле (IP addresses) может содержать значение либо из выбранных и указанных вами принудительно, IP-адресов, которые входят в набор IP адресов, которые предоставит вам провайдер, как PPTP-сервер, при установке VPN-соединения, либо значение поля IP addresses должно содержать групповой символ звёздочку, что позволяет использовать абсолютно все IP-адреса, из, подготовленного PPTP-сервером для вас заранее, набора IP-адресов. Также, вы можете оставить это поле пустым, если вы захотите использовать динамическую (или статическую) выдачу IP-адреса при распределении IP-адресов вашим провайдером.
Обратите внимание, что вы не должны указывать IP-адрес в значение поля IP addresses, если вы не требуете от PPTP-сервера ПРИНУДИТЕЛЬНО выдать (по DHCP или статически) вам этот IP-адрес. Даже если вы попробуете это сделать, скорее всего у вас ничего не получится, так как большинство PPP-серверов, для защиты, не позволяют удалённой системе (client) устанавливать принудительно, произвольный на выбор, свой IP-адрес, в таком случае, IP-адреса выдаются только со стороны провайдера (PPTP-сервера, server).
Если у вас имеется только одна пара логин/пароль, то в значения полей Server и IP addresses можно указать звёздочку. В противном случае, достаточно указать различные имена PPTP-серверов (server), с соответствующей им парой логин/пароль.
В случае, если Вы используете сервер PPTP, который, скорее всего, не требует авторизации по доменным именам, не вписывайте $DOMAIN\\ в поле client, установив в значение только $USERNAME.
В случае, если пароль или остальные значения содержат какие-либо специальные символы, то значение заключают в кавычки — "ваш пароль". Для подробной информации прочитайте руководство страниц man по pppd:
# man pppd
Обратите внимание! Пароль из пары к логину хранится не в зашифрованном виде. Для большей безопасности, установим права:
# chmod 600 /etc/ppp/chap-secrets
Общий пример содержания файла /etc/ppp/chap-secrets для более наглядного понимания:
Если ваша машина (client) - fred, а удалённая (server) - barney, то ваша машина установила бы name fred remotename barney, а удалённая машина (server) установит name barney remotename fred в их соответствующих файлах /etc/ppp/options.ttySx
/etc/chap-secrets файл для fred (client) такой:
# Secrets for authentication using CHAP # client server secret IP addresses fred barney flintstone barney fred wilma
/etc/chap-secrets файл для barney (server) такой:
# Secrets for authentication using CHAP # client server secret IP addresses barney fred flintstone fred barney wilma
Обратите внимание, на то, что обе машины имеют записи для двунаправленного установления подлинности. Это позволяет локальной машине (client) называть себя на удалённой машине (server). И удалённой машине (server) называть себя на локальной машине (client).
/etc/ppp/peers/$TUNNEL
Создайте файл /etc/ppp/peers/$TUNNEL, к примеру:
# nano /etc/ppp/peers/beeline
со следующим содержимым:
pty "pptp $SERVER --nolaunchpppd" name $DOMAIN\\$USERNAME remotename PPTP file /etc/ppp/options.pptp ipparam $TUNNEL
где:
Первая строчка запускает в интерфейсе псевдотерминала (pty, pseudo terminal interface) клиент pptp для подключения к PPTP-серверу, указанному в параметре $SERVER (VPN-сервер, vpn.internet.beeline.ru), с дополнительными параметрами-ключами программы pptp.
Вторая строчка параметром name задаёт "имя локальной машины" (client), в данном случае, это - ваш логин для авторизации на сервере PPTP. Значение параметра name обязано совпадать с указанным значением в поле client файла /etc/ppp/chap-secrets, так как программа pptp, при запуске, будет считывать из файла /etc/ppp/chap-secrets построчно данные, со значениями остальных полей, сравнивая со значением параметра name, значение поля client. Иначе говоря,
ваш логин для авторизации на VPN-соединении = значение параметра name = значение параметра client
для уникального подключения $TUNNEL, из каталога с сетевыми подключениями PPP — /etc/ppp/peers/
Третья строчка параметром remotename задаёт "имя удалённой машины" (server), в данном случае, используется произвольное значение, т.н. "PPTP" или "bee". Как уже упоминалось выше, методы авторизации PAP и CHAP разработаны, чтобы опознавать компьютерные системы, а не пользователей. Разница заключается в том, что как только ваш компьютер (client) создал PPP (Point-to-Point Protocol) соединение с сервером (server), ЛЮБОЙ пользователь вашей системы может использовать это соединение - не только вы. PAP может требовать (а CHAP ТРЕБУЕТ) двунаправленного установления подлинности, то есть компьютер на каждом конце соединения, и клиент, и сервер, должен иметь правильные имя и пароль другой стороны. Поэтому значение параметра remotename обязано совпадать с указанным значением в поле server файла /etc/ppp/chap-secrets, так как программа pptp, при запуске, будет считывать из файла /etc/ppp/chap-secrets построчно данные, со значениями остальных полей, сравнивая со значением параметра remotename, значение поля server. Иначе говоря,
произвольное значение с именем удалённой машины (PPTP-сервера) = значение параметра remotename = значение параметра server
для уникального подключения $TUNNEL, из каталога с сетевыми подключениями PPP — /etc/ppp/peers/
Таким образом, в PPP достигается авторизация не только пользователей, но и машин, что позволяет использовать как одновременную общую авторизацию всех пользователей в системе на машине (как PPTP-клиенту) на одно общее VPN-подключение по PPP, так и абсолютно отдельные друг от друга VPN-подключения по PPP, с собственной авторизацией на PPTP-сервере, на каждого пользователя в системе (как PPTP-клиентам).
Четвёртая строчка просто подключает отдельный внешний файл /etc/ppp/options.pptp с общими настройками для PPTP, в текущий файл. В том случае, если вам потребуется изменить параметры настройки для вашего каждого отдельного PPTP-соединения, просто меняйте параметры в текущем файле. Вы можете добавить в настройку отдельного каждого соединения такие параметры, как:
persist - для переподключения после обрыва подключения
Пятая строчка назначает параметр ipparam, значение которого (в переменной $6 ($PPP_IPPARAM)), получат скрипты /etc/ppp/ip-up (при запуске VPN-соединения) и /etc/ppp/ip-down (при остановке VPN-соединения). На практике, обычно, в значение параметра ipparam удобно указать название подключения, и затем, принудительно подключить файлы с одноимённым названием подключения, из каталогов /etc/ppp/ip-up.d/ и /etc/ppp/ip-down.d/, вставив в соотвествующие файлы со скриптами:
sh /etc/ppp/ip-up.d/$6 — в /etc/ppp/ip-up
и
sh /etc/ppp/ip-down.d/$6 — в /etc/ppp/ip-down
В случае, если вы планируете по VPN-подключению использовать доступные узлы с другой стороны PPTP-сервера, вместо доступных имеющихся, то наиболее удобным вариантом для вас будет указание в значение параметра ipparam - старого маршрута до имеющихся доступных узлов, который вы на время подключения замените, для доступности узлов за PPTP-сервером, на новый. Список маршрутов, составляющий таблицу маршрутизации, можно узнать командой:
# ip route
В случае, если Вы используете сервер PPTP, который, скорее всего, не требует авторизации по доменным именам, не вписывайте $DOMAIN\\ во вторую строчку, установив в значение параметра name только $USERNAME.
Маршрутизация (Роутинг)
Как только вы запустили подключение по PPTP туннелю, проверьте доступность узлов с другой стороны туннеля. Особенность подключения к провайдерам заключается в том, что PPTP-сервер (т.н. VPN-сервер "vpn.internet.beeline.ru") находится не в одной подсети с вами, и этот сервер вам доступен через стандартный шлюз (default gateway, шлюз по-умолчанию). Когда интернет отключён, VPN-подключение по PPTP-туннелю остановлено, маршрутом по-умолчанию (default route) в таблице маршрутизации является маршрут на default gateway. Посмотреть маршрут по-умолчанию default route, указывающий на default gateway, можно при помощи команд:
# route -n
и
# netstat -nr
Для доступности узлов с другой стороны туннеля, которые находятся за PPTP-сервером, иначе говоря, для установки связи с Интернетом, необходимо, чтобы маршрут по-умолчанию default route указывал на шлюз, отвечающий за доступность узлов за PPTP-сервером, то есть, на образующийся при VPN-подключении, интерфейс ppp0.Следующая команда удалит маршрут по-умолчанию default route, который указывает на default gateway:
# route del default
затем нам понадобится создать новый маршрут по-умолчанию default route, но уже указывающий на шлюз, предоставляющий вам доступность узлов с другой стороны туннеля:
# route add default gw шлюз
или вы также можете создать новый маршрут по-умолчанию default route, указывающий на интерфейс ppp0:
# route add default dev ppp0
если установилось VPN-соединение, что можно проверить командой:
# ifconfig -a | grep inet
Для того, чтобы после каждого запуска и остановки VPN-подключения вам не приходилось вручную менять маршрут по-умолчанию default route, есть два решения:
- параметр defaultroute/replacedefaultroute
- скрипты в каталогах /etc/ppp/ip-up.d/ и /etc/ppp/ip-down.d/
Для этого в настройке pppd нужно прописывать параметр defaultroute. Проблема в том, что в некоторых релизах pppd отказывается замещать default route на новый default gateway, говоря при этом: will not replace defaultroute.
В таких случаях, можно добавить недокументированный параметр replacedefaultroute, благодаря которому, всякие манипуляции, с удалением маршрутов по-умолчанию default route на default gateway, становятся ненужными. Однако, этот параметр работает не во всех релизах pppd.
Когда устанавливается VPN-подключение по PPTP туннелю, маршрут по-умолчанию default route указывает на PPTP-сервер, доступный по интерфейсу ppp0. В связи с замещением этим маршрутом по-умолчанию предыдущего default route, система не знает, как добраться до PPTP-сервера, так как он недоступен, исходя из таблицы маршрутизации.
# route -n
Поэтому маршрут до PPTP-сервера нужно прописать в таблице маршрутизации вручную. Следующая проблема заключается в том, что PPTP-серверов у каждого провайдера много, и их список (nslookup vpn.internet.beeline.ru) постоянно меняется. Выводы:
- Отслеживайте любые изменения в вашей таблице маршрутизации и вносите только тщательно проверенные и правильные маршруты.
- Используйте скрипты для автоматического управления маршрутами вместо добавления постоянных маршрутов.
Для использования автоматического управления маршрутами через скрипты, воспользуйтесь файлами, содержащими скрипты /etc/ppp/ip-up и /etc/ppp/ip-down
После того, как связь установлена - скрипт /etc/ppp/ip-up
Как только связь PPP установлена, pppd ищет /etc/ppp/ip-up. Если этот скрипт существует и является исполняемым, то pppd выполняет скрипт. Скрипт позволяет вам автоматизировать любые специальные команды маршрутизации, которые могут вам понадобиться, и любые другие действия, которые вы хотите выполнить при активации соединения PPP.
Файл всего лишь является shell скриптом, и он может делать всё, что может делать shell скрипт (то есть фактически всё что вы захотите). Например, вы можете заставить sendmail послать исходящую почту, стоящую в очереди. Точно так же, вы можете вставить команды в скрипт ip-up для проверки почты (используя POP), ожидающей вашей проверки в вашем почтовом ящике.
Имеются следующие ограничения на /etc/ppp/ip-up:
Для усиления защиты он выполняется в преднамеренно ограниченном окружении. Это означает, что вы должны указывать полный путь к запускаемым файлам внутри скриптов и т.д. Технически /etc/ppp/ip-up - это программа, а не скрипт. Это означает, что он может быть всё таки выполнен - и следовательно, ему потребуется стандартный файл (#!/bin/bash) в начале первой строки скрипта, также он должен быть читаемым и исполняемым от пользователем root.
Если вы связываете две локальных сети, вы должны будете установить специфические маршруты к 'посторонней' локальной сети. Это легко сделать используя скрипт /etc/ppp/ip-up. Единственая трудность возникает, если ваша машина работает с несколькими PPP соединениями. Потому, что /etc/ppp/ip-up выполняется для КАЖДОГО ppp соединения, которое устанавливается, так что, вы должны тщательно проверить на правильность команды маршрутизации для определённого устанавливаемого соединения - и не выполнять их, когда устанавливается любое другое соединение.
После того, как связь завершена - скрипт /etc/ppp/ip-down
Вы можете создать скрипт, который будет выполняться, как только связь будет завершена. Он называется /etc/ppp/ip-down. Он может использоваться, чтобы отменить что-нибудь, что вы сделали в соответствующем скрипте /etc/ppp/ip-up. Например, вернуть прежние маршруты или правила iptables.
Помните, скрипт - это только стандартный скрипт bash и может использоваться так, чтобы автоматизировать ЛЮБУЮ функцию, которую нужно выполнять каждый раз, при установке соответствующего PPP соединения.
Использование
Тоннель VPN запускается командой pon:
# pon $TUNNEL
для примера:
# pon beeline
Тоннель останавливается командой poff:
# poff $TUNNEL
для примера:
# poff beeline
Автоматическое подключение тоннеля VPN при загрузке системы
Для автоматического подключения при загрузке следует добавить в /etc/network/interfaces следующую запись:
auto ppp0
iface ppp0 inet ppp
provider $TUNNEL # (/etc/ppp/peers/MY_PEER)Если в локальной сети используется DHCP, то в некоторых случаях PPTP-соединение инициализируется еще до того, как были получены настройки от DHCP-сервера. В этом случае /etc/network/interfaces следует изменить таким образом, чтобы PPTP-соединение устанавливалось только после полной инициализации ethernet-соединения:
iface eth0 inet dhcp
post-up ifup ppp0
down ifdown ppp0
iface ppp0 inet ppp
provider $TUNNEL
Известные проблемы и их решение
Если у вас в процессе использования "PPTP Client" возникнет проблема, то вполне возможно, что решение проблемы вы найдёте на страничке Руководства по диагностике "PPTP Client"
В большинстве случаев, новички, при запуске PPTP-подключения к провайдеру, для установки VPN-соединения с Интернет, столкнутся с проблемой маршрутизации, которая заключается в том, чтобы на момент активности PPTP-подключения, заменить старые маршруты на новые, а после завершения PPTP-подключения - заменить новые маршруты обратно на старые. Правильный выход из данной ситуации был описан выше, в разделе "Маршрутизация (Роутинг)". При настройке pppd, использование параметров defaultroute и replacedefaultroute не рекомендуется, во избежание возможных и никому не нужных проблем с маршрутами на машине.
Также, при возникновении проблем после переподключения PPTP-подключения (pon,poff,pon,...) можете добавить в скрипт /etc/ppp/ip-down следующее:
ifdown eth0 ifup eth0
где eth0 - это интерфейс вашей сетевой карточки, через который, в таблице маршрутизации, доступен PPTP-сервер.
На практике, обычно, также вы можете заметить, просматривая, в процессе хода работы программы PPTP, файл /var/log/syslog, что он переполнен сообщениями типа
non log[decaps_gre:pptp_gre.c:414]: buffering packet
от программы PPTP.
Комментарий разработчика доступен по ссылке buffering_out_of_order, а ниже приводится перевод:
буферизация "out-of-order" ("не в обычном порядке") пакета
Признак: при работе pptp, появляется это сообщение, которое, возможно, связано и с любым другим событием:
log[decaps_gre:pptp_gre.c:397]: buffering out-of-order packet 272 (expecting 271)
Диагноз: это - нормальная ситуация. Множество сетевых соединений блокирует или меняет порядок следования пакетов в общем потоке пакетов - это обычная нормальная штатная ситуация как часть в их работе. Данное сообщение информирует вас о том, что пакет был потерян или у него был изменён порядок следования в общем потоке пакетов. Сетевая инфраструктура TCP (в модели OSI), которая находится выше этого уровня, ретранслирует потерянные данные.
(фраза "out-of-order" ("не в обычном порядке") в этом контексте относится к последовательности пакетов, и не должна быть перепутана с использованием фразы в некоторых переводах на другие языки для предупреждения о неработоспособности общедоступного оборудования.)
Решение: если потери пакетов происходят на уровне выше, чем физический уровень (в модели OSI), проверьте физический уровень (в модели OSI) на наличие возможных проблем.
Вы можете также использовать возможность подсчёта статистики PPTP-соединения, для получения и понимания статистики смотрите руководство страниц man.
Собственно, если проблем на вашем физическом уровне — нет, это не исключает наличие проблем на физическом уровне PPTP-сервера, т.н. провайдера.
Чтобы запретить запись сообщений в лог syslog, раздумывая кто виноват — проблемы физического уровня провайдера или проблемы "PPTP Client" (в любом случае, не проблемы службы, реализующей протокол точка-точка, ppp), добавьте параметр-ключ --loglevel 0 (уровень записи в лог, 0=низкий, 1=по-умолчанию, 2=высокий) в запуск программы pptp интерфейсом псевдотерминала pty (файл "/etc/ppp/$TUNNEL").
Параметр-ключ --timeout установит время для ожидания перед восстановлением пакетов в общем потоке (от 0.01 до 10 секунд). Добавление параметра-ключа --nobuffer позволит вам полностью отключить буферизацию и восстановление пакетов в общем потоке, при этом любое значение параметра-ключа --timeout будет проигнорировано.
Заметьте, что сообщений очень много, что увеличивает файл syslog до огромных размеров, а это значит, что сообщение, добавленное в файл syslog, пишется после удачной проверки каждого "out-of-order" ("не в обычном порядке") пакета, и скорость VPN-соединения из-за этого снижается очень значительно, что не наблюдается при использовании, основанного на netgraph(4), аналога "PPTP Client" — mpd для операционной системы FreeBSD.
Универсального и единого решения для данной проблемы — нет, и если вас не устраивает текущая ситуация, то используйте альтернативы "PPTP Client" (в любом случае, не службы, реализующей протокол точка-точка, ppp), т.н. уточните, а использует ли VPN-сервер (vpn.internet.beeline.ru ), совместно с PPTP, протокол L2TP ?
И если ответ от техподдержки был — да, посмотрите описание настройки VPN-подключения по протоколу L2TP с помощью openl2tp — здесь, и с помощью демона xl2tpd — здесь.
Если у вас имеется какая-то другая проблема при работе с "PPTP Client", то вполне возможно, что решение проблемы вы найдёте на страничке Руководства по диагностике "PPTP Client"
Ссылки
netinstall — Сетевая установка с минимальным компакт-диском
Руководство APT — Добавление CD-ROM в файл sources.list
Клиент PPTP — Официальный сайт "Клиент PPTP", клиент Linux, FreeBSD, NetBSD и OpenBSD для протокола от Microsoft — Point-to-Point Tunneling Protocol, PPTP
Клиент PPTP — Руководство по использованию в Debian
Клиент PPTP — Руководство по диагностике "PPTP Client"