OpenVPN, или Кроссплатформенная частная сеть

АНДРЕЙ БЕШКОВ

OpenVPN, или Кроссплатформенная частная сеть

Рано или поздно большинство системных администраторов сталкивается с необходимостью соединить свои территориально удаленные сети с помощью надежного, достаточно быстрого и в то же время защищенного от прослушивания и вмешательства злоумышленников канала. Таким образом, получается, что нам нужно создать частную виртуальную сеть (Virtual Private Network), или VPN. В этот момент перед нами открывается развилка из нескольких путей для претворения задуманного в жизнь:

1. Использовать свободную реализацию IPSec (Internet Protocol Security). В качестве таковой могут выступать FreeSWAN или FreeBSD IPSec.
2. Купить и внедрить коммерческое решение. Например, Cisco VPN или Securepoint VPN Server, который также основан на IPSec, или взять решение от какого-либо другого производителя, например Windows IPSec. В данном разделе я сознательно не делю решения на аппаратные и программные, потому что это всего лишь обзор.
3. Взять на вооружение свободные разработки, использующие криптографические алгоритмы собственного изготовления. Список таких приложений довольно велик. Поэтому перечислим только те, что у всех на слуху – cipe, vpnd, tinc, – этот список можно было бы продолжать очень долго.
4. Самостоятельно написать программное обеспечение, реализующее все механизмы VPN.
5. Использовать PPTP (Point to Point Tunneling Protocol).

Давайте разберемся с достоинствами и недостатками каждой из предлагаемых методик решения проблемы.

Что же можно сказать по поводу первого решения. Последние несколько лет при создании VPN стандартом де-факто считается IPSec. Такая распространенность помогает нам не слишком беспокоиться о совместимости VPN-серверов и клиентов. Все-таки единый стандарт – штука очень удобная. Подобный способ хорош тем, что не потребует больших материальных затрат и в то же время предлагает стойкую криптографическую защиту передаваемых данных. Но на этом его преимущества заканчиваются, и на сцену выходят недостатки. Во-первых, IPSec не обязательно сможет мирно сосуществовать с вашим межсетевым экраном, особенно если тот выполняет над пакетами изуверские операции, называемые в народе NAT. Опять же экраны с контролем состояния соединения (statefull firewall), находящиеся между двумя точками виртуального тоннеля и управляемые провайдером, могут не пропускать те или иные IPSec-пакеты. О кроссплатформенности разных реализаций IPSec пока что остается только мечтать в связи с тем, что для реализации функций IPSec приходится вносить в ядро операционной системы и IP-стек довольно много изменений. Как гласит старинная пословица: «Надежность заканчивается там, где начинается сложная механика», это значит, что одна-единственная ошибка в коде, реализующем IPSec, приведет к огромной дыре в безопасности. Вдобавок, насколько я знаю, на данный момент не существует легко настраиваемого свободного клиента IPSec для Windows. Значит, либо придется разбираться в настройках тех клиентов, что распространяются под эгидой opensource, либо покупать коммерческий. Также стоит обратить внимание на несколько большую сложность установки и настройки такого комплекса по сравнению с остальными типами VPN. Еще одним из минусов является отсутствие технической поддержки. Если что-то пойдет не так, как планировалось, то на квалифицированную помощь от производителя рассчитывать трудно. Это ведь свободный продукт, поэтому придется просить совета либо у своих более удачливых коллег, либо в форумах и списках, посвященных данному программному обеспечению. Впрочем, не каждый производитель проприетарного софта может похвастаться квалифицированной службой поддержки. К тому же обычно у многих свободных разработок существует внушительный лагерь сторонников, которые будут рады обратить вас в свою веру и заодно помочь в настройке программы.

Второй способ выглядит довольно привлекательным в случае, если у вас есть деньги. В обмен на довольно внушительную сумму вы, скорее всего, получите более или менее качественную техническую поддержку, стабильно работающее оборудование и специалистов, которые самостоятельно или по вашим указаниям решат, как именно соединить сети для достижения наилучшего результата. Да и с технической документацией вероятнее всего дело будет обстоять очень хорошо. Но, как всегда в жизни, плюсов без минусов не бывает. Выбрав решение от одного производителя, вы будете впредь очень сильно привязаны к нему. Соответственно, если выбранный вендор не реализует те или иные возможности в своей продуктовой линейке, значит и вы, скорее всего, не сможете ими воспользоваться.

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

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

