Создание VPN с использованием протоколов PPP и SSH

2005 г.

Создание VPN с использованием протоколов PPP и SSH

Глава 3 из книги "LINUX. Создание виртуальных частных сетей (VPN)"

Олег Колесников, Брайан Хетч,
Издательство "КУДИЦ-ОБРАЗ"

Глава 3

Обзор сочетания «PPP через SSH»
Как насчет документации?
Установка «PPP через SSH» вручную
Повышение безопасности VPN
Скрипты VPN
Поиск проблем
Ограничения
Заключение

Одним из первых VPN решений, предназначенных для самостоятельного воплощения, было соединение двух сетей с помощью протокола PPP в сессии SSH. Этот метод является общепринятой практикой, однако он может показаться несколько тяжеловесным новичку в использовании данных протоколов. Когда вы закончите чтение этой главы, вы сможете создать сеть VPN на основе SSH/PPP и вручную, и с помощью набора предлагаемых нами скриптов.

Обзор сочетания “PPP-через-SSH’

Чтобы лучше понять реализацию «PPP-через-SSH» давайте обсудим эти два протокола.

PPP

PPP представляет собой аббревиатуру от Point-to-Point Protocol (Протокол передачи «от точки к точке»). Этот протокол является производным HDLC (High Level Data Link Control, Высокоуровневый Протокол Управления Каналом) – еще одного протокола типа «от точки-к-точке» 2-го уровня, который используется для осуществления управления каналом и инкапсуляции пользовательских данных. Чаще всего протокол PPP используется для установления связи между модемами по телефонной линии, например, при вызове провайдера. В большинство дистрибутивов Linux включаются такие утилиты, как wvdial или xisp, позволяющие установить модемное соединение не вдаваясь в детали команд PPP и конфигураций, на основе которых они работают. Однако PPP не ограничивается только физическими соединениями, соединения по протоколу PPP могут быть установлены между любыми хостами, имеющими сетевую связь. Нашей целью будет устанавливать PPP-соединения между различными машинами через Интернет, которые мы будем использовать для создания VPN.

Чтобы запустить утилиту pppd, демон протокола PPP, нужно, чтобы ядро поддерживало его. Часто PPP компилируется в модуль, запросы к которому можно подавать командой lsmod. Если это так, он будет загружаться автоматически при необходимости. Ядро в большинстве дистрибутивов Linux включает поддержку PPP, так что это не должно быть проблемой.

Большинство дистрибутивов Linux также поставляется с предварительно откомпилированными версиями PPP, которые можно установить. Так что вам, скорее всего, не придется компилировать и инсталлировать pppd самостоятельно. Однако по причинам, о которых будет рассказано далее, мы предлагаем использовать версию pppd 2.3.7 и выше.

Обеспечение конфиденциальности передаваемых данных никогда не было главной целью протокола PPP. И как следствие, он использует для этой цели внешние методы шифрования. Риск перехвата данных при использовании данного протоколе сводится к возможности подключения к линии или захвата одного из концов PPP-соединения. Тем не менее, поскольку мы хотим использовать PPP для установления сетевого соединения при пересылке потока данных через Интернет, мы должны провести PPP-соединение через шифрованный туннель.

SSH

Протокол SSH (Secure Shell, безопасная оболочка) чаще всего используется для создания безопасной оболочки для доступа к другим хостам и передачи файлов по сети, для безопасности аутентификации и для обеспечения конфиденциальности данных. Он был разработан как безопасная замена Telnet и так называемых r-команд (rlogin, rsh и rcp).

В SSH поддерживается мощное шифрование и продвинутые методы идентификации пользователей, которые прошли проверку временем. OpenSSH, реализация протокола SSH, созданная группой разработчиков OpenBSD и перенесенная на Linux из той же OpenBSD, включается сейчас по умолчанию во многие дистрибутивы Linux. SSH сейчас «де факто» является безопасным методом входа в систему и передачи файлов в Unix-подобных системах.

Существуют, также, программные реализации SSH, выполненные другими производителями, например, ssh.com. Мы, тем не менее, отдаем предпочтение OpenSSH, поскольку он поставляется во многих дистрибутивах Linux, его легче конфигурировать, его версии более совместимы между собой и в нем поддерживается и версия 1 и версия 2 протокола SSH. Используемые в данной главе настройки предполагают, что вы используете OpenSSH.

Версии протокола

С момента создания протокола SSH в 1995 году, было выпущено несколько различных его версий, главными из которых являются версия 1.5 (также называемая SSH1) и версия 2 (SSH2). OpenSSH 2.0, выпущенный в июне 2000 года изначально поддерживает оба протокола. (Коммерческие реализации SSH также могут поддерживать обе версии, но только путем запуска при необходимости демона sshd для версии 1, что сильно снижает производительность.)

Эти два протокола SSH не совместимы между собой, и следует определиться с тем, какой вариант вы предпочтете. В протоколе SSH1 временами возникают проблемы с безопасностью. Даже сейчас остается теоретическая возможность «атаки включением» (insertion attack) против этого протокола, но этот риск сводится к минимуму специальной заплаткой (patch) выпущенной CORE-SDI еще в 1998 году. Протокол SSH1 дольше использовался и для него существует обширная база поддержки. В SSH1 поддерживается только ассиметричное шифрование RSA, запатентованное в США в 2000 году. Однако, поскольку срок действия этого патента уже истек, это больше не проблема.

SSH2 – более новый и богатый возможностями протокол, который пока успешно выдерживает все проверки. Хотя установление соединения по протоколу SSH2 требует намного больше времени, в последних версиях OpenSSH этот процесс существенно ускорен. SSH2 поддерживает ассиметричные алгоритмы RSA и DSA.

Независимо от того, какую версию протокола вы выберете, убедитесь в том, что вы используете самую последнюю версию OpenSSH. Время от времени в OpenSSH обнаруживались слабые места, такие, например, как две отдельные прорехи «UseLogin» или ошибка переполнения целого числа в анти-хакерской заплатке которая могла привести к вскрытию пользователя root. Однако разработчики OpenSSH сделали намного больше для безопасности, чем их коллеги, разработавшие SSH. OpenSSH включает в себя контрмеры даже на случай таких эзотерических атак, как определение времени нажатия клавиш (keystroke timing), когда атакующий анализирует интервалы между пакетами, определяя, таким образом, насколько близко расположены нажимаемые вами клавиши и пытается по этому показателю понять, что вы печатаете.

Мы будем использовать идентификаторы (identities) SSH (ассиметричные криптографические ключи, используемые при аутентификации и подробно описываемые ниже) для обеспечения разрешения на соединение VPN-клиента с VPN-сервером. К сожалению, формат этих идентификаторов в протоколе SSH1 отличается от SSH2. Поэтому, хотя OpenSSH и поддерживает обе версии протоколов, нам придется решить, какой из них мы хотим использовать для нашей VPN. Если у вас есть самая последняя версия OpenSSH (а у вас она должна быть), мы предлагаем использовать SSH2. Мы подробно опишем создание SSH-идентификаторов для обоих протоколов, так что выбор остается за вами.

Наш образец сети

Теория проста – установить SSH-соединение VPN-клиента с VPN-сервером и запустить на обоих концах соединения демоны PPP, которые, общаясь друг с другом, и создадут нашу VPN. Мы создадим VPN между хостами Bears (VPN-сервер) и Falcons (VPN-клиент), как это показано на Рис. 3.1.

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

Как насчет документации?

Авторитетным справочным пособием по установлению соединения «PPP-через-SSH» является VPN-HOWTO для Linux, написанное в 1997 году и доступное по адресу www.linuxdoc.org/HOWTO/mini/VPN.html. К сожалению к настоящему времени этот документ несколько устарел и в нем предполагается, что вы уже хорошо знакомы с этими протоколами и теориями.

Перевод рис 3.1 на странице 70

Bears VPN Server VPN-сервер Bears

Falcons VPN Client VPN-клиент Falcons

sshd server listens on port 9876 сервер sshd опрашивает порт 9876

Bears' sshd server listens on port 9876 for inbound requests from falcons and launches pppd для установления сетевого соединения Сервер sshd на машине Bears опрашивает порт 9876 на предмет входящих запросов от Falcons и загружает pppd для установления сетевого соединения.

Falcons pppd process connects to Bears via ssh процесс pppd на машине Falcons связывается с Bears через ssh .

Рисунок 3.1 Наша сеть VPN.

Мы покажем как создать VPN с помощью тех же протоколов, но более подробно и с использованием некоторого числа возможностей, не описанных и обсуждаемых в HOWTO, в частности:

И клиент и сервер запускают свои программы от лица фиктивного пользователя (не root). Хорошей практикой с точки зрения безопасности является как можно меньшее использование root.
На сервер накладываются ограничения, предотвращающие вход фиктивного пользователя в систему, что могло бы быть использовано для получения дополнительных привилегий.
Сервер контролирует почти все аспекты соединения, что приводит к тому, что в конфигурировании нуждается только одна машина.
Больше не нужно использовать метод pty-redir, описанный в HOWTO.
Выделенный SSH-сервер с ограничивающей конфигурацией позволяет не использовать и не полагаться на действительный SSH-сервер, используемый обычными пользователями.
Описываются протоколы SSH1 и SSH2 и идентификаторы (identities).
Обсуждается верификация ключей на SSH-хостах, позволяющая избежать атаки типа «man-in-the-middle» (кто-то посередине).
Аутентификация PPP (PAP/CHAP, дополнительный пароль), обеспечивает еще один уровень аутентификации в VPN.
Новые, VPN-зависимые маршруты будут добавлены автоматически при помощи скрипта ip-up после установления VPN-соединения.

