Содержание:
Когда речь заходит о необходимости предоставления авторизированному пользователю доступа к защищенным ресурсам частной сети, на ум сразу приходят примеры построения VPN на базе IPSec, PPTP, L2TP и SSL. Однако если требуется в кратчайшие сроки развернуть бесплатное, кроссплатформенное, полнофункциональное ПО с гибкими возможностями конфигурирования и относительно простой установкой, не требующей вмешательства в ядро ОС, то из всех доступных решений выбор невольно падает на OpenVPN.
OpenVPN является реализацией технологии VPN с использованием протокола SSL/TLS.
С его помощью можно поднять надежный, достаточно быстрый и в то же время
защищенный от прослушивания и вмешательства злоумышленников криптотуннель
поверх общедоступной сети, такой, как Интернет. В двух словах схему работы
этого приложения можно описать следующим образом: любой сетевой трафик,
посылаемый или принимаемый для сетевого адаптера, инкапсулируется в
зашифрованный пакет и доставляется в другой конечный пункт туннеля OpenVPN, где
данные расшифровываются и попадают в удаленную сеть.
К числу основных преимуществ применения OpenVPN стоит отнести:
Как видишь, список возможностей впечатляет, но в отличие от других SSL VPN, достоинством которых считается безклиентская установка (соединение SSL VPN устанавливается через браузер), для OpenVPN необходим специальный клиент (поговорим об этом ниже).
Предположим, одним прекрасным солнечным утром твое высокое начальство
впечатлилось идеей создания виртуальной частной сети, и теперь перед тобой
стоит задача поднять VPN-сервер для служащих, которым требуется работать с
корпоративными ресурсами, находясь вне стен офиса (это могут быть надомные,
командировочные сотрудники или просто фрилансеры).
Функции шлюза компании, выпускающего сотрудников в Интернет, выполняет
компьютер с тремя сетевыми картами (213.167.XX.YY, 192.168.1.1, 192.168.2.1)
под управлением... хотя это не так важно, настройки в поддерживаемых
операционках будут отличаться минимально. В моем случае на сервере заказчика
была установлена OpenBSD 3.9. Что касается корпоративной внутренней сети, то
она состоит из двух участков: проводного (192.168.1.0/24) и беспроводного
(192.168.2.0/24). После рекогносцировки на местности переходим к установке
OpenVPN.
OpenVPN без труда можно найти в любом репозитарии или дереве портов:
# cd /usr/ports/net/openvpn # make install clean
В случае установки из исходных кодов в некоторых системах может понадобиться отключить поддержку реализации потоков выполнения и указать местоположение библиотек и заголовочных файлов lzo:
# ./configure --disable-pthread --with-lzo-lib=/usr/local/lib \ --with-lzoheaders=/usr/local/include # make # make install
Для проверки с помощью следующих команд можно посмотреть, какие дайджесты (применяются для аутентификации каждой получаемой UDP-датаграммы) и алгоритмы шифрования доступны:
# /usr/local/sbin/openvpn --show-digests # /usr/local/sbin/openvpn --show-ciphers
Чтобы обеспечить дополнительный уровень защиты и избежать возможный ущерб при взломе, нужно дать указание демону OpenVPN работать с правами непривилегированного пользователя в chroot'ной среде - среде с измененным корневым каталогом. Первый шаг для этого - добавить в систему группу _openvpn и одноименного пользователя:
# groupadd -g 500 _openvpn # useradd -u 500 -g 500 -c 'OpenVPN Server' -s /sbin/nologin \ -d /var/openvpn -m _openvpn
Проверяем правильность выполнения двух последних команд:
# grep 500 /etc/passwd _openvpn:*:500:500:OpenVPN Server:/var/openvpn:/sbin/nologin
Думаю, ни для кого не секрет, что сертификаты открытых ключей предоставляют
удобный и надежный способ аутентификации пользователей, поэтому не будем сейчас
тратить время на теоретическую часть и перейдем непосредственно к процедуре
генерирования надлежащих сертификатов.
Создаем директорию, где будут лежать конфигурационные файлы, скрипты и
сертификаты:
# mkdir -p /etc/openvpn/keys
Копируем комплект скриптов easy-rsa, предназначенный для упрощения создания сертификатов, которые предъявляются в процессе аутентификации для подтверждения валидности клиентов. Теперь о монстроидальных командах openssl можно забыть.
# cp -r /usr/local/share/examples/openvpn/easy-rsa /etc/openvpn
Далее следует экспортировать переменные KEY_*, они необходимы для работы build-* скриптов:
# cd /etc/openvpn/easy-rsa # . ./vars
Инициализируем директорию /etc/openvpn/easy-rsa/keys:
# ./clean-all
Создаем корневой и серверный сертификаты:
# ./build-ca # ./build-key-server server
Для создания файла параметров Диффи-Хэлмана, предназначенного для обеспечения более надежной защиты данных при установке соединения клиента с сервером, выполняем:
# ./build-dh
Снизить вероятность успешного проведения DoS-атаки на сервер OpenVPN можно за счет использования клиентом и сервером статического ключа HMAC (так называемый shared secret):
# /usr/local/sbin/openvpn --genkey --secret keys/ta.key
Перемещаем все созданные файлы в подкаталог keys и выставляем для них корректные права доступа:
# cd keys/ # mv ca.crt dh1024.pem server.crt server.key ta.key /etc/openvpn/keys # chown -R root:wheel /etc/openvpn # chmod 700 /etc/openvpn/keys # chmod 644 /etc/openvpn/keys/{ca.crt,dh1024.pem,server.crt} # chmod 600 /etc/openvpn/keys/{server.key,ta.key}
Процедура создания клиентских сертификатов практически аналогична соответствующей процедуре для сервера:
# ./build-key client1 # mkdir -p /home/vpn/client1 # mv client1.crt client1.key /home/vpn/client1 # cp /etc/openvpn/keys/{ca.crt,ta.key} /home/vpn/client1
Теперь подкаталог client1 следует перенести на винч или флешку "географически изолированного" сотрудника.
Конфигурация сервера OpenVPN хранится в файле /etc/openvpn/server.conf. Ниже приведен пример подобного конфига. Все опции детально прокомментированы, поэтому сложностей возникнуть не должно. При настройке старайся "не срезать углы" - за один шаг добавляй/изменяй что-то одно и сразу же тестируй. Все действия в server.conf желательно фиксировать в локальном cvs-репозитории, чтобы можно было быстро просмотреть историю изменений и вернуться к рабочей ревизии.
# vi /etc/openvpn/server.conf ; Работаем в режиме демона daemon openvpn ; Указываем местоположение файла с уникальным идентификатором процесса сервера ; OpenVPN writepid /var/openvpn/pid ; Определяем файл, содержащий список текущих клиентских соединений status /var/openvpn/status 10 ; Внешний IP-адрес нашего сервера local 213.167.XX.YY ; Используемый порт port 1194 ; Для транспорта по умолчанию применяется протокол UDP. Это вполне резонный ; подход. Во-первых, благодаря меньшему размеру заголовков и отсутствию ; встроенной функции подтверждения доставки пакетов, производительность UDP ; значительно выше. А во-вторых, при использовании UDP общая надежность не ; снижается, так как OpenVPN шифрует исходные пакеты, обеспечивая проверку ; ошибок и повторную передачу. В связи с этим TCP рекомендуется применять ; только в тех случаях, когда UDP не работает, например, если брандмауэр ; блокирует весь UDP-трафик. proto udp ; Выбираем тип виртуального устройства туннеля (tun, tap или null) dev tun0 ; Включаем компрессию передаваемых данных comp-lzo ; Указываем абсолютные пути к созданным сертификатам и ключам ca /etc/openvpn/keys/ca.crt cert /etc/openvpn/keys/server.crt key /etc/openvpn/keys/server.key dh /etc/openvpn/keys/dh1024.pem ; Значение 0 следует использовать на сервере, 1 - на клиенте tls-auth /etc/openvpn/keys/ta.key 0 ; Для большинства сетей подойдет режим маршрутизатора (routed). Да, в этом ; случае широковещательный трафик отсутствует, соответственно, не будут работать ; некоторые протоколы, которые его используют, например NetBIOS поверх TCP. Но ; последнее нивелируется развертыванием WINS-сервера, либо подключением сетевых ; дисков/созданием ярлыков на расшаренные ресурсы server 192.168.3.0 255.255.255.0 ; Проталкиваем подключенным клиентам статические маршруты, чтобы они могли ; получить доступ к ресурсам проводной и беспроводной сети push "route 192.168.1.0 255.255.255.0" push "route 192.168.2.0 255.255.255.0" ; Не позволяем соединению разорваться при простое keepalive 10 120 ; Алгоритмы, используемые для аутентификации и шифрования пакетов auth SHA1 cipher AES-256-CBC ; Максимальное число одновременно подключенных VPN-пользователей max-clients 10 ; Задаем файл журналирования событий и уровень детализации журнала, отображаем ; не более 20 экземпляров одного сообщения (остальные отбрасываем) log-append /var/log/openvpn.log verb 3 mute 20 ; Пользователь и группа, с правами которых работает демон user _openvpn group _openvpn ; Эти опции предотвращают доступ к некоторым ресурсам (например, ; tun-устройству) при перезапуске демона (рекомендуется применять только при ; снижении привилегий) persist-key persist-tun ; Сажаем демона в chroot-окружение chroot /var/empty
Чтобы не вбивать директивы вручную, можно воспользоваться примером конфига, любезно предоставленным разработчиками:
# cp /usr/local/share/examples/openvpn/sample-config-files/server.conf /etc/openvpn
Поднимаем виртуальный интерфейс tun0:
# echo "up" > /etc/hostname.tun0 # sh /etc/netstart tun0
Запускаем сервер OpenVPN командой:
# /usr/local/sbin/openvpn --config /etc/openvpn/server.conf
Для автоматической загрузки OpenVPN достаточно прописать эту строчку в стартовый сценарий /etc/rc.local, например, так:
# vi /etc/rc.local if [ -x /usr/local/sbin/openvpn ]; then echo -n ' openvpn'; /usr/local/sbin/openvpn --config /etc/openvpn/server.conf fi
Далее смотрим в логи, чтобы убедиться в успешной загрузке нашего демона:
# tail /var/log/openvpn.log Sun Dec 2 15:31:37 2007 IFCONFIG POOL: base=192.168.3.4 size=62 Sun Dec 2 15:31:37 2007 Initialization Sequence Completed
Чтобы проверить состояние псевдоустройства туннелирования, можно воспользоваться утилитой ifconfig:
# ifconfig tun0 tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 groups: tun inet 192.168.3.1 --> 192.168.3.2 netmask 0xffffffff
Для корректной работы сервера OpenVPN необходимо разрешить прохождение любого трафика через интерфейс OpenVPN, а также входящие подключения на внешний адрес сервера порт 1194/udp:
# vi /etc/pf.conf pass quick on { lo tun0 $int_if } inet pass in on $ext_if inet proto udp from any to $ext_if port 1194 \ keep state
Перезагружаем набор рулесетов файервола:
# pfctl -f /etc/pf.conf
Итак, VPN-сервер работает и готов принимать подключения. Развертывание VPN-клиентов для VPN-подключений удаленного доступа состоит из двух действий: установка программы OpenVPN GUI и правка конфигурационного файла client*.ovpn.
C:\Program Files\OpenVPN\config\mycompany_client1.ovpn ; Работаем в режиме клиента client dev tun ; Указываем IP-адрес и порт VPN-сервера remote 213.167.XX.YY 1194 proto udp resolv-retry infinite nobind pull comp-lzo persist-key persist-tun verb 3 ; Я предпочитаю хранить crt и key файлы на флешке ca "f:\\vpn\\mycompany\\ca.crt" cert "f:\\vpn\\mycompany\\client1.crt" key "f:\\vpn\\mycompany\\client1.key" tls-auth "f:\\vpn\\mycompany\\ta.key" 1 ns-cert-type server ; Нижеследующие алгоритмы должны совпадать с теми, что заданы на сервере auth SHA1 cipher AES-256-CBC ; Без этих двух директив Vista-клиенты не смогут получать маршруты от сервера ; route-method exe ; route-delay 2
Теперь для подключения к VPN-серверу достаточно в трее щелкнуть правой кнопкой мыши на значке с красными мониторчиками, выбрать конфиг mycompany_client1 и нажать Connect.
В BSD-системах, используя связку пакетного фильтра pf и авторизационного шелла
authpf, можно контролировать доступ клиентов, подключающихся к VPN-службе и
корпоративной сети. Схема работы такой конструкции довольно проста:
пользователь логинится по ssh, и, в зависимости от введенных данных (имя и
пароль), на сервере вступают в силу персональные правила файервола, в данном
случае разрешающие прохождение UDP-пакетов к порту 1194.
Но прежде, чем производить настройку authpf, необходимо переопределить
некоторые дефолтные значения переменных демона sshd(8). Так мы усложним
потенциальному злоумышленнику успешное проведение атаки с целью перехвата и
подмены ssh-сессии.
# vi /etc/ssh/sshd_config # Работаем с использованием протоколов IPv4 и ssh2 AddressFamily inet Protocol 2 # Ожидаем подключения по всем доступным сетевым интерфейсам ListenAddress 0.0.0.0 # Запрещаем регистрацию root'а и применение пустых паролей PermitRootLogin no PermitEmptyPasswords no # За счет использования протокола ssh2 и этих двух опций усложняем проведение # атак типа ARP- и IP-spoofing ClientAliveInterval 15 ClientAliveCountMax 3 # Отключаем DNS-резолвинг UseDNS no # Определяем списки контроля доступом AllowGroups wheel users authpf
Для того чтобы внесенные изменения вступили в силу, необходимо дать указание демону перечитать свой конфиг:
# kill -HUP `sed q /var/run/sshd.pid`
Authpf представляет собой псевдооболочку, которая назначается пользователю
системы в качестве login shell (примечание: запись "/usr/sbin/authpf" в файл
/etc/shells добавлять не следует). При авторизации пользователя по ssh к
текущим правилам фильтра пакетов с помощью так называемых якорей (anchors)
будут присоединены правила, указанные в файле /etc/authpf/authpf.rules, либо в
/etc/authpf/users/$USER. В добавляемых правилах допускается использование
зарезервированных макросов $user_id и $user_ip, за счет которых будет
происходить автоматическая подстановка имени и IP-адреса подключившегося
пользователя (значения макросов считываются из переменных окружения ssh
автоматически).
В конец файла login.conf(5) заносим сведения о новом классе authpf,
пользователи которого в качестве стандартного шелла будут получать authpf:
# vi /etc/login.conf authpf:\ :shell=/usr/sbin/authpf:\ :tc=default:
С помощью штатной утилиты cap_mkdb(8) обновляем хэшированную базу данных /etc/login.conf.db:
# cap_mkdb /etc/login.conf
Мы не будем переопределять умолчальные значения директив anchor и table, поэтому файл authpf.conf оставляем пустым:
# echo -n > /etc/authpf/authpf.conf
Подготавливаем приветственное сообщение authpf.message (аналог /etc/motd):
# vi /etc/authpf/authpf.message This service is for authorised VPN-clients only. Please play nice.
Создаем нового пользователя, который принадлежит классу authpf, входит в группу authpf и в качестве оболочки получает /usr/sbin/authpf:
# useradd -m -c 'authpf vpn user' -g authpf -L authpf \ -s /usr/sbin/authpf client1 # passwd client1
Рисуем правило файервола, разрешающее пользователю client1 доступ к серверу OpenVPN:
# mkdir -p /etc/authpf/users/client1
# vi /etc/authpf/users/client1/authpf.rules pass in log quick on fxp0 inet proto udp from $user_ip to fxp0 \ port 1194 keep state
Теперь для подключения механизма якорей добавим следующие записи в pf.conf(5):
# vi /etc/pf.conf nat-anchor "authpf/*" rdr-anchor "authpf/*" binat-anchor "authpf/*" ... pass in log on $ext_if inet proto tcp to fxp0 port ssh keep state ... anchor "authpf/*"
И перезагрузим набор рулесетов файервола:
# pfctl -f /etc/pf.conf
На стороне клиента открываем любой ssh-клиент, например, Putty или SecureCRT, создаем новую сессию, указываем IP-адрес сервера и имя пользователя. Если все настроено правильно, после успешной авторизации правила файервола на сервере для этого пользователя изменятся, и он получит доступ к VPN-службе.
# f:\vpn\putty> plink.exe -pw mypassword client1@213.167.XX.YY Hello client1. You are authenticated from host "77.41.XX.YY" This service is for authorised VPN-clients only. Please play nice.
А чтобы постоянно не вводить пароль, можно настроить аутентификацию на базе публичного ключа.
Эта статья включает полный набор пошаговых действий, необходимых для внедрения базового VPN-решения удаленного доступа, используя BSD-систему в качестве VPN-сервера и WinXP/Vista в качестве VPN-клиента. Развернув в 3-4 компаниях подобную конфигурацию, ты сможешь не с пустыми кредиткой и кошельком ехать в Египет греть пятки. Удачи.