Вариант решения, основанный на PPT, большей частью используется приверженцами Microsoft. Данный стандарт реализует довольно стойкое шифрование и аутентификацию соединений. Созданный в недрах большой Редмондской корпорации, он не получил особого распространения в мире UNIX. Хотя свободное программное обеспечение для работы с ним все же существует и пользуется некоторым спросом, все же решения на основе IPSec практикуют гораздо чаще. Происходит это, видимо, потому, что IPSec имеет более надежные процедуры шифрования. Но политические мотивы сопротивления со стороны юниксистов новинкам, внедряемым Microsoft, тоже не стоит сбрасывать со счетов.

Ну а большинству читателей, не воспользовавшихся вариантами, предлагаемыми выше, видимо, придется обратиться к программе, которой собственно и посвящена данная статья. Между делом неплохо было бы посетить сайт проекта http://openvpn.sourceforge.net. Ну а я продолжу свое повествование.

История разработки OpenVPN выглядит довольно забавно и в то же время является хрестоматийной иллюстрацией принципов, типичных для движения открытых исходников. В конце 2001 года Джеймс Йонан (James Yonan) успешно выполнил работу над большим проектом для компании, сотрудником которой он является и по сей день. В качестве благодарности работодатель разрешил ему не ходить каждый день на работу и выполнять свои обязанности удаленно. С этого момента жизнь Джеймса кардинально изменилась. Словно в калейдоскопе мелькали страны и континенты: Египет, Кыргызстан, Монголия, Китай. Как обычно, без русских тут не обошлось. Уж очень автора OpenVPN беспокоил тот парадоксальный факт, что в России есть достаточно большое количество безработных, но очень талантливых хакеров. А судя по его наблюдениям, некоторая часть трафика шла именно через российские сети. Объездив всю центральную Азию, Джеймс попутно продолжал искать решение, которое позволит ему работать с центральным офисом удобно, безопасно, надежно и в то же время не будет стоить бешеных денег. Испробовав на себе все вышеперечисленные способы создания VPN, он понял, что на данный момент идеал, к сожалению, недостижим.

Решив разработать свой собственный пакет, реализующий функции VPN, он в отличие от других авторов не стал заниматься созданием своего собственного уникального криптоалгоритма с нуля. Вместо этого был использован проверенный временем и неоднократно доказавший свою надежность стандарт SSL, для работы с которым можно было опереться на доступную для многих систем библиотеку OpenSSL. Стоит отметить, что такая же идея используется и в программном обеспечении, называемом vtun.

Итак, давайте посмотрим поближе на возможности, предоставляемые OpenVPN.

• Официально OpenVPN успешно работает под управлением следующих операционных систем: Linux, Solaris, OpenBSD, FreeBSD, NetBSD, Mac OS X, Windows 2000/XP. Это позволяет создавать сложные кроссплатформенные туннели. Впрочем, не составит никакого труда портировать OpenVPN в любую другую систему, для которой существует драйвер tun/tap-устройств. К тому же данная разработка независима от размера и старшинства байтов в машинном слове, что облегчает перенос на новые операционные системы.
• Компрессия потока передаваемых данных и управление полосой пропускания производятся с помощью библиотеки LZO. Процесс сжатия является адаптивным, то есть попытки упаковать передаваемые данные будут предприняты, только если есть смысл их упаковывать. Эта возможность может быть легко отключена по желанию пользователя, как и любые другие компоненты в случае, если вам не удалось с ними поладить, или если вы хотите поступиться какой-то частью функционала взамен на быстродействие.
• Поддерживаются два типа туннелей: IP и Ethernet, соответственно называемые routed и bridged. Таким образом, появляется возможность туннелировать как IP-подсети, так и виртуальные Ethernet-адаптеры.
• Отлично работает в сетях, где адреса распределяются с помощью DHCP. Помогает подключаться к VPN-клиентам, попадающим в Интернет через dial-up.