Самая большая проблема при использовании VPN-HOWTO – это то, что эта документация была написана для более старой версии pppd. Как мы опишем позже, pppd требует наличия tty , через который осуществляется связь. Метод pty-redir использовался для того, чтобы предоставить tty, через который можно установить соединение. Теперь это делается более аккуратно – при помощи аргумента pty для pppd. Также, при помощи скрипта ip-up, который вызывается после установления соединения, мы немедленно можем добавить маршруты. Большая часть других методов VPN, связанных с PPP, используют команду sleep 10, которая ожидает завершения установления PPP-соединения перед тем, как перейти к добавлению маршрутов, что может привести к задержке VPN, если PPP установится быстро или может привести к неверной установке маршрутов, если установка PPP-соединения займет определенное время.

Установка «PPP-через-SSH» вручную

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

Инсталляция и проверка PPP

Во-первых, определим, установлен ли PPP и на VPN-клиенте и на VPN-сервере. В Debian или других системах, основанных на dpkg, нужно ввести следующее:

root@debian$ dpkg -l ppp |grep ppp
ii ppp  2.3.11-1.4 Point-to-Point Protocol (PPP) daemon.

В RedHat или других системах, основанных на rpm, нужно ввести следующее:

root@redhat# rpm -q ppp
ppp-2.3.11-4

Убедитесь, что установлена версия 2.3.7 или выше, поскольку это первая версия, поддерживающая аргумент pty, необходимый для автоматической установки pty.

Включение маршрутизации IP

Большинство дистрибутивов Linux по умолчанию не разрешают маршрутизацию IP-пакетов, но нам оно необходимо для маршрутизации пакетов VPN через интерфейс PPP. Изменять статус маршрутизации IP можно, изменяя соответствующий параметр ядра. Хотя возможно перекомпилировать ядро и изменить значения, установленные по умолчанию, наиболее легкий способ – использовать файловую систему /proc. Файлы в /proc, в действительности, файлами не являются, а представляют собой способы доступа и/или модификации параметров ядра и для того, чтобы изменить их вы должны иметь статус root. Таким образом, простейший способ включить маршрутизацию через порт – запустить следующую команду:

root# echo 1 > /proc/sys/net/ipv4/ip_forward

Эта команда автоматически включит маршрутизацию IP-пакетов по умолчанию во всех интерфейсах. При создании VPN архитектуры хост-хост это существенно. Если вы желаете создать VPN типа сеть-сеть или хост-сеть, вам может понадобиться включить маршрутизацию IP-пакетов только для тех интерфейсов, через которые и осуществляется маршрутизация. Например, в случае большого VPN-сервера вам может понадобится осуществлять маршрутизацию через все интерфейсы ppp (связи VPN) и через интерфейс eth1 (внутренний интерфейс), но не через все интерфейсы Ethernet. Это можно сделать, используя следующий скрипт shell:

#!/bin/sh

