Для настройки собственно VPN-соединения, потребуются пакеты: ppp, pptpclient и некоторые зависимости.

Установка:

# pacman -S ppp pptpclient

Менеджер пакетов установит необходимые и ещё несколько зависимых пакетов. Эти пакеты находятся на установочном компакт-диске, поэтому менеджер попросит вставить этот диск.

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

После установки пакета ppp, будет создан каталог /etc/ppp , где собственно и будут содержаться файлы, управляющие PPP- и в частности VPN- -соединениями.

Теперь нужно создать или изменить некоторые файлы. Естественно, это нужно делать из под учётной записи root`а.

Редактируем или создаём файл конфигурации собственно соединения. Назовём его "provider" и поместим в /etc/ppp/peers . Пример файла:

peers

pty "pptp 10.0.0.1 --nolaunchpppd"
user "user"
password "user-007"
require-mschap
noauth
nobsdcomp
nodeflate
nomppe
mtu 1372
mru 1372
defaultroute
lcp-echo-failure 10

Несколько слов о том, что значат все эти непонятные опции:

Прим.
* Опция defaultroute требует дополнительных комментариев. Если провайдер предоставляет услуги доступа в сеть Интернет через NAT И при этом не устанавливает в транспортной сети основной шлюз (для сетевого адаптера компьютера), то опцию следует выставить. Если в транспортной сети основной шлюз указывается, то опция defaultroute не сработает и основной шлюз в VPN-сети не установится.

Когда файл создан (модифицирован) и скопирован в /etc/peers , нужно выставить необходимые права доступа для ограничения доступа к учётным данным, хранимым в файле. Читать и модифицировать файл следует разрешить только пользоватею root. В консоли, это делается примерно так:

Переходим в каталог и просматриваем его:

# cd /etc/ppp/peers/
# ls -l
total 1
-rw-rw-rw- 1 user user 221 Sep 19 11:08 provider

Изменяем владельца файла provider, а затем меняем права доступа:

# chown root:root provider
# chmod 600 provider

Проверяем результат:

# ls -l
-rw------- 1 root root 221 Sep 19 11:08 provider

Теперь доступ к учётным данным может получить только пользователь root. Можно сделать несколько файлов с разными именами и параметрами для доступа к больше чем одному провайдеру и запускать соединение к нужному. В примере выше, были даны базовые опции конфигурации VPN. Если Вы хотите углубиться в настройку и больше узнать об опциях, загляните в man pppd.

Пробуем запустить наше соединение для начала от имени root`а:

# pon provider

Как Вы уже догадались, pon - активирует соединение с провайдером, сконфигурированным в файле /etc/ppp/peers/providers

