В этой статье я расскажу об одном из вариантов настройки сервера удаленного доступа IPSec VPN на базе OpenSwan. Для клиентского подключения будут использоваться GreenBow VPN Client и Shrew VPN. Аутентификация с использованием Preshared Key.
Итак у нас имеется сервер с CentOS 5.5 один из интерфейсов смотрит в интернет и имеет внешний IP 10.10.11.10 и шлюз 10.10.11.1 (адреса IP и шлюза взяты исключительно для данного примера и не имеют отношения к внешним адресам), другой интерфейс имеет IP 192.168.0.1 и является шлюзом для корпоративной подсети 192.168.0.0/24. Виртуальная подсеть для VPN клиентов 192.168.10.0/24 – ее использование в данном случае упрощает ограничение доступа для удаленных пользователей к ресурсам организации. Ну и пара клиентских компьютеров как показано на рисунке ниже.
1. Установка OpenSwan
OpenSwan есть в стандартном репозитории CentOS, однако версия 2.6.21 увы не поддерживает множественные подключения с различными ключевыми фразами в агрессивном режиме (здесь по-моему просто теряется смысл использования менее защищенного агрессивного режима). Поэтому берем более новую версию с сайта openswan.org и устанавливаем:
[root@localhost ~]# wget http://openswan.org/download/binaries/centos/5/without-nss/openswan-2.6.26-1.i386.rpm [root@localhost ~]# rpm -ihv openswan-2.6.26-1.i386.rpm
Для нормальной работы скриптов необходимо установить which и lsof:
[root@localhost ~]# yum install which lsof
Открываем файл /etc/sysctl.conf и меняем значение net.ipv4.ip_forward c 0 на 1, тем самым разрешая форвардинг пакетов и дописываем две строчки запрещающие ICMP send redirects и ICMP accept redirects:
net.ipv4.ip_forward = 1 # Разрешаем форвардинг пакетов net.ipv4.conf.default.send_redirects = 0 # Отключаем ICMP send redirects net.ipv4.conf.default.accept_redirects = 0 # Отключаем ICMP accept redirects
Применяем сделанные изменения
[root@localhost ~]# sysctl -p
2. Настройка подключений
На данном этапе я не буду углубляться в упрощение описания за счет использования директив also и %default или расположения описаний подключений в отдельных файлах – по моему главное сделать максимально простой и работоспособный пример.
Открываем файл /etc/ipsec.conf и приводим его к следующему виду.
# /etc/ipsec.conf - Openswan IPsec configuration file # # Manual: ipsec.conf.5 # # Please place your own config files in /etc/ipsec.d/ ending in .conf version 2.0 # conforms to second version of ipsec.conf specification # basic configuration config setup # Debug-logging controls: "none" for (almost) none, "all" for lots. # klipsdebug=none # plutodebug="control parsing" # For Red Hat Enterprise Linux and Fedora, leave protostack=netkey protostack=netkey nat_traversal=yes # Использование NAT-T необходимо для # прохождения пакетов UDP через NAT virtual_private=%v4:192.168.10.0/24 # Описание виртуальной подсети для # VPN-клиентов oe=off # Enable this if you see "failed to find any available worker" nhelpers=0 # Секция описания первого подключения conn conn-cl02 authby=secret # аутентификация по Preshared Key aggrmode=yes # агрессивный режим настроек - необходим для # идентификации клиента с динамическим IP # по FQDN или User FQDN # Все настройки начинающиеся с left относятся к локальному узлу left=%defaultroute # IP внешнего интерфейса # %defaultroute - выбор по умолчанию leftnexthop=%defaultroute # Шлюз внешнего интерфейса # %defaultroute - выбор по умолчанию leftsubnet=192.168.0.1/24 # Адрес локальной подсети leftid=@gate.my.domain # ID локального хоста FQDN # Все настройки начинающиеся с right относятся к удаленному узлу right=%any # внешний IP удаленного хоста, директива %any # говорит о том что может использоваться # любой адрес rightsubnet=vhost:%priv # Виртуальный адрес клиента из подсети # указанной в ранее директиве virtual_private rightid=cl02@my.domain # ID удаленного хоста - UFQDN # Настройки алгоритмов шифрования и обмена ключами auth=esp keyexchange=ike ike=3des-sha1-modp1024! # Параметры фазы 1, формат: # кодирование-аутентификация-ключ группы # Восклицательный знак в конце означает, что # сервер будет принимать подключения только с # заданными настройками фазы. esp=3des-sha1! # Параметры фазы 2, формат: # кодирование-аутентификация pfs=yes # С версии 2.3 в openswan нет параметра # pfsgroup при включении pfs значениее # pfsgroup берется из фазы 1 # Настройка запуска подключения auto=add # add - загрузить подключение и отвечать # на входящее запросы # Cекция описания второго подключения - совершенно аналогичная первой, # единственное отличие значение rightid=cl03@my.domain - User FQDN второго # клиента conn conn-cl03 authby=secret aggrmode=yes left=%defaultroute leftnexthop=%defaultroute leftsubnet=192.168.0.1/24 leftid=@gate.my.domain right=%any rightsubnet=vhost:%priv rightid=cl03@my.domain auth=esp keyexchange=ike ike=3des-sha1-modp1024! esp=3des-sha1! pfs=yes auto=add # Эту директиву можно раскомментировать и переместить описания подключений в # разных файлах в директорию /etc/ipsec.d, скажем так описание conn-cl02 в # файл /etc/ipsec.d/conn-cl02.conf, а описание conn-cl03 в файл # /etc/ipsec.d/conn-cl03.conf. При наличии 2-х десятков подключений это может # немножко облегчить жизнь. #include /etc/ipsec.d/*.conf
Открываем файл /etc/ipsec.secrets
# Формат записи: список идентификаторов хостов: PSK "парольная фраза" # В нашем случае: leftid rightid: PSK "парольная фраза" @gate.my.domain cl02@my.domain: PSK "password.for.cl02" @gate.my.domain cl03@my.domain: PSK "password.for.cl03" # Точно такая же директива как и в ipsec.conf #include /etc/ipsec.d/*.secrets
Добавляем в iptables
# Разрешаем прохождение через файрвол для следующих протоколов: # 1. IKE - UDP порт 500 # 2. NAT-T - UDP порт 4500 # 3. ESP - протокол 50 # eth0 - внешний интерфейс iptables -A INPUT -i eth0 -p udp --dport 500 -j ACCEPT iptables -A INPUT -i eth0 -p udp --dport 4500 -j ACCEPT iptables -A INPUT -i eth0 -p 50 -j ACCEPT
Добавляем сервис ipsec в автозапуск и запускаем
[root@localhost ~]# chkconfig ipsec on [root@localhost ~]# service ipsec start ipsec_setup: Starting Openswan IPsec U2.6.26/K2.6.18-194.26.1.el5...
3. Настройка VPN клиентов
Описание настройки VPN клиентов напишу немножко позже, и думаю лучше всего будет перенести это описание в отдельную статью. На сегодняшний день из более-менее живых и стабильных клиентов я вижу всего два:
1. GreenBow VPN Client (ZyWALL VPN Client) – очень удобная штука, правда платная стоит приближенно 50$.
2. Shrew VPN – бесплатный, имеет огромное количество настроек, в которых иногда бывает трудно найти то что нужно.
Если кто-то использует альтернативные варианты подключения – с удовольствием рассмотрю их.
11 Коммент. : “OpenSwan как сервер удаленного доступа”
Извините, а какие преимущества дает данная схема по сравнению с банальным PPTP? На клиентские компы требуется устанавливать дополнительного клиента, да и настройка сложней.
В чем кайф?
@miha
В IPSec реализована более высокая надежность шифрования передаваемых данных по сравнению с MPPE в PPTP, в которых найдено множество различных дыр начиная от уязвимости MSCHAP и кончая подменой пакетов в MPPE. Кроме того по моим подсчетам около 20% провайдеров по москве зарубают прохождение PPTP через NAT.
С другой же стороны это право каждого выбирать соотношение между затратами на сложность настройки и вероятностью сторонней атаки (которая как обычно кажется крайне маленькой).
Да, что опасность атаки преуменьшают – точно. “кому нужны?” главная концепция обеспечения защищенности.
Почитал про дыры в PPTP, не совсем все плохо, если нет возможности завернуть к себе для анализа поднятую “трубу”, то не особенно то и сломаешь v2. Впрочем придется неспешно думать о замене на L2TP, но он в centose кривоватый, может быть пока что.
Ставить же внешние программы-клиенты для подключения на удаленку мне как то не нравится.
@miha
По PPTP не стоит исключать и более простые методы, такие как простейший перебор паролей. Сколько не смотрю – забыл что-нибудь заблокировать, и вот кто-то по 3 раза в день перебирает пароли от ssh или web-админки. Мне даже помнится было интересно кто же это, я специально делал редирект с внешнего IP на ssh виртуалки – как не странно в основном перебирают с адресов организаций, на которых висит либо почта либо веб-сервер, у некоторых перебиральщиков открыто все что можно imap, pop3, mysql и даже через сквида полазить можно
Неплохая альтернатива для замены PPTP – это L2TP over IPSec, единственное с настройкой придется заморочится. Но честно говоря я так и не смог добиться четкой и стабильной работы L2TP/IPSec на CentOS, при 10-15 одновременных подключениях приходилось пару раз в месяц перезапускать сервисы.
Перебор – есть такое дело, но банальный denyhosts вполне спасает. Забавно, что еще лет 5 назад такого массового перебора не было, в логах неделями было чисто. Сейчас же и от рута перебирают, и пользователей списком пробивают…
Меня только сейчас осенило, чего на одной из точек временами тупит или даже виснет аппаратный роутер d-link, у которого SSH открыт в инет.
не могли бы Вы рассмотреть настройку Nokia VPN Client для подключения к серверу, настроенному по данной схеме?
Хотя бы в общих чертах.
Приветствую
Жалко ни одного Nokia под рукой нет, попробовать не на чем. Теоретически с этими настройками к OpenSWAN можно подцепиться любым клиентом, и Nokia VPN Client тоже.
Может у тебя что-то конкретное не получается?
Приветствую.
А в чем преимущество OpenSwan над OpenVpn (ну кроме использования ipSec)? есть ли виндовые клиенты для подключения к серверу (аналог OpenVpn_GUI)?
Так же слышал что OpenVpn работает быстрее, а OpenSwan иногда может не работать т.к. провайдеры лочат ipSec пакеты.
Помогите разобраться
Хорошо и понятно написано, но после выполнения настройки и попытки подключиться с Windows XP – выдается ошибка “сертификат не найден”, как его сгенерировать непонятно.
Добрый день
А как можно настроить Ipsec в такой конфигурации
http://itmages.ru/image/view/970334/d41d8cd9
что бы пакеты бегали из сеть 1 в сеть 3 через сеть 2
Сейчас получилось что бегают из сеть 1 в сеть 2 и из сеть 2 в сеть 3.
Приветствую,
не конектится через Shrew VPN
attached to key daemon …
peer configured
iskamp proposal configured
esp proposal configured
client configured
local id configured
remote id configured
pre-shared key configured
bringing up tunnel …
negotiation timout occurred
tunnel disabled
detached from key daemon
куда копать?
спасибо за статью!