echo “Setting up IP forwarding rules”
echo 1 > /proc/sys/net/ipv4/ip_forward
echo -n “/proc/sys/net/ipv4/ip_forward: “
cat /proc/sys/net/ipv4/ip_forward
for forwarding in /proc/sys/net/ipv4/conf/*/forwarding
do
 echo -n “$forwarding: “;

 interface=`dirname $forwarding`
 interface=`basename $interface`

 case “$interface” in
       ppp*|eth1)  # список интерфейсов
            # прохождение через которые нужно включить
            echo 1 > $forwarding
            ;;

      *)    # Выключить прохождение для всех интерфейсов
            echo 0 > $forwarding
            ;;
 esac

 cat $forwarding
done

Обязательно настройте выражения в операторе case в соответствии с вашими требованиями к маршрутизации IP-пакетов. В данном случае разрешается маршрутизация пакетов через интерфейс eth1 и все ppp-интерфейсы (ppp0, ppp1, …), а для всех прочих интерфейсов пакеты будут отбрасываться.

Создание пользователя VPN

Теперь необходимо создать пользователя, который будет запускать команды VPN на обоих концах соединения. Предположим, вы используете для обоих концов имя пользователя sshvpn, но можно использовать и любое другое. Хотя имена пользователей не обязательно должны быть одинаковы для обеих машин, это значительно упрощает дело. Пользователя можно создать, например, таким образом:

root# groupadd sshvpn
root# useradd -m -d /opt/ssh-vpn -c 
      “SSH VPN User” -g sshvpn sshvpn

Программа useradd создает пользователя с паролем, закрытым по умолчанию, что гарантирует невозможность подключиться через него к системе. Единственный способ доступа к этим учетным записям является использование команды /bin/su для получения прав root. Позже мы создадим особый доступ к этим пользователям через протокол SSH. Домашний каталог для этого пользователя традиционный - /opt/ssh-vpn. Хотя мы и могли создать домашний каталог в /home, но этот пользователь будет скорее использоваться в качестве программного продукта и установка его в каталог /opt (или /usr и т п.) более соответствует его назначению. Так что в дальнейшем мы будем использовать каталог /opt/ssh-vpn, а вы можете использовать какой угодно.

Соглашения об именах

Для ясности мы назовем ту машину, которая начинает процесс соединения VPN-клиентом, а другую – VPN-сервером. VPN-клиент для соединения с VPN-сервером будет использовать протокол SSH.

Также мы должны дать нашей VPN какое-нибудь имя. Для примера, мы будем использовать имя vpn1. Поскольку наши скрипты могут создавать более одной VPN, такое имя позволит их различать.

Установление беспарольного SSH-соединения

Наш пользователь VPN на VPN-клиенте должен иметь возможность соединяться с VPN-сервером без пароля. Этого можно добиться с помощью SSH несколькими различными способами. Есть два стандартных метода – хостовая аутентификация и аутентификация по идентификатору SSH. Прочие методы, например, kerberos, обычно требуют значительных усилий по обслуживанию и их трудно использовать в ситуациях, подобных нашей.

Хостовая аутентификация использует установление доверительных взаимоотношений между хостами. В данном случае любой пользователь одного хоста (клиент) может без пароля соединиться с другим хостом (сервером). Если не слишком вдаваться в детали, то при этом копия публичного хостового SSH-ключа клиента устанавливается на сервер в /etc/ssh/ssh_known_hosts, а имя клиентской машины записывается в /etc/shosts.equiv. При соединении клиента с сервером, представляемый клиентом ключ сравнивается с ключом, хранящимся в файле. Если ключи совпадают, сервер заключает, что клиент имеет право доступа и соединение без пароля разрешается. Позже, при установлении соединения, мы увидим, как работают хостовые ключи SSH. Если вы желаете использовать хостовую аутентификацию в других проектах, обратитесь за информацией к руководству по sshd.

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

Идентификатор (identity) SSH - это просто пара из публичного и приватного ключа, располагающаяся на машине – клиенте. С сервером может соединиться любой пользователь, обладающий верным идентификатором, и поместивший свой публичный ключ в файл $HOME/.ssh/authorized_keys на SSH-сервере. Обычно идентификаторы создаются таким образом, что для их использования нужна идентификационная фраза (passphrase, многословный вариант пароля).

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

Создание идентификатора SSH

Для начала нужно создать идентификатор SSH на VPN-клиенте. Станем пользователем sshvpn и создадим каталог .ssh:

root@falcons-client# su - sshvpn
sshv
pn@falcons-client$ pwd
/opt/ssh-vpn
sshvpn@client$ mkdir .ssh
sshvpn@client$ chmod 700 .ssh

Если вы хотите использовать протокол SSH1, для создания беспарольного идентификатора SSH в ~/.ssh/identity используйте следующие команды:

sshvpn@falcons-client$ ssh-keygen -t rsa1 -N ‘’
Generating public/private rsa1 key pair.
En
ter file in which to save the key (/opt/ssh-vpn/.ssh/identity):
Your identification has been saved in /opt-ssh-vpn/.ssh/identity.
Your public key has been saved in /opt/ssh-vpn/.ssh/identity.pub.
The key fingerprint is:
a8:28:08:2b:3c:b3:52:13:26:f0:ac:5e:43:df:20:fb sshvpn@client

Если вы хотите использовать протокол SSH2, для создания беспарольного идентификатора DSA SSH в ~/.ssh/id_dsa используйте следующие команды:

sshvpn@falcons-client$ ssh-keygen -t dsa -N ‘’ 
Generating public/private dsa key pair.
Enter file in which to save the key (/opt/ssh-vpn/.ssh/id_dsa):
Your identification has been saved in /opt/ssh-vpn/.ssh/id_dsa.
Your public key has been saved in /opt/ssh-vpn/.ssh/id_dsa.pub.
The key fingerprint is:
6c:e7:e7:bb:71:da:68:8c:d8:5f:ae:e0:90:e6:c8:d2 sshvpn@client

Если желаете, можно создать для протокола SSH2 идентификатор RSA, используя параметр -t rsa. Для нашей задачи не имеет значения, какой идентификатор вы используете, но мы предположим, что вы используете идентификатор DSA.

Создание идентификаторов для нескольких VPN

Если вы хотите иметь более одной VPN, вам может потребоваться создать разные идентификаторы SSH для каждой VPN. Просто укажите имя файла в параметре –f filename команды ssh-keygen.

И вот идентификатор создан. Можете увидеть публичную часть идентификатора, просмотрев версию ключа .pub:

sshvpn@falcons-client$ cat .ssh/identity.pub # для SSH1

или

sshvpn@falcons-client$ cat .ssh/id_dsa.pub # для SSH2

На сервере создадим каталог .ssh, принадлежащий sshvpn таким образом:

root@bears-server# su - sshvpn
sshvpn@bears-server$ mkdir .ssh
sshvpn@bears-server$ chmod 700 .ssh

Теперь нужно скопировать публичный ключ на сервер. Можно использовать любой метод по вашему выбору - scp, sftp или даже копировать/вставить. Если вы используете протокол SSH1, скопируйте этот файл в ~sshvpn/.ssh/authorized_keys на VPN-сервере. Если вы используете SSH2, скопируйте этот файл в ~sshvpn/.ssh/authorized_keys2 на VPN-сервере. Сделав это, вы получите следующие файлы. В случае SSH1:

sshvpn@bears-server$ ls -l /opt/ssh-vpn/.ssh
-rw------- 1 sshvpn sshvpn 330 Apr 19 04:43 authorized_keys
sshvpn@bears-server$ cat /opt/ssh-vpn/.ssh/authorized_keys
1024 35 
     128494554020444581541671425906529809779416661821446....

Жутковатая строка чисел – это публичная часть идентификатора. Публичный ключ SSH2 выглядит примерно также:

sshvpn@bears-server$ ls -l /opt/ssh-vpn/.ssh
-rw------- 1 sshvpn sshvpn 600 Apr 19 04:43 authorized_keys2
sshvpn@bears-server$ cat /opt/ssh-vpn/.ssh/authorized_keys2
ssh-dss AAAAB3NzaC1kc3MAAACBAM228h8QJ+QPkauTanmmhMwKykctqLh....

Прием и проверка хостового ключа SSH на сервере

Теперь мы должны в первый раз соединиться с сервером. Когда мы сделаем это, нас попросят принять ключ сервера:

sshvpn@falcons-client$ ssh server.example.com
The authenticity of host ‘server.example.com’ can’t be established.
RSA1 key fingerprint is 
      57:9d:59:1e:75:58:61:5b:ca:3f:e1:5c:96:59:e9:1a.
Are you sure you want to continue connecting (yes/no)? yes

В ответ на приглашение введите yes (целым словом, а не просто y). Теперь вы должны соединиться с сервером не вводя пароль и сохранив копию SSH-ключа сервера на клиентской машине.

Использование дополнительных аргументов команды ssh

Если вам необходимо использовать какие-нибудь аргументы команды ssh при установлении SSH-соединения, например, -p portnum или -l remoteusername, убедитесь в том, что вы указали их в командной строке. Мы предполагаем, что на этом этапе никакие другие аргументы вам не понадобятся. Позже в этой главе мы покажем, как можно внести эти дополнительные аргументы в .ssh/config, чтобы их не нужно было вводить каждый раз.

Теперь вам необходимо проверить, что хостовый ключ сервера, который вы только что приняли вслепую, в действительности представляет собой ключ сервера и вы не подверглись при этом атаке типа «кто-то посередине» (man-in-the-middle). Если этого не сделать, нельзя будет проверить, что удаленный конец SSH-соединения аутентичен. Например, программа Dsniff, написанная Dug Song, вполне может осуществить атаку. Риск весьма реален.

Когда вы ввели слово yes, хостовый ключ сервера был сохранен в файле $HOME/.ssh/known_hosts. Элементы этого файла – это строки чисел и/или букв, похожие на публичный ключ идентификатора. Вот, например, хостовый ключ RSA1:

sshvpn@falcons-client$ head -1 $HOME/.ssh/known_hosts
server.example.com 1024 35
1564497847169651600945933582396946558133150606031.....

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

/etc/ssh/ssh_host_key.pub
/etc/ssh/ssh_host_rsa_key.pub
/etc/ssh/ssh_host_dsa_key.pub

Эти файлы могут располагаться в /etc, а не в /etc/ssh. Это зависит от того, как программное обеспечение SSH-сервера было скомпилировано дистрибутивом Linux. Найдите ключ, соответствующий вашему файлу $HOME/.ssh/known_hosts и убедитесь что они в точности одинаковы. Если они отличаются, происходит что-то подозрительное, и ваша VPN небезопасна.

Проверка безпарольного соединения

Теперь попробуем соединить клиента с сервером еще раз. Если все было установлено нормально, вы должны получить возможность соединиться без ввода пароля и без вопросов о хостовом ключе:

sshvpn@falcons-client$ ssh server ‘echo `hostname`’ 
server.example.com
sshvpn@falcons-client$

Если соединиться без ввода пароля не удалось, проверьте следующее:

Права доступа. Протокол OpenSSH очень чувствителен к правам доступа. Убедитесь в том, ~sshvpn и ~sshvpn/.ssh имеют режим 700, а файл authorized_keys{2} – 600.
Несовместимости протоколов. Убедитесь, что и клиент и сервер поддерживают выбранный вами протокол SSH. Также, OpenSSH по умолчанию может использовать неподходящий протокол. Принудительно выставить протокол можно опциями командной строки ssh -1 или ssh -2.

Если причина оказалась не в этом, проверьте протокол syslog на сервере (обычно находится в /var/log/messages) и включите опцию командной строки ssh -v для отладки. Если неполадка по прежнему возникает, просмотрите страницу man ssh(1), страницу SSH FAQ (Frequently Asked Question, Часто задаваемые вопросы) на сайте http://www.employees.org/~satch/ssh/faq, или попросите помощи в списке рассылки SSH. Информацию о списке рассылки можно увидеть на странице FAQ.

Установка Sudo

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

Sudo – универсальная программа, позволяющая пользователям запускать ограниченный набор команд от лица пользователя root. Мы создадим очень простой набор правил, который позволит нам запустить команду pppd.

Программу Sudo можно найти на сайте www.courtesan.com/sudo/.Ее также включают во многие дистрибутивы Linux, так что вам может и не потребоваться компилировать ее самостоятельно.

После установки Sudo, запустите команду visudo для редактирования файла /etc/sudoers. Не пытайтесь редактировать этот файл вручную (не пользуясь visudo), поскольку вы можете повредить его! В конец файла добавьте следующие строки:

Cmnd_Alias VPNs=/usr/bin/pppd
sshvpn ALL=NOPASSWD: VPN

Измените строку пути /usr/bin/pppd, если положение pppd в вашей системе иное. Также, во второй строке замените sshvpn на имя созданного вами фиктивного пользователя SSH VPN, если вы выбрали иное чем мы. По завершению сохраните изменения и выйдите из редактора.

Полученные строки кода позволят пользователю sshvpn запускать команду /usr/bin/pppd с любыми требуемыми аргументами. Из-за указания элемента NOPASSWD пользователю не потребуется вводить свой пароль перед получением доступа к программам. Поскольку нам нужно, чтобы команды выполнялись с помощью скрипта, т.е автоматически, мы не можем вводить пароль.

Чтобы провести быстрое тестирование, просто введите следующие строки на клиентской машине и на сервере:

root@machine# su - sshvpn
sshvpn@machine$ sudo /usr/sbin/pppd noauth
~y}#A!}!}!} }4}”}&} } } } }%} (продолжается такая же абракадабра....)

Забавные символы представляют собой результат попытки pppd установить соединение с вашим терминалом. Перейдите к другому окну и выполните команду killall –HUP pppd для остановки процесса pppd.

Если файл sudoers изменен неверно, от вас потребуется введение пароля. Проверьте синтаксис этого файла. И снова обязательно используйте программу visudo, и не редактируйте этот файл вручную.

Установка PPP

Нам нужно запустить pppd на обоих хостах. В таблице 3.1 перечислены полезные аргументы команды pppd.

Таблица 3.1 Аргументы команды pppd

Аргумент Назначение

updetach После установления соединения pppd отсоединяется от терминала и становится демоном (производным init )

nodetach Не отключаться от терминала. Полезно при отладке.

Proxyarp Добавление записи, содержащей адрес узла, в таблицу ARP (протокол преобразования IP -адресов в аппаратные адреса Ethernet ). Можно использовать для того, чтобы другой конец соединения казался принадлежащим той же локальной сети.

debug Используется для получения дополнительной отладочной информации.

Linkname имя
Имя данного PPP соединения. Полезно для различения данного соединения от других. Также используется pppd для создания / var / run / ppp - name . pid в добавление к стандартному / var / run / ppp - device . pid .

Noauth Не требуется аутентификация PPP -хоста. совершенно приемлемо с точки зрения безопасности, поскольку существует проверка обоих концов соединения на уровне SSH .

require-pap На PPP -хосте требуется аутентификация PAP . Не обязательный параметр¹

Papcrypt При использовании аутентификации PAP эта опция говорит о том, что все секретные данные PAP в шифрованном виде хранятся в файле / etc / ppp / pap - secrets.

require-chap На PPP -хосте требуется аутентификация CHAP . Не обязательный параметр²

name имя Имя локальной системы для PPP -аутентификации. Необязательный параметр, но полезный, если аутентификация присутствует.

remotename имя Имя удаленной системы для PPP -аутентификации. Необязательный параметр, но полезный, если аутентификация присутствует.

user имя-пользователя Имя пользователя для PPP -аутентификации. По умолчанию то же, что и имя локальной системы.

show-password Показывать пароль, используемый в аутентификации, в файлах протокола. Полезно при отладке, но нужно отключить, когда PPP соединение нормально заработает.

Connect-delay # Время ожидания PPP -пакета от другого хоста (в миллисекундах). Мы устанавливаем это значение в 10000 (10 секунд), чтобы у SSH было время на установление своего соединения. Команда используется только на машине-клиенте.

pty команда
Вместо использования терминала/последовательного устройства, команда запускается на собственном псевдо- tty . Это будет наша команда ssh, соединяющаяся с удаленным сервером

usepeerdns Заставляет локальную машину использовать для поиска имен DNS -серверы удаленной системы. Хорошо использовать для разрешения мобильным клиентам доступа к внутренним DNS -серверам, например, с целью доступа к внутренним машинам. Логично использовать только на одном конце соединения, а не на обоих.

¹ PAP ( Password Authentication Protocol ) - протокол аутентификации пароля – Прим. переводчика
² CHAP ( Challenge Handshake Authentication Protocol ) - протокол аутентификации с предварительным согласованием вызова – Прим переводчика

Обход PPP-аутентификации

Протокол PPP обычно используется для создания сетевого соединения между двумя хостами по модему и почти всегда требует, чтобы перед установкой соединения пользователь проходил аутентификацию. Мы обсудим, как можно включить PPP-аутентификацию позже в этой же главе, когда будем предлагать готовый к использованию VPN-скрипт. Однако сейчас нам нужно убрать эту возможность и позволить выполнять аутентификацию протоколу SSH. Следовательно сейчас мы не будем использовать следующие аргументы – require-pap, require-chap, name, remotename и user.

Установление PPP соединения вручную

Теперь у нас есть все что нужно для соединения двух сетей:

Возможность соединить клиент с сервером без ввода пароля с помощью идентификаторов SSH.
Возможность запустить pppd от имени пользователя root с помощью sudo.

Давайте запустим pppd на клиенте, соединимся с удаленным сервером и запустим pppd там.

sshvpn@falcons-client$ sudo /usr/sbin/pppd updetach noauth \
        pty “sudo -u sshvpn ssh -t -t server.example.com \
        sudo pppd noauth 192.168.254.254:192.168.254.253”
Using interface ppp0
Connect: ppp0 <--> /dev/pts/2
Deflate (15) compression enabled
local IP address 192.168.254.253
remote IP address 192.168.254.254

Теперь давайте подробно рассмотрим эту жуткую командную строку:

sudo /usr/sbin/pppd updetach noauth

Запуск pppd от имени root через sudo. От терминала не отключаемся, что позволяет просмотреть информацию об IP-адресах. Аутентификация не требуется.

pty “sudo -u sshvpn ssh -t -t server.example.com \

Аргумент команды pty определяет команду, запускаемую для соединения с удаленной PPP-службой. Поскольку PPP запущен от имени пользователя root (через sudo), команда ssh будет также запущена от имени root. Это неправильно, поскольку в таком случае мы окажемся в зависимости от содержимого каталога /root/.ssh пользователя root. Поэтому нам надо запустить ssh от имени sshvpn с помощью команды sudo -u sshvpn ssh .... Аргументы -t и -t заставляют выделить на сервере pty (псевдотерминал) для данного соединения, что требуется для pppd. server.example.com – это, очевидно, имя сервера.

sudo pppd noauth 192.168.254.254:192.168.254.253”

Поскольку мы соединились с VPN-сервером от имени пользователя sshvpn, для запуска pppd от имени root нам нужно использовать sudo. Аргумент noauth позволяет использовать PPP без всякой аутентификации. Два IP-адреса показывают локальный и удаленный адрес для данного PPP-соединения. Нужно выбрать сети, которые точно не используются никакими машинами. Маска сети для данного соединения – 255.255.255.255, что означает что можно создавать для связей PPP сколько угодно отдельных пар IP-адресов, если при этом не дублировать уже используемые.

Влияние прочих выходных данных SSH

Если ваш VPN-сервер выводит что-нибудь автоматически при соединении (например, содержимое файла etc/motd, то процесс, осуществляющий PPP соединение может заметить это и произойдет ошибка. Попробуйте установить переменную PrintMotd в файле /etc/{ssh}/sshd_config в no.

Проверка соединения

К этому моменту вы должны иметь возможность связаться командой ping с адресами 192.168.254.254 и 192.168.254.253 и с клиента, и с сервера:

machine$ ping 192.168.254.253
PING 192.168.254.253 (192.168.254.253): 56 data bytes
64 bytes from 192.168.254.253: icmp_seq=0 ttl=255 time=10.7 ms
64 bytes from 192.168.254.253: icmp_seq=1 ttl=255 time=11.7 ms
...

Также вы должны иметь возможность просмотреть информацию об интерфейсе:

bears-server$ ifconfig ppp0
ppp0 Link encap:Point-to-Point Protocol
inet addr:192.168.254.254 P-t-P:192.168.254.253 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:33 errors:0 dropped:0 overruns:0 frame:0
TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10

Заметьте, что перечисленные IP-адреса совпадают с теми, которые мы указали в команде pppd.

Настройка таблицы маршрутизации

Последний этап – установить таблицы маршрутизации клиента и сервера для туннелирования данных через PPP-соединение:

sshvpn@falcons-client$ sudo route add -net 192.168.1.0/24 
                     gw 192.168.254.254

sshvpn@bears-server$ sudo route add -net 192.168.2.0/24 
                     gw 192.168.254.253

К этому моменту вы должны иметь возможность связываться с помощью команды ping с обеими сетями по желанию. Показан пример листинга с машины cubs, находящейся позади VPN-сервера Bears:

user@cubs-192.168.1.10$ ping braves.atlanta.example.com
PING braves.atlanta.example.com (192.168.2.15) 56 data bytes
64 bytes from 192.168.2.15 icmp_seq=0 ttl=255 time=13.4 ms
64 bytes from 192.168.2.15 icmp_seq=1 ttl=255 time=12.5 ms
...

Чтобы это работало, нужно, чтобы на всех машинах позади VPN-серверов соответствующий VPN-сервер был маршрутизатором по-умолчанию. Например:

user@cubs-192.168.1.10$ netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

user@braves-192.168.2.15$ netstat -rn

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth0

Повышение безопасности VPN

Для повышения безопасности вашей VPN вы можете предпринять определенные шаги, в частности, в области аутентификации. Если вы правильно следовали процедуре, в особенности, в части безопасности генерации и установки идентификатора SSH на клиентскую машину и проверки хостового SSH-ключа сервера, эти улучшения не являются необходимыми с точки зрения безопасности VPN. Однако добавление некоторых элементов управления не повредит. Мы предлагаем для параноиков следующие ограничения.

Требование на PPP-аутентификацию

Теперь, когда мы доказали, что можем создать VPN, можем добавить еще безопасности, затребовав аутентификацию. Протокол PPP включает в себя методы аутентификации с помощью PAP (Password Authentication Protocol) - протокола аутентификации пароля, и CHAP (Challenge Handshake Authentication Protocol) - протокола аутентификации с предварительным согласованием вызова.

Аутентификация PAP открыто посылает секретные данные (пароль) по соединению, CHAP поступает иначе. В этом случае посылается измененный пароль и вызов от хоста. Поскольку наше PPP-соединение устанавливается через зашифрованное SSH-соединение, в данном случае нет причин предпочитать аутентификацию CHAP аутентификации PAP.

Чтобы быть абсолютно уверенным в том, что соединение установлено именно с той машиной, с которой нужно, можно сделать так, чтобы демон PPP требовал аутентификации на обоих концах соединения. Конечно, это уже несколько чересчур, поскольку проверка обеих конечных точек производится с помощью SSH: клиентская машина аутентифицируется – по идентификатору SSH, а сервер – по хостовому ключу SSH.

И все же, если вы хотите установить на вашем соединении PAP или CHAP -аутентификацию, нужно будет отредактировать соответственно файл /etc/ppp/pap-secrets или /etc/ppp/chap-secrets. Правильным выбором аргументов name, remotename и user команды pppd мы можем улучшить читаемость файлов /etc/ppp/{pap-secrets chapsecrets}.

Например, на клиентской машине будем использовать следующие аргументы pppd:

debug require-pap show-password name vpn1-client \
user vpn1-client remotename vpn1-server

На сервере используем следующие аргументы:

debug require-pap show-password name vpn1-server \
user vpn1-server remotename vpn1-client

На обоих хостах в файлах /etc/ppp/pap-secrets увидим следующее:

# Username Server Password ip_addrs

vpn1-server vpn1-client “somepw” *

vpn1-client vpn1-server “otherpw” *

Для дополнительной безопасности можно зашифровать пароль на требующей аутентификации машине с помощью команды crypt(). Иными словами, машине vpn1-client не нужно знать пароль машины vpn1-server и она может держать зашифрованный пароль в соответствующем поле. Следовательно, файл /etc/ppp/pap-secrets на клиентской машине будет выглядеть так:

# Username Server Password ip_addrs

vpn1-server vpn1-client “8x5X.K/YftXJQ” *

vpn1-client vpn1-server “someotherpassword” *

В качестве быстрого способа сгенерировать версию пароля с помощью crypt() можно предложить такой скрипт Perl:

machine$ perl -e ‘print
  ( “Encrypted Password: “, crypt(“somepw”, “8x”), “\n”)’

Выходные данные этого скрипта будут выглядеть примерно так:

Encrypted Password: 8x5X.K/YftXJQ

При использовании CHAP вместо PAP, все делается аналогичным образом, за исключением того, что используется файл /etc/ppp/chap-secrets, в командной строке команды pppd указывается require-chap и шифровка пароля с помощью crypt() не производится. Аутентификация CHAP в силу своей архитектуры не может обрабатывать шифрованные пароли.

В представленном примере аутентификация требуется и на клиентской машине и на сервере. Можно проводить аутентификацию только для одного из концов соединения. Просто замените require-{pap, chap} на noauth на том конце, на которого аутентификации быть не должно.

Накладывание ограничений на идентификаторы SSH

Путем модификации файла .ssh/authorized_keys{2} можно наложить ограничения на принимаемые идентификаторы SSH. Просто вставьте перед строкой, содержащей публичный ключ, на который вы желаете повлиять, список ограничений. Наиболее полезные ограничения перечислены в Таблице 3.2.

Таблица 3.2 Полезные ограничения идентификаторов SSH

Ограничение Описание

from=”pattern-list” Разделяемый запятыми список хостов, которым оказывается доверие. Если идентификатор приходит от другой машины, в соединении будет отказано. Допустимы символы * и ?, а также ! (для отрицания).

command = “command” Какую бы команду не пытался выполнить клиент, выполняется указанная команда. Это может быть скрипт shell , загружающий pppd с соответствующими аргументами приведенный ниже в этой главе.

environment = “VARIABLE=value” Создает переменную окружения VARIABLE со значением value , позже мы используем это ограничение для указания имени VPN , связанной с данным соединением.

no-port-forwarding Отключение маршрутизации портов через SSH . Для VPN это не требуется.

no-X11-forwarding Отключение маршрутизации X 11. Для VPN X 11не требуется.

no-agent-forwarding Отключить маршрутизацию агента. Для VPN не требуется.

Данные опции можно объединить запятыми и поместить первым аргументом в строку authorized_keys{2} с идентификатором SSH. Пример может выглядеть так:

from=”client.example.com”,
command=”/usr/bin/sudo /usr/sbin/pppd 
    noauth 192.168.254.254:192.168.254.253”,
environment=”vpn_network=vpn1”, no-port-forwarding,
no-X11-forwarding,no-agent-forwarding 1024 35
    128494554020444581541671425906529809779416661821446...

В этом примере мы разрешаем поступление идентификатора только с машины client.example.com, принудительно будет выполняться команда sudo pppd, все ненужные маршруты SSH будут отключены, а переменная окружения vpn_network приобретет значение vpn1 (для дальнейшего использования).

Включение этих параметров будет создавать очень, очень длинные командные строки. Используйте только редакторы, поддерживающие такие строки. В частности, старые версии vi могут не позволить редактировать и правильно отображать их. Мы предлагаем использовать vim или Emacs.

Используйте самую последнюю версию OpenSSH

Напомним вам еще раз о необходимости использовать самую последнюю версию OpenSSH. Например, в версиях до 2.9.9.p2 есть ошибка, при которой пользователь с правильным идентификатором SSH может установить SFTP-соединение с сервером и обойти ограничения. (Такое возможно только при использовании протокола SSH2). Если в руках у атакующего оказался идентификатор, он может убрать ограничения на команды, заменив файл authorized_keys2 другим, не содержащим опции -command. Если вы не имеете возможности модернизировать OpenSSH-сервер, по крайней мере, закомментируйте строку Subsystem sftp в файле /etc/ssh/sshd_config.

Запуск собственного демона ssh на VPN-сервере

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

Все что нам нужно – это создать второй файл sshd_config, в котором указать иной, чем по умолчанию (22) порт и ограничительные опции. Пользователь sshvpn на клиентской машине свяжется теперь с этим демоном. Вот новый файл sshd-config, который мы поместим в /opt/ssh-vpn/etc:

Port 9876
PidFile /var/run/sshd_vpn.pid

HostKey /etc/ssh/ssh_host_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600

SyslogFacility AUTH
LogLevel INFO

RSAAuthentication yes
AllowUsers sshvpn

# Restrictive settings
#
IgnoreRhosts yes
IgnoreUserKnownHosts yes
PermitRootLogin no
StrictModes yes

PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
RhostsAuthentication no
RhostsRSAAuthentication no
X11Forwarding no
PrintMotd no
KeepAlive yes

При такой конфигурации соединение позволяется только пользователю sshvpn, никакие методы аутентификации кроме идентификаторов SSH не используются, а номер порта устанавливается в 9876. Можно использовать списки контроля доступа (ACL) ядра с командами ipchains/iptables, если хотите ограничить доступ к этому порту. При использовании другого порта вы получаете возможность использовать с демоном ssh для доступа к VPN иные ACL, чем для стандартного доступа по протоколу SSH через порт 22.

Запустить этот демон можно просто выполнив команду /usr/sbin/sshd -f /opt/sshvpn/etc/sshd_config. Также, для запуска этого демона может понадобиться изменить стартовый скрипт для sshd в файле /etc/init.d. Любой VPN-клиент, который захочет соединиться с этим SSH-демоном, должен будет указать новый порт с помощью аргумента команды ssh -p portnum

Установка опций SSH в файле .ssh/config

Перед установлением исходящего соединения ssh читает файл $HOME/.ssh/config. Этот файл содержит аргументы команды ssh, используемые при установлении соединения, это предотвращает ошибки при ручном вводе аргументов. Мы будем использовать его для создания «псевдонимов» (Alias) наших соединений.

Скажем, мы назовем нашу VPN vpn1. Удаленный сервер называется server.example.com и на этом удаленном сервере запущена команда ssh на порт 9876, как это описано в предыдущем разделе. Предположим, что по какой-то причине пользователь sshvpn на сервере в действительности имеет имя pppme. В файл ~sshvpn/.ssh/config впишем следующие строки:

Host vpn1
Hostname server.example.com
Port 9876
User pppme

Эти аргументы автоматически будут использованы, когда мы соединимся с vpn1:

sshvpn@falcons-client$ ssh -v vpn1
debug: Reading configuration data /opt/ssh-vpn/.ssh/config
debug: Applying options for vpn1
debug: Connecting to server.example.com [XXX.XXX.XXX.XXX] port 9876.
....

Таким образом мы создадим опции .ssh/config для каждого VPN-соединения, что позволит нам просто использовать команду ssh имя vpn и опции будут использоваться автоматически.

Скрипты VPN

Теперь, когда вы знаете, как создать VPN вручную, пришло время показать наши скрипты, которые сделают за вас большую часть работы. Вот, коротко, необходимые этапы:

Установка PPP
Настройка маршрутизации IP
Настройка пользователей sshvpn в обеих системах, включая их домашние директории.
Выбор имени VPN (мы будем использовать vpn1)
Выбор версии протокола SSH, создание идентификатора SSH на клиентской машине и копирование его в файл authorized_keys{2} на сервере.
Настройка sudo на обеих машинах.
Настройка паролей /etc/ppp/{pap, chap}-secrets (если нужно).
Создание файла sshd_config для VPN и запуск демона ssh (если нужно).
Установление беспарольного соединения и проверка ключа полученного с сервера.
Настройка псевдонимов ssh для vpn с помощью файла ~sshvpn/.ssh/config, чтобы можно было автоматически установить соединение с помощью команды ssh vpn1.
Установка скриптов vpn-server и vpn-client в каталог /opt/ssh-vpn/bin.
Создание ссылки на vpn-server или vpn-client в файле /etc/init.d
Конфигурирование pppd для того, чтобы запускать наши VPN-скрипты через ip-up.
Модификация authorized_keys{2} на сервере для запуска команд vpn-server.
Создание конфигурационных файлов VPN.
Запуск VPN.

В этой главе мы уже обсудили пункты с 1 до 10. Теперь рассмотрим новые конфигурационные элементы.

Установка программ vpn-server и vpn-client

Для установления VPN-соединения нужны две программы: vpn-client устанавливает соединение с сервером по протоколу SSH, а vpn-server принимает соединение. Скачать эти файлы можно с нашего web-сайта www.buildinglinuxvpns.net. Установим их в домашние каталоги пользователей sshvpn клиента и сервера следующим образом:

falcons-client# mkdir /opt/ssh-vpn/bin; chmod 755 
                /opt/ssh-vpn/bin
falcons-client# cp vpn-client /opt/ssh-vpn/bin; chmod 755 
                /opt/ssh-vpn/bin/*

bears-server# mkdir /opt/ssh-vpn/bin; chmod 755 
                /opt/ssh-vpn/bin
bears-server# cp vpn-server /opt/ssh-vpn/bin; chmod 755 
                /opt/ssh-vpn/bin/*

Файлы устанавливаем от имени пользователя root, чтобы взлом пользователя sshvpn не позволил изменить файлы.

Программы vpn-client и vpn-server представлены на Распечатках 3.1 и 3.2 соответственно. Вместо того, чтобы перепечатывать, возьмите их с нашей web-страницы, мы осуществляем поддержку последних версий программ в режиме online.

Распечатка 3.1 Программа vpn-client

#!/bin/sh

# Здесь укажите положение
# вашей директории для установки SSH VPN 
SSH_VPN_DIR=/opt/ssh-vpn

# Отсюда и ниже никаких изменений делать не нужно

vpn_config () {
   vpn_network=$1
  # Берем глобальные переменные
  . $SSH_VPN_DIR/etc/ssh-vpn.conf || exit 0
  # Берем vpn-специфические переменные
  VPN_CONFIG=$SSH_VPN_DIR/etc/$vpn_network
  . $VPN_CONFIG || exit 0
  if [ “$client_debug” = “yes” ] ; then
        set -x
        client_pppd_args=”$client_pppd_args debug”
  fi
}

run_as_sshvpn () {
     whoami=`$WHOAMI`
     pwd=`pwd`
     case “$whoami” in
       root)    exec $SU - $SSH_VPN_USER “-ccd $pwd;$0 $*”;
                exit 0; ;;
       $SSH_VPN_USER) ;;
       *)       echo “$0 Must be run as $SSH_VPN_USER” >&2;
                exit 1; ;;
     esac
}

# Определяем, что нужно делать:

if [ ! -z “$LINKNAME” ] ; then
        # Был вызов скрипта ip-up из pppd

        vpn_config $LINKNAME

        # Конфигурируем новый маршрут
        # sudo не нужно, вызов был из pppd от имени root
        # переменную $IPREMOTE установил для нас демон pppd
        [ “$server_network” ] && $ROUTE add -net 
           $server_network gw $IPREMOTE

        exit 0;

elif [ “$1” = “stop” ] ; then
         # Вызов был в стиле init.d одним из 
         # следующих способов:
         # /etc/init.d/vpn-client stop vpn1
         # /etc/init.d/vpn1 stop
         # /etc/rcX.d/S##vpnname stop

         [ “$2” ] && vpn_config “$2” \
                  || vpn_config `basename $0 | 
                     sed -e ‘s/^[SK][0-9][0-9]//’`

         # Останавливаем процессы pppd и stunnel
         kill `head -1 
               $PIDDIR/ppp-$vpn_network.pid` 2>/dev/null
         exit 0;

elif [ “$1” = “start” ] ; then
     # вызов в стиле init.d, сходный с вышеописанным.

        [ “$2” ] && vpn_config “$2” \
                 || vpn_config `basename $0 | 
                    sed -e ‘s/^[SK][0-9][0-9]//’`
        run_as_sshvpn “$@” 
        # Убедимся, что мы не являемся root или др..

        # Переходим к началу .

elif [ $# -eq 1 ] ; then
        vpn_config $1
        run_as_sshvpn “$@” 
        # Убедимся, что мы не являемся root или др.

        # Переходим к изначальному состоянию.

else
        echo “Usage: $0 destination start|stop” >&2
        echo “Usage: $0 start|stop” >&2
        echo “Usage: (if $0 is a vpn name)” >&2
        exit 1
fi

# Универсальные аргументы ssh
# (да, здесь есть два параметра ‘-t’ )
SSH_ARGS=”-oBatchMode=yes -enone -t -t”

# Универсальные аргументы pppd
PPPD_ARGS=”updetach lock connect-delay 10000 
           name $vpn_network-client \
      user $vpn_network-client linkname $vpn_network \
      remotename $vpn_network-server $client_pppd_args pty”

# Вносим изменения в PPPD_ARGS
# для нужного уровня аутентификации

if [ “$client_require_pap” = “yes” ] ; then
         PPPD_ARGS=”require-pap $PPPD_ARGS”
elif [ “$client_require_chap” = “yes” ] ; then
         PPPD_ARGS=”require-chap $PPPD_ARGS”
else
         PPPD_ARGS=”noauth $PPPD_ARGS”
fi

# Запуск процессов pppd/ssh
$SUDO $PPPD $PPPD_ARGS \
   “$SUDO -u $SSH_VPN_USER $SSH $SSH_ARGS 
             $client_ssh_args $vpn_network”

Распечатка 3.2 Программа vpn-server

#!/bin/sh

# Здесь укажите положение
# вашей директории для установки SSH VPN 
SSH_VPN_DIR=/opt/ssh-vpn

# Отсюда и ниже никаких изменений делать не нужно

vpn_config () {
     # Конфигурируем переменные VPN
     vpn_network=$1
     # Берем глобальные переменные
     . $SSH_VPN_DIR/etc/ssh-vpn.conf
     # Берем vpn-специфичные переменные
     VPN_CONFIG=$SSH_VPN_DIR/etc/$vpn_network
     . $VPN_CONFIG || exit 0  
       # Проверка на наличие конфигурации. Возможно,
       # что вызов был из скрипта ip-up
       # при создании другой VPN. Если это так,
       # просто выходим.
     if [ “$server_debug” = “yes” ] ; then
          set -x
          server_pppd_args=”$server_pppd_args debug”
     fi
}
run_as_sshvpn () {
     whoami=`$WHOAMI`
     pwd=`pwd`
     case “$whoami” in
           root)   exec $SU - $SSH_VPN_USER “-ccd $pwd;$0 $*”;
                   exit 0; ;;
           $SSH_VPN_USER) ;;
           *)      echo “$0 Must be run as $SSH_VPN_USER” >&2;
                   exit 1; ;;
     esac
}
if [ “$LINKNAME” ] ; then
        # Был вызов скрипта ip-up из pppd


        vpn_config $LINKNAME

        # Конфигурируем новый маршрут
        # sudo не требуется,
        # запуск был из pppd от имени root
        # переменную PREMOTE установил за нас демон pppd
        [ “$client_network” ] && $ROUTE add -net 
           $client_network gw $IPREMOTE

        exit 0

elif [ “$1” = “pppd” ] ; then
        # Вызов был из файла authorized_keys{2}
        # ‘vpn-server pppd vpn1’ как SSH_VPN_USER

        vpn_config $2

        # Универсальные аргументы pppd
        PPPD_ARGS=”updetach linkname $vpn_network \
              remotename $vpn_network-client user 
                         $vpn_network-server \
              name $vpn_network-server $server_pppd_args”

         if [ “$server_require_pap” = “yes” ] ; then
              PPPD_ARGS=”require-pap $PPPD_ARGS”
         elif [ “$server_require_chap” = “yes” ] ; then
              PPPD_ARGS=”require-chap $PPPD_ARGS”
         else
              PPPD_ARGS=”noauth $PPPD_ARGS”
         fi

         # Загрузка pppd
         $SUDO $PPPD $PPPD_ARGS 
               $server_ppp_ip:$client_ppp_ip

elif [ “$1” = “stop” ] ; then
        # Вызов был в стиле init.d
        [ “$2” ] && vpn_config “$2” \
                 || vpn_config `basename $0 | 
                    sed -e ‘s/^[SK][0-9][0-9]//’`

        # Останавливаем процесс pppd
        kill `head -1 
              $PIDDIR/ppp-$vpn_network.pid` 2>/dev/null
        exit 0;

elif [ “$1” = “start” ] ; then
        # Вызов был в стиле init.d

        echo “You can’t start an SSH-VPN connection 
              from the server.” >&2
        exit 1;

else
        echo “Usage: $0 stop” >&2
        echo “” >&2
        echo “This program is meant to be called 
              by sshd or to stop “ >&2
        echo “an existing VPN. It cannot be called 
              manually.” >&2
        exit 1
fi

Ссылки на vpn-{client, server} в /etc/init.d

Скрипты, применяемые для запуска и останова системных служб располагаются в каталоге /etc/init.d (в некоторых дистрибутивах Linux, в особенности ранних версиях систем RedHat они располагаются в /etc/rc.d/init.d). Ссылки на эти скрипты обычно располагаются в одной из директорий /etc/rcX.d, что определяет на каком уровне выполнения (runlevel) служба должна быть активна.

Наши скрипты созданы так, чтобы их можно было запускать напрямую, как один из таких скриптов запуска/останова, поэтому все что нам нужно, это создать на них ссылки. Скажем, мы хотим, чтобы наша VPN с именем vpn1 запускалась на уровне выполнения 2. Нужно создать следующие символические ссылки:

bears-server# ln -s /opt/ssh-vpn/bin/vpn-server /etc/rc2.d/S99vpn1
bears-server# ln -s /opt/ssh-vpn/bin/vpn-server /etc/init.d/vpn1

falcons-client# ln -s /opt/ssh-vpn/bin/vpn-client /etc/rc2.d/S99vpn1
falcons-client# ln -s /opt/ssh-vpn/bin/vpn-client /etc/init.d/vpn1

Эти команды приведут к тому, что наша VPN запуститься как последняя программа при выходе на 2 уровень выполнения. Число 99 можно заменить на более соответствующее вашей системе. Также, для легкости использования можно создать запись в init.d.

Конфигурирование ip-up для запуска наших VPN-скриптов

Сразу после установления PPP-соединения, демон pppd запускает скрипт /etc/ppp/ip-up. Мы можем использовать этот факт для установки маршрутов, не используя оператор sleep, применяемый во многих общедоступных методах создания VPN (при этом после запуска pppd и перед добавлением маршрутов запускается команда sleep 10, в надежде на то, что все завершиться своевременно). Демон pppd устанавливает различные переменные окружения, в частности LINKNAME и IPREMOTE, что облегчает нашим скриптам задачу определения того, какая VPN была только что создана и получения необходимых параметров сети. Мы сделаем так, чтобы скрипт ip-up запускал наши программы vpn-client или vpn-server автоматически для установки маршрутов.

pppd всегда вызывает /etc/ppp/ip-up, но то, что делает этот файл, радикально отличается в разных версиях Linux. В некоторых дистрибутивах этого файла нет вообще. Так что, мы опишем несколько методов, используя которые вы сможете указать скрипту ip-up на наши программы.

Настройка PPP

В нижеследующих примерах мы предполагаем, что у вас установлены настройки ppp по умолчанию. Если вы создали ppp-зависимые файлы, наше решение со ссылкой вам не подойдет. В таком случае, добавьте вручную в ваш ip-up–зависимый скрипт строку, вызывающую vpn-client или vpn-server.

Slackware: скрипт ip-up отсутствует

В Slackware скрипта ip-up нет совсем. Поэтому для указания наших VPN-скриптов придется создать его. Наиболее легкий способ – использование символической ссылки

falcons-client# ln -s /opt/ssh-vpn/bin/vpn-client /etc/ppp/ip-up

или

bears-server# ln -s /opt/ssh-vpn/bin/vpn-server /etc/ppp/ip-up

Debian: /etc/ppp/ip-up.d

Скрипт ip-up дистрибутива Debian автоматически загружает все скрипты, записанные в каталоге /etc/ppp/ip-up.d. Таким образом, нам требуется только создать в этом каталоге ссылку на наши скрипты, например, таким образом.

falcons-client# ln -s /opt/ssh-vpn/bin/vpn-client 
                      /etc/ppp/ip-up.d/vpn-client

или

bears-server# ln -s /opt/ssh-vpn/bin/vpn-server 
                    /etc/ppp/ip-up.d/vpn-server

Red Hat: /etc/ppp/ip-up.local

Скрипт ip-up в Red Hat и подобных системах в конце своего выполнения автоматически загружает /etc/ppp/ip-up.local. Все что нам нужно – это создать символические ссылки на наши VPN-скрипты с именем ip-up.local.

falcons-client# ln -s /opt/ssh-vpn/bin/vpn-client /etc/ppp/ip-up.local

или

bears-server# ln -s /opt/ssh-vpn/bin/vpn-server /etc/ppp/ip-up.local

Изменение файла authorized_keys{2}

Поставим некоторые ограничения на SSH-идентификатор, предоставленный клиентом, добавив поле начальных опций в файл ~sshvpn/.ssh/authorized_keys{2}. Чтобы упростить наши программы, мы заставим VPN-сервер автоматически загружать наш скрипт vpn-server. Это также повысит и безопасность сервера, поскольку если идентификатор окажется каким-либо образом похищенным, атакующий не сможет соединиться с сервером, он (или она) может только попытаться создать VPN.

Мы также присвоим переменной vpn-network значение, соответствующее имени VPN (vpn1). Эта переменная будет контролировать следующее:

Имя локальной машины и имя пользователя, необходимые для PPP-аутентификации, в данном случае – vpn1-server
Файл конфигурации, используемый скриптом vpn-server. В нашем случае /opt/ssh-vpn/etc/vpn1

Можно добавить аргумент from, чтобы ограничить число машин, которые могут попытаться установить VPN-соединение. Также мы включим все ограничительные опции no-*-forwarding, поскольку они не являются необходимыми для VPN, они только добавляют сложности и могут потенциально быть угрозой безопасности. Таким образом наш пример будет выглядеть так:

from=”client.example.com”,
command=”/opt/ssh-vpn/bin/vpn-server pppd vpn1”,
no-port-forwarding,no-X11-forwarding,no-agent-forwarding“ 
1024 35 128494554020444581541671425906529809779416661821446...

Единственные необходимые для наших целей элементы – это команда и опция. Отметьте, что мы загружаем vpn-server с двумя аргументами – pppd и именем VPN (vpn1), программа будет использовать эти аргументы, чтобы понять, что ей следует делать. Без этих аргументов наши скрипты функционировать не будут.

Создание глобального конфигурационного файла VPN

И скрипт vpn-client, и скрипт vpn-server будут читать файл /opt/ssh-vpn/etc/ssh-vpn.conf. Для простоты мы разместили этот файл на нашем web-сайте, откуда его легко можно скачать. Установите его и на клиент и на сервер следующим образом:

root# mkdir /opt/ssh-vpn/etc; chmod 755 /opt/ssh-vpn/etc
root# cp ssh-vpn.conf /opt/ssh-vpn/etc
root# chmod 644 /opt/ssh-vpn/etc/ssh-vpn.conf

Этот файл содержит пути к внешним командам, которые могут понадобиться:

# Положение программ. Возможно они
# соответствуют вашей системе, но проверить нужно.
SU=/bin/su
SUDO=/usr/bin/sudo
PPPD=/usr/sbin/pppd
ROUTE=/sbin/route
SSH=/usr/bin/ssh
WHOAMI=/usr/bin/whoami

PIDDIR=/var/run

Также в файле есть переменная SSH_VPN_USER. Присвойте ей значение, соответствующее имени пользователя, запускающего скрипт vpn-client на клиентской машине (в наших примерах – sshvpn):

SSH_VPN_USER=sshvpn

Программа vpn-client сначала проверит, что ее запуск был произведен нужным пользователем, а затем будет использовать это значение в аргументах команды pty следующим образом:

pty “$SUDO -u $SSH_VPN_USER $SSH ...”

Это нужно потому, что pppd запускается от имени root через sudo, а нам нужно производить ssh-соединение в команде pty от лица SSH_VPN_USER. Господи, до чего же сложно!

Создание VPN-специфичного конфигурационного файла

Наши программы vpn-client и vpn-server написаны для того, чтобы можно было устанавливать любое число произвольных VPN-соединений. Эти команды определяют, какую VPN им нужно создавать по имени программы и ее аргументам. Если два аргумента указаны, например, таким образом: vpn-server start vpn1, то второй аргумент рассматривается как имя VPN. При вызове через символическую ссылку, например, /etc/init.d/vpn1 или /etc/rc2.d/s99vpn1, будет использовано имя программы с удаленными первыми символами S## (или K##), что опять же дает vpn1. иными словами, скрипт пытается как можно более интуитивно определить, что вы хотите. На сервере скрипт определяет имя VPN по аргументам командной строки, которые мы указали в опции command в файле authorized_keys{2}.

Определив имя VPN, скрипт получает из файла /opt/ssh-vpn/etc/имя_vpn ее конфигурационные переменные. Таким образом, для нашей VPN с именем vpn1 мы должны создать файл /opt/ssh-vpn/etc/vpn1. Каждая переменная в конфигурационном файле начинается с server_ или client_, что означает возможность создать один файл со всеми необходимыми значениями и использовать его, при желании, в обеих системах не заботясь о конфликтах. Указанные в Таблице 3.3 переменные являются обязательными.

Таблица 3.3 Переменные конфигурационного файла

Переменная Кто использует Пример Объяснение

client_network сервер 192.168.1.0/24 Сеть на VPN -клиенте. Используется VPN -сервером для установления маршрута к удаленной сети с помощью команды route add .

server _ network клиент 192.168. 2 .0/24 Сеть на VPN -сервере. Используется VPN -клиентом для установления маршрута к удаленной сети с помощью команды route add .

server_ppp_ip сервер 192.168.254.254 IP -адрес конца PPP -соединения, на котором находится VPN -сервер. Этот адрес не должен находится в сети, доступной любой машине.

client _ ppp _ ip сервер 192.168.254.253 IP -адрес конца PPP -соединения, на котором находится VPN -клиент. Этот адрес не должен находится в сети, доступной любой машине.

Переменные, указанные в Таблице 3.4 являются необязательными.

Таблица 3.4 Необязательные переменные конфигурационного файла

Переменная Кто использует Пример Объяснение

client_debug клиент yes Добавляет опцию debug к аргументам pppd и включает set - x для пошагового вывода скрипта vpn - client .

server _ debug сервер yes Добавляет опцию debug к аргументам pppd с целью ведения более подробного протокола.

client_ssh_args клиент - c 3des Дополнительные аргументы ssh , специфичные для данной VPN .

client _ pppd _ args клиент usepeerdns Дополнительные аргументы командной строки pppd , специфичные для данной VPN .

server _ pppd _ args сервер proxyarp Дополнительные аргументы командной строки pppd , специфичные для данной VPN .

client_require_pap клиент yes VPN -клиент будет требовать PAP -аутентификации сервера. Все значения, кроме yes эквивалентны no .

server _ require _ pap сервер yes VPN -сервер будет требовать PAP -аутентификации клиента. Все значения, кроме yes эквивалентны no .

client_require_chap клиент yes То же, что и client _ require _ pap , но для протокола CHAP .

server_require_chap сервер yes То же, что и server _ require _ pap , но для протокола CHAP.

Пример файла конфигурации может выглядеть так:

# конфигурационный файл VPN1
# /opt/ssh-vpn/etc/vpn1

# На обеих сторонах расположены сети, для
# которых можно использовать команду ‘route’
client_network=192.168.2.0/24
server_network=192.168.1.0/24

# Нужна ли нам отладочная информация?
client_debug=”no”
server_debug=”yes”

# Выбираем адреса IP для обеих VPN.
server_ppp_ip=192.168.254.254
client_ppp_ip=192.168.254.253

# Нужна ли PPP-аутентификация?
client_require_pap=”yes”
server_require_pap=”yes”
client_require_chap=”no”
server_require_chap=”no”

# нужны ли нестандартные аргументы pppd? Вставьте их сюда.
#client_pppd_args=”usepeerdns”
#server_pppd_args=”proxyarp”

# нужны ли дополнительные аргументы ssh? Вставьте их сюда.
#client_ssh_args=”-C”
#server_ssh_args=””

Существует два главных способа управления командой ssh. Первый – создать запись в ~/.ssh/config, как было уже ранее показано в этой главе. Как альтернативу (или как дополнение) можно предложить разместить аргументы в переменной client_ssh_args. Эта переменная представляет собой просто строку, помещаемую сразу за командой $SSH, указанной в pty-аргументе pppd.

Можно включать такие опции, как -l remoteusername или -p 9876. Можно размещать любую доступную опцию, но вы должны их слегка видоизменять. Например, вариант опции из файла ~/.ssh/config Hostname client.example.org для командной строки можно предложить такой: -ostname client.example.org.

Мы, в общем случае, предпочитаем помещать все опции ssh в одно место, либо в конфигурационный файл ~/.ssh/config, либо в файл /opt/ssh-vpn/etc/имя_vpn. Так гораздо легче просмотреть сразу все опции.

Запуск и останов VPN

Для запуска VPN вручную, нужно просто запустить следующую команду на клиентской машине:

falcons-client# /etc/init.d/vpn1 start

Запустить VPN можно только с клиентской машины, поскольку именно эта машина начинает SSH-соединение. Для останова VPN нужно выполнить следующую команду:

root# /etc/init.d/vpn1 stop

Остановить VPN можно и с клиентской машины, и с сервера, поскольку эта команда просто прекращает выполнение pppd. Также возможно запустить или остановить VPN, указав ее имя вручную в команде вызова программы vpn-client или vpn-server, например:

bears-server# /opt/ssh-vpn/bin/vpn-server stop vpn1
falcons-client# /opt/ssh-vpn/bin/vpn-client start vpn1

Поддержка нескольких сетей VPN

Наши скрипты сделаны так, чтобы поддерживать любое количество VPN-соединений, и число VPN, которое вы можете запустить и обслуживать зависит исключительно от доступных ресурсов (память, мощность процессора, число процессов и т.д.) на используемых машинах.

Каждая VPN должна использовать свой собственный отдельный идентификатор SSH. Это необходимо потому, что сервер использует идентификатор клиента для установления имени сети VPN в файле authorized_keys{2} с помощью опции command.

Скажем, мы хотим создать второе VPN-соединение с именем vpn2. На этапе создания идентификатора мы с помощью ssh-keygen создадим новый идентификатор, но включим аргумент – имя файла, например:

sshvpn@falcons-client$ ssh-keygen -f 
            /opt/ssh-vpn/.ssh/identity.vpn2 -t rsa1 -N ‘’

(При создании ключа SSH2 замените параметр -t rsa1 на -t dsa или -t rsa).

Чтобы заставить скрипт vpn-client использовать данный ключ вместо установленного по умолчанию, в файл /opt/ssh-vpn/.ssh/config добавьте следующие строки:

Host vpn2
Identity /opt/ssh-vpn/.ssh/identity.vpn2

Также, в конфигурационный файл vpn2 /opt/ssh-vpn/etc/vpn2 можно вставить строку

client_ssh_args=”-i /opt/ssh-vpn/.ssh/identity.vpn2”

Поиск проблем

Протокол «PPP-через-SSH» - штука коварная. В последующих разделах обсуждаются несколько полезных мер поиска ошибок, к которым можно прибегнуть, чтобы заставить протокол работать.

Проблемы PPP

Если демону pppd не удается должным образом установить PPP-соединение, то чтобы увидеть, почему это происходит, включите опцию debug на обоих концах соединения, а затем просмотрите системные протоколы.

Если вы не можете получить отладочную информацию, убедитесь, что демон syslogd сконфигурирован таким образом, чтобы отображать все сообщения отладки. pppd обычно компилируется так, чтобы использовать данное свойство этого демона, поэтому проверьте, что в файле /etc/syslog.conf содержится строка примерно с таким содержимым: daemon.debug /var/log/messages. Вы можете также захотеть использовать вместо данного метода опцию pppd logfile.

Если возникают проблемы с PAP или CHAP-аутентификацией, для отладки можно попробовать использовать аргумент демона pppd show-password. Можно также отключить требования на PAP и CHAP-аутентификацию, пока вы не убедитесь, что именно они являются источником проблем.

Если PPP-соединение устанавливается правильно, но не происходит добавления маршрутов, убедитесь, что скрипты вызываются из ip-up должным образом, соответствующим вашей версии Linux. Также убедитесь, что в конфигурационном файле VPN установлены значения переменных client_network и server_network. Для проверки синтаксиса можно попробовать добавить маршруты вручную, используя значения этих переменных.

Проблемы SSH

Попробуйте установить соединение между клиентом и сервером вручную, командой ssh (c аргументами, которые вы намереваетесь использовать для VPN) и убедиться в том, что при этом не потребуется пароль. Если установка соединения прошла успешно, удаленная система должна автоматически запустить pppd, и на экране вы увидите процесс установления соединения по протоколу PPP.

Если возникает ошибка «Aborted by user» (Прервано пользователем), убедитесь, что у вас не установлен режим SSH-соединения BatchMode (пакетный режим) до того момента, пока не получен и не проверен ключ полученный с сервера.

Убедитесь в том, что поместили публичный ключ клиента в нужный файл:

~/.ssh/authorized_keys (в случае SSH1) и ~/.ssh/authorized_keys2 (в случае SSH2).

На клиентской машине в команде ssh используйте опцию -v для получения более подробной информации На сервере – проверьте системные протоколы. Убедитесь, что вы записываете всю отладочную информацию с помощью syslogd. Обычно OpenSSH использует аутентификацию, поэтому проверьте, чтобы в /etc/syslog.conf содержалась строка, подобная auth.debug /var/log/messages. В качестве альтернативы можно предложить попробовать запустить демон sshd вручную не в фоновом (foreground) режиме с опцией -d для вывода отладочной информации на терминал.

Если установка SSH-соединения не разрешается, попробуйте явным образом указать версию протокола SSH в файле ~/sshvpn/.ssh/config или в переменной окружения client_ssh_args. Также убедитесь в том, что используете идентификатор, совместимый с вашим протоколом. Хорошо бы запустить одну и ту же версию OpenSSH на обеих машинах, поскольку так будет меньше проблем с совместимостью.

Сетевые проблемы

Если PPP-соединение установлено, но некоторые или же все IP-пакеты не проходят через него, проверьте еще раз значения для IP-маршрутизации в /proc/sys/net/ipv4/ip_forward и пр. Также проверьте, нет ли каких-либо правил ipchains и iptables, которые могли бы блокировать пакеты. Используйте в командах ipchains/iptables опцию -l для записи в протокол отброшенных пакетов и просмотрите системные протоколы.

Если проблемы возникают при поиске имен хостов в удаленной сети, попробуйте использовать опцию PPP usepeerdns, обычно на клиентской машине.

Ограничения

Созданная нами VPN работает через SSH, который представляет собой протокол TCP. TCP (Transmission Control Protocol, Протокол управления передачей) является IP-протоколом, который автоматически выполняет повторную передачу любых пакетов, которые не были получены удаленной системой. Таким образом, TCP – надежный протокол: либо пакет передается на другой конец соединения и своевременно там принимается, либо, по истечении произвольно установленного времени ожидания, соединение разрывается.

Использование TCP для VPN имеет и недостаток. Мы инкапсулируем разные IP-протоколы (TCP, UDP, ICMP) в нашем SSH-соединении. В частности, протокол UDP (User Datagram Protocol, протокол передачи дейтаграмм пользователя) используется в ситуациях, когда гарантированная доставка не требуется, например, в потоковых протоколах, для которых потеря одного - двух пакетов не является критичной. Однако, когда UDP-пакеты посылаются через TCP-соединение, доставка будет гарантирована, и пакет, который в норме мог бы быть безболезненно потерян, посылается снова. Это может привести к замедлению работы VPN.

Протокол PPP изначально был создан для обработки таких IP-протоколов, как TCP, UDP и ICMP. Таким образом любой не-IP трафик не сможет пройти через VPN. Однако, pppd имеет поддержку IPX (Internet Packet eXchange, Межсетевой пакетный обмен, протокол используемый Novell NetWare). У pppd есть несколько опций, связанных с IPX, которые вам может понадобиться настроить для правильной работы. Обратитесь к странице руководства pppd(8).

Заключение

В этой главе мы обсудили все, что необходимо для успешного создания безопасной VPN с помощью протоколов PPP и SSH. Мы снабдили вас готовыми к применению скриптами, которые одновременно и гибки и легки в использовании. Однако даже при их наличии, первые несколько попыток создания VPN вызовут у вас головную боль. Может оказаться так, что вам придется искать проблемы в соединении, которое успешно работало многие месяцы.

Однако создание VPN на основе «PPP-через-SSH» - это хорошо зарекомендовавший себя на практике метод. Эти протоколы надежны, вполне определены и, что наиболее важно, не находятся в состоянии становления, как многие другие VPN-технологии.