Через 3…5 секунд читаем последние события лога /var/log/daemon.log на предмет ошибок. Это можно сделать через команду tail или воспользоваться файловым менеджером типа Midnight Commander, запущенным от имени root`а. Последние события лога будут выглядеть примерно так:

...
Dec 27 22:32:47 comp pppd[[3151]]: pppd 2.4.5 started by root, uid 0
Dec 27 22:32:47 comp pppd[[3151]]: Using interface ppp0
Dec 27 22:32:47 comp pppd[[3151]]: Connect: ppp0 <--> /dev/pts/4
Dec 27 22:32:47 comp pptp[[3152]]: anon log[[main:pptp.c:314]]: The synchronous pptp option is NOT activated
Dec 27 22:32:47 comp pptp[[3156]]: anon log[[ctrlp_rep:pptp_ctrl.c:251]]: Sent control packet type is 1 'Start-Control-Connection-Request'
Dec 27 22:32:47 comp pptp[[3156]]: anon log[[ctrlp_disp:pptp_ctrl.c:739]]: Received Start Control Connection Reply
Dec 27 22:32:47 comp pptp[[3156]]: anon log[[ctrlp_disp:pptp_ctrl.c:773]]: Client connection established.
Dec 27 22:32:48 comp pptp[[3156]]: anon log[[ctrlp_rep:pptp_ctrl.c:251]]: Sent control packet type is 7 'Outgoing-Call-Request'
Dec 27 22:32:48 comp pptp[[3156]]: anon log[[ctrlp_disp:pptp_ctrl.c:858]]: Received Outgoing Call Reply.
Dec 27 22:32:48 comp pptp[[3156]]: anon log[[ctrlp_disp:pptp_ctrl.c:897]]: Outgoing call established (call ID 0, peer's call ID 27136).
Dec 27 22:32:52 comp pppd[[3151]]: CHAP authentication succeeded
Dec 27 22:32:52 comp pppd[[3151]]: CHAP authentication succeeded
Dec 27 22:32:52 comp pppd[[3151]]: Cannot determine ethernet address for proxy ARP
Dec 27 22:32:52 comp pppd[[3151]]: local  IP address 172.16.1.81
Dec 27 22:32:52 comp pppd[[3151]]: remote IP address 172.16.0.1

- это лог нормально состоявшегося соединения.

Теперь проверим, появился ли в списке сетевых адаптеров VPN-адаптер. Сделать это можно командой ifconfig без параметров:

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:30:25:B1:9E:A6  
          inet addr:10.0.0.25  Bcast:10.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:21554 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15437 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:7894630 (7.5 Mb)  TX bytes:1877575 (1.7 Mb)
          Interrupt:20 Memory:d0300000-d0320000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:94 errors:0 dropped:0 overruns:0 frame:0
          TX packets:94 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:10336 (10.0 Kb)  TX bytes:10336 (10.0 Kb)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:172.16.1.81  P-t-P:172.16.0.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1372  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:42 (42.0 b)  TX bytes:48 (48.0 b)

Обратите внимание, что помимо аппаратной сетевой карты eth0 и интерфейса обратной связи, появился адаптер ppp0 - это и есть адаптер VPN-соединения. Проверить прохождение пакетов именно в VPN-канале можно командой ping:

# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
64 bytes from 172.16.0.1: icmp_seq=1 ttl=64 time=28.4 ms
64 bytes from 172.16.0.1: icmp_seq=2 ttl=64 time=13.4 ms
64 bytes from 172.16.0.1: icmp_seq=3 ttl=64 time=5.28 ms
64 bytes from 172.16.0.1: icmp_seq=4 ttl=64 time=23.9 ms
64 bytes from 172.16.0.1: icmp_seq=5 ttl=64 time=29.1 ms
^C
--- 172.16.0.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 5.288/20.066/29.151/9.269 ms
^C

Здесь, адрес 172.16.0.1 - это адрес удалённого конца VPN-соединения. В Вашем случае, он может быть другим. Как видно пинг проходит, значит VPN-соединение работает. Отключаем соединение:

# poff provider

Здесь poff - даёт команду на завершение работы, а provider - Вы уже знаете

Когда соединение настроено и проверено, нужно сконфигурировать операционную систему так, чтобы запускать соединение не от имени учётной записи root`а, а от имени обычного пользователя. Здесь поможет статья Настройка sudo - отредактируйте файл /etc/sudoers до примерно такого вида:

sudoers

root ALL=(ALL) ALL 
Host_Alias LOCALHOST = localhost, compname
username LOCALHOST = NOPASSWD: /usr/bin/poff, /usr/bin/pon

, где вместо compname - подставьте своё имя компьютера, username - имя пользователя, который будет манипулировать VPN-соединением.

Теперь можно запускать\останавливать соединение от имени пользователя, указанного вместо username:
запуск

$ sudo pon provider

останов

$ sudo poff provider

На этом настройку vpn-соединения можно считать завершённой.

Поскольку провайдеров в мире много, у каждого могуть быть свои особенности в настройке VPN (PPTP) соединения. Ниже приведены некоторые дополнительные опции для файла конфигурации соединения.

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

• Обсуждение статьи на форуме