• Позволяет создать туннели поверх NAT, несмотря на то что NAT изменяет содержимое заголовков передаваемых пакетов.
• Дает возможность работать с любыми механизмами шифрования, встроенными в OpenSSL для защиты передаваемого трафика. А это, в свою очередь, позволяет каждому клиенту выбрать тип, режим работы (CBC, CFB, OFB) и размер ключа шифра в соответствии с индивидуальными предпочтениями.
• Для аутентификации датаграмм, пересылаемых по туннелю, можно использовать HMAC-дайджест.
• В случае если в передаваемых данных есть повторяющиеся последовательности, для их сокрытия будет использован алгоритм explicit IV.
• Каждая датаграмма помечается с помощью специальных ID, создаваемых на основе времени отправки и номера последовательности. Таким образом предотвращается возможность повторного проигрывания злоумышленником последовательности записанных пакетов.
• В качестве дополнительной меры безопасности может быть использован протокол TLS, позволяющий аутентифицировать сессию с помощью динамического обмена сертификатами. Довольно большой оптимизации быстродействия при динамическом обмене SSL/TLS-ключами позволяет добиться использование мультипоточной библиотеки pthread. Таким образом, даже частый обмен между сервером и клиентом ключами размером более чем 2048 байт практически не влияет на скорость передачи туннелируемых данных.
• Для увеличения безопасности OpenVPN позволяет переместить себя в chroot-окружение и снижает свои привилегии после старта так, чтобы отлично работать от имени самого бесправного пользователя системы.
• Еще одним полезным с точки зрения безопасности свойством является наличие ключа --mlock. Он позволяет запретить OpenVPN записывать в процессе работы на жесткий диск какую-либо информацию, связанную с секретными ключами и данными, передаваемыми по туннелю.
• В связи с тем, что данная программа является всего лишь обычным пользовательским приложением, а не частью ядра, она может вполне мирно сосуществовать с другими приложениями, использующими tun/tap-туннели.
• OpenVPN создавался для тесной интеграции с пользовательскими скриптами и другими высокоуровневыми приложениями. Что в свою очередь дает возможность по первому требованию легко создавать и уничтожать туннели.
• Позволяет удобно работать через межсетевые экраны с контролем состояния соединения. В случае если по туннелю не передаются данные, OpenVPN позволяет через определенные промежутки времени посылать ping, для того чтобы не дать межсетевым экранам разорвать соединение из-за неактивности.

В данной статье мы будем работать только с маршрутизируемыми (routed) туннелями, а разговор о туннелях типа мост (bridge) отложим до следующего раза. Как я уже упомянул ранее, маршрутизируемый туннель умеет работать только с TCP/IP-трафиком. Соответственно широковещательный трафик через него не пройдет. А это значит, что некоторые протоколы вроде Microsoft Netbios работать поверх нашего туннеля не смогут.

Задачей на сегодня будет соединение через VPN трех удаленных филиалов одной организации. Будем считать, что они называются магазин, склад и офис. В каждом из филиалов стоит маршрутизатор, имеющий на борту по два реальных и два виртуальных сетевых интерфейса. Первый из реальных интерфейсов направлен во внутреннюю локальную сеть с серым адресным пространством, а второй – в Интернет. Адреса для внешних интерфейсов выданы нам провайдером и принадлежат к сети 80.80.20.0/24. Для виртуальных tun-интерфейсов выбрана подсеть 10.3.0.0/24.

Таблица 1

Более наглядно все вышеуказанное отображено на приведенной схеме.

Рисунок 1

Итак, начнем установку пакетов на ALT Linux. В системном репозитарии есть все, что нам может понадобиться.

# apt-get update

# apt-get install iptables openssl liblzo liblzo-devel openvpn

После удачного завершения установки создаем пользователя openvpn, входящего в группу openvpn. Процессы openvpn, стартуя от имени пользователя root, будут снижать свои права, чтобы с наименьшими привилегиями работать от имени вышеуказанного пользователя. Согласитесь, что дополнительная безопасность никому не помешает.

# useradd openvpn

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

# openvpn --show-ciphers

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

Для аутентификации каждой получаемой UDP-датаграммы применяется так называемый механизм дайджеста. Смотрим доступные дайджесты:

# openvpn --show-digests

Сначала нужно сгенерировать статический ключ, с помощью которого в дальнейшем будет производиться шифрование потока.

#openvpn --genkey --secret /etc/openvpn/static.key

Внутри файла static.key должно появиться что-то похожее на следующие данные:

После этого можно провести тестирование криптосистемы с использованием только что созданного ключа.

# openvpn --test-crypto --secret /etc/openvpn/static.key

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

Теперь нужно создать конфигурационные файлы, которые опишут наши туннели. Первый из них описывает туннель между машинами Linux и FreeBSD, а второй – между Linux и Windows. Файл linux-freebsd.conf:

proto udp

dev tun

port 5000

comp-lzo

ping 15

verb 3

user openvpn

group openvpn

remote 80.80.20.129

ifconfig 10.3.0.9 10.3.0.10

route 10.10.120.0 255.255.255.0 10.3.0.10

secret /etc/openvpn/static.key

auth MD5

cipher DES-CBC

tun-mtu 1500

Файл linux-windows.conf:

proto udp

dev tun

port 5002

comp-lzo

ping 15

verb 3

user openvpn

group openvpn

remote 80.80.20.128

ifconfig 10.3.0.6 10.3.0.5

route 10.10.130.0 255.255.255.0 10.3.0.5

secret /etc/openvpn/static.key

tun-mtu 1500

auth MD5

cipher DES-CBC

Начинаем разбираться по порядку, что означает каждая из этих опций.

• proto – протокол, используемый для передачи данных. Может принимать значения udp, tcp-client, tcp-server. Настоятельно рекомендуется использовать udp, потому что туннелирование поверх TCP создает слишком большие накладные расходы. Впрочем, если нет другого выхода, то и TCP сойдет. В таком случае нужно на одном конце туннеля установить настройки этой переменной как tcp-server, а на другом – как tcp-client. Соответственно отвечать за инициацию соединения будет машина со значением tcp-client. По умолчанию эта переменная имеет значение udp, поэтому если вы с этим согласны, то ее определение можно в дальнейшем не использовать.
• port – порт, на котором нужно ждать соединений. Должен быть одинаковым на обоих концах туннеля. Номера портов для разных туннелей не могут совпадать.
• dev – тип виртуального устройства туннеля. Может принимать значения tun, tap, null. В этом случае OpenVPN будет пытаться динамически выбрать и задействовать первое свободное устройство данного типа. Если же ему это не удается, то нужно будет четко указать имя устройства с помощью опции dev-node. Например, dev-node tun1.
• comp-lzo – включение упаковки потока данных. В случае если поток все же не стоило упаковывать, размер передаваемых данных увеличится всего на один байт. Впрочем, за все время эксплуатации данного программного комплекса я не встречал случая, когда система адаптивной компрессии ошиблась и стала пытаться применить сжатие там, где делать этого не стоило.
• ping – в случае если по VPN-каналу не передается никаких данных, приказывается отправлять ping каждые n секунд, чтобы не позволить соединению разорваться из-за простоя. Полезно в случае, если между конечными точками vpn находятся межсетевые экраны с контролем состояния.
• verb – уровень подробности выводимых сообщений. Чем больше число, тем многословнее и педантичнее программа будет рассказывать о том, что происходит у нее внутри. Верхним пределом для этой переменной является число 11. Данная опция чаще всего используется при отладке и первоначальной настройке туннелей.
• user, group – имя пользователя и группы, от имени которой будет работать программа. Первоначально openvpn стартует от имени root и, прочитав все интересующие файлы, снижает привилегии до указанного уровня.
• remote – IP-адрес хоста, представляющего из себя дальнюю сторону туннеля. Если его не указать, то openvpn будет пассивно принимать все входящие соединения, не пытаясь самостоятельно соединяться с удаленной машиной. Затем все полученные соединения должны будут пройти авторизацию. Данный режим удобен для работы с dial-up системами, у которых постоянно меняется IP-адрес.
• ifconfig – назначает виртуальному tun/tap интерфейсу IP-адрес. Заодно указывает адрес удаленного виртуального интерфейса. Это необходимо, потому что туннель работает как стандартное соединение «точка-точка».
• route – описывает маршрут, который должны пройти пакеты, чтобы попасть в удаленную сеть. Можно обозначить маршрут двумя способами. Либо с помощью этой настройки, либо переменной up, значением которой необходимо указать имя командного скрипта, отвечающего за выполнение правильной настройки маршрутизации. В случае если вы пользовались первым способом настройки маршрутизации, то openvpn самостоятельно удалит из таблицы маршрутов нужную запись, когда пользователь попросит его завершить работу. Ну а если прибегали к услугам опции up, то необходимо также описать опцию down, которая будет указывать на скрипт, выполняющий самостоятельные действия по удалению маршрута.
• secret – указывает имя файла, в котором хранится статический ключ, используемый для шифрования потока.
• tun-mtu – максимальный размер пакета, передаваемого по виртуальному интерфейсу. Пакеты большего размера будут разбиваться на несколько кусков и передаваться последовательно отдельными датаграммами. Желательно, чтобы на обоих концах туннеля значение этой переменной было одинаково, иначе можно провести несколько интересных часов в забавном поиске причины, почему авторизация и передача первых пакетов проходит нормально, а затем все начинает работать весьма медленно и нестабильно.
• auth – наименование алгоритма, используемого для аутентификации приходящих пакетов. В моем случае это MD5. Хотя никто не мешает взять любой другой.
• cipher – алгоритм, используемый для шифрования пакетов. Blowfish выбран потому, что является весьма стойким и в то же время достаточно быстрым. В случае если хочется повысить надежность шифрования, нужно использовать переменную keysize и указывать большой размер ключа. По умолчанию Blowfish использует ключ длиной 128 бит, хотя максимально возможный размер – 448 бит.

На этом установку и первоначальную настройку пакета на Linux-машине можно считать завершенной. Переходим на FreeBSD. Как человек рассудительный и здравомыслящий, предпочитаю устанавливать сложное программное обеспечение из портов.

# cd /usr/ports/archivers/lzo

# make install clean

# cd ../../security/openssl

# make install clean

# cd ../openvpn

# make install clean

К сожалению, несмотря на то что перед началом инсталляции я обновил список портов, система упрямо не хотела ставить openvpn-1.6.0, а вместо него подсовывала openvpn-1.4.0.

Дабы не наступать на грабли и впоследствии не ломать голову над совмещением разных версий, пришлось деинсталлировать ранее установленную версию 1.4.0. Хотя в документации описано, как «подружить» старые и новые версии, я решил рисковать.

# make deinstall

Отправляемся по адресу: http://www.freebsd.org/cgi/ports.cgi?query=openvpn&stype=all и с помощью поиска выясняем, что исходные тексты самой свежей версии порта openvpn-1.6.0 не желают скачиваться. Ну на нет и суда нет. Видимо, такова судьба, и нам придется снова пойти в обход. Берем отсюда бинарный пакет ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-4-stable/All/openvpn-1.6.0.tgz и устанавливаем его с помощью утилиты pkg_add.

# pkg_add openvpn-1.6.0.tgz

Не забываем добавить в систему пользователя и группу openvpn.

# adduser openvpn

Затем создаем директорию /etc/openvpn, где у нас будут храниться файлы с настройками и ключом. С помощью какого-либо безопасного транспорта переносим с Linux-машины файл static.key. В качестве средства, пригодного для этой цели, можно использовать scp, sftp, архив с паролем или просто дискету, переданную доверенным лицом. Теперь давайте посмотрим на содержимое конфигурационных файлов.

Файл freebsd-linux.conf:

dev tun

port 5000

comp-lzo

ping 15

verb 3

user openvpn

group openvpn

remote 80.80.20.131

ifconfig 10.3.0.10 10.3.0.9

route 10.10.140.0 255.255.255.0 10.3.0.9

secret /etc/openvpn/static.key

auth MD5

cipher DES-CBC

tun-mtu 1500

comp-lzo

Файл freebsd-windows.conf:

dev tun

remote 80.80.20.128

port 5001

ifconfig 10.3.0.1 10.3.0.2

route 10.10.130.0 255.255.255.0 10.3.0.2

secret /etc/openvpn/static.key

ping 10

verb 3

tun-mtu 1500

user openvpn

group openvpn

auth MD5

cipher DES-CBC

comp-lzo

Я думаю, что, пользуясь предыдущими объяснениями, будет довольно легко понять все используемые настройки. Права на директорию /etc/openvpn и файлы в ней должны позволять чтение только пользователю root и группе wheel.

Если очень хочется, то можно выполнить проверку доступных шифров так же, как мы делали это для Linux.

Наконец-то мы готовы к запуску первого из наших туннелей. На Linux-машине выполняем следующую команду:

# openvpn --config /etc/openvpn/linux-freebsd.conf

И соответственно на FreeBSD делаем так:

# openvpn --config /etc/openvpn/freebsd-linux.conf

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

Ну а FreeBSD-машина должна говорить что-то вроде этого:

Как только увидите надпись «Peer Connection Initiated with», считайте, что дело сделано. Теперь с помощью команды ping можно проверить, видны ли оконечные адреса из соединяемых частных сетей. В нашем примере это 10.10.120.1 и 10.10.140.1. Не забываем настроить компьютеры, находящиеся в наших локальных сетях так, чтобы они считали машины Linux и FreeBSD шлюзами по умолчанию.

Кстати, стоит отметить, что openvpn может вполне успешно работать и без всяких конфигурационных файлов. Дело в том, что все параметры можно передать в программу и из командной строки. К примеру, для поднятия того же самого туннеля можно было скомандовать вот так:

# openvpn --remote 80.80.20.128 --dev tun --port 5001 --ifconfig 10.3.0.1 10.3.0.2 --route 10.10.130.0 255.255.255.0 10.3.0.2

--secret /etc/openvpn/static.key --ping 10 --verb 3 --tun-mtu 1500 --user openvpn --group openvpn --auth MD5 --cipher DES-CBC

Хотя, с моей точки зрения, данный способ выглядит несколько громоздко.

Стоит отметить один интересный факт: дистрибутив openvpn для Linux устанавливает в систему скрипт /etc/rc.d/init.d/openvpn, который помогает удобно управлять нашими туннелями с помощью команды service openvpn. Главной особенностью скрипта является способность поднять туннели для всех *.conf-файлов, находящихся в /etc/openvpn. Таким образом, нам не надо придумывать, как автоматически запустить требуемое количество экземпляров openvpn с нужными настройками после перезагрузки системы.

Во FreeBSD тоже есть скрипт подобного предназначения. Сразу после инсталляции он обычно находится в /usr/local/etc/rc.d/openvpn.sh.sample. Посмотрев внутрь него, понимаем, что он совершенно бесполезен, так как практически ничего не умеет делать. Поэтому нам придется смастерить свой собственный вариант такого скрипта. Для этого нужно создать файл openvpn.sh и внести в него следующие данные:

#! /bin/sh

case x$1 in

  xstart)

            /usr/local/sbin/openvpn --config /etc/openvpn/freebsd-linux.conf &

            /usr/local/sbin/openvpn --config /etc/openvpn/freebsd-windows.conf &

  ;;

  xstop)

            killall -SIGTERM openvpn

            route delete 10.10.130.0

            route delete 10.10.140.0

            ;;

  *)  echo >&2 "Usage: $0 {start|stop}"

esac

Обязательно кладем файл в /usr/local/etc/rc.d/ и даем ему право на выполнение. Стоит обратить внимание на наличие знака «&» после запуска каждого экземпляра openvpn. Сделано это потому, что данная программа жестко привязывается к терминалу, с которого была запущена. Соответственно при отсутствии этого знака второй процесс openvpn не запустится до тех пор, пока терминал не освободится, а этого при правильном развитии событий не должно произойти никогда. Вторым важным моментом является наличие команд route, удаляющих записи о маршрутах в той ветке скрипта, которая отвечает за выполнение действия stop. Удалять маршруты приходится вручную, потому что к моменту завершения работы openvpn выполняется от лица одноименного пользователя и группы, а изменять таблицу маршрутизации имеет право только root. Конечно, можно было бы портировать под FreeBSD версию скрипта, поставляющуюся в комплекте с Linux-версией программы, но сейчас заниматься этим как-то недосуг. Возможно, я сделаю это в следующей статье.

Настало время перейти к настройке Windows-системы. На первый взгляд здесь все довольно просто. Берем дистрибутив для этой платформы на родном сайте программы http://prdownloads.sourceforge.net/openvpn/openvpn-1.6.0-install.exe. Затем запускаем только что скачанный инсталлятор и методично жмем на кнопки «Далее» и «ОК». После установки в систему будет добавлен новый сетевой интерфейс со странным именем «Подключение по локальной сети 3».

Рисунок 2

Если присмотреться внимательно к свойствам данного подключения, то можно заметить что оно представляет собой не что иное, как интерфейс tap.

Рисунок 3

Тут стоит сделать одну важную оговорку: под Windows не существует различия между tun- и tap-устройствами. А еще точнее было бы сказать, что такая реализация tap-драйвера позволяет устройству работать в любом из двух режимов.

Для нас столь длинное название устройства неудобно, поэтому переименовываем его во что-нибудь более краткое и информативное. Например, в Linux. Затем с помощью меню «Пуск –> Программы –> Open –> VPNAdd a new TAP-win32 virtual ethernet adapter» создаем еще один виртуальный интерфейс и переименовываем его во FreeBSD. Думаю, название каждого из этих интерфейсов достаточно красноречиво говорит об их предназначении. Надеюсь, что все еще помнят, зачем мы создавали файл static.key. Если это действительно так, то копируем его в C:Program FilesOpenVPNconfig под именем staic.txt. По непонятной причине файлы с расширением .key openvpn, работающие под Windows, не воспринимаются как секретные ключи. Затем создаем конфигурационные файлы наших туннелей. Стоит обратить внимание на тот факт, что для успешной работы у этих файлов должно быть расширение .ovpn.

Файл windows-freebsd.ovpn:

remote 80.80.20.129

dev-node FreeBSD

dev tun

port 5001

ifconfig 10.3.0.2 10.3.0.1

secret static.txt

ping 10

verb 3

route 10.10.120.0 255.255.255.0 10.3.0.1

auth MD5

cipher DES-CBC

comp-lzo

Файл windows-linux.ovpn:

remote 80.80.20.131

dev tun

dev-node Linux

port 5002

ifconfig 10.3.0.5 10.3.0.6

secret static.txt

ping 10

verb 3

route 10.10.140.0 255.255.255.0 10.3.0.6

tun-mtu 1500

comp-lzo

В сущности, все тесты, которые мы использовали до этого, отлично работают и под управлением Windows. Поэтому, если есть желание, можете выполнить openvpn с параметрами --show-digests и --show-ciphers. Единственное, на что стоит обратить внимание, – это обязательное наличие в конфигурационном файле записи dev-node с именем используемого устройства. К сожалению, Windows умеет автоматически находить и использовать нужное виртуальное устройство туннеля только в том случае, если оно в системе представлено в единственном числе. Кстати, стоит отметить тот факт, что в случае работы устройства tun под Windows использовать для туннеля какие попало адреса из подсети 10.3.0.0 не получится, придется выбирать из таблицы, выводимой командой openvpn --show-valid-subnets.

Как и под UNIX-системами, можно поднять туннель вызовом openvpn с указанием имени используемого конфигурационного файла, а можно и без него, просто перечислив все нужные ключи в командной строке. Есть еще два способа запуска туннеля. Первый из них состоит в том, что нужно с помощью проводника перейти в директорию C:Program FilesOpenVPNconfig и щелкнуть правой клавишей на файле конфигурации. В ниспадающем меню выбрать «Start OpenVPN on this config file». А можно поступить более умно и включить службу OpenVPN, которая самостоятельно будет заботиться о том, чтобы запустить по одному экземпляру программы для каждого конфигурационного файла.

Рисунок 4

На этом радостном этапе установку и настройку можно считать завершенными. На обоих UNIX-машинах сначала останавливаем, а затем снова запускаем сервисы openvpn.

# service openvpn stop

# service openvpn start

# /usr/local/etc/rc.d/openvpn.sh stop

# /usr/local/etc/rc.d/openvpn.sh start

То же самое проделываем и под управлением Windows.

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

А для FreeBSD будет характерна следующая картина:

Ну и на закуску осталось посмотреть на интерфейсы Windows:

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

Теперь хотелось бы разобраться, как обстоит дело с шифрованием. Для этого начинаем прослушивание интерфейсов tun0 – 10.3.0.10 и lnc1 – 80.80.20.129 и снова выполняем ping 10.10.140.1. Таким образом, мы видим, что через tun0 пакеты icmp идут в открытом виде.

# tcpdump -i tun0 –len

А проходя через интерфейс lnc1, в Интернет они попадают уже зашифрованными:

# tcpdump -i lnc1 –lenx

Таким образом, видно, что поставленную задачу мы успешно выполнили.

Комментарии могут оставлять только зарегистрированные пользователи