В этой статье я расскажу об одном из вариантов  настройки сервера удаленного доступа 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 как сервер удаленного доступа”

  1. Извините, а какие преимущества дает данная схема по сравнению с банальным PPTP? На клиентские компы требуется устанавливать дополнительного клиента, да и настройка сложней.
    В чем кайф?

  2. Alsigned пишет:

    @miha
    В IPSec реализована более высокая надежность шифрования передаваемых данных по сравнению с MPPE в PPTP, в которых найдено множество различных дыр начиная от уязвимости MSCHAP и кончая подменой пакетов в MPPE. Кроме того по моим подсчетам около 20% провайдеров по москве зарубают прохождение PPTP через NAT.

    С другой же стороны это право каждого выбирать соотношение между затратами на сложность настройки и вероятностью сторонней атаки (которая как обычно кажется крайне маленькой).

  3. Да, что опасность атаки преуменьшают – точно. “кому нужны?” главная концепция обеспечения защищенности.

    Почитал про дыры в PPTP, не совсем все плохо, если нет возможности завернуть к себе для анализа поднятую “трубу”, то не особенно то и сломаешь v2. Впрочем придется неспешно думать о замене на L2TP, но он в centose кривоватый, может быть пока что.

    Ставить же внешние программы-клиенты для подключения на удаленку мне как то не нравится.

  4. Alsigned пишет:

    @miha
    По PPTP не стоит исключать и более простые методы, такие как простейший перебор паролей. Сколько не смотрю – забыл что-нибудь заблокировать, и вот кто-то по 3 раза в день перебирает пароли от ssh или web-админки. Мне даже помнится было интересно кто же это, я специально делал редирект с внешнего IP на ssh виртуалки – как не странно в основном перебирают с адресов организаций, на которых висит либо почта либо веб-сервер, у некоторых перебиральщиков открыто все что можно imap, pop3, mysql и даже через сквида полазить можно :)

    Неплохая альтернатива для замены PPTP – это L2TP over IPSec, единственное с настройкой придется заморочится. Но честно говоря я так и не смог добиться четкой и стабильной работы L2TP/IPSec на CentOS, при 10-15 одновременных подключениях приходилось пару раз в месяц перезапускать сервисы.

  5. Перебор – есть такое дело, но банальный denyhosts вполне спасает. Забавно, что еще лет 5 назад такого массового перебора не было, в логах неделями было чисто. Сейчас же и от рута перебирают, и пользователей списком пробивают…

    Меня только сейчас осенило, чего на одной из точек временами тупит или даже виснет аппаратный роутер d-link, у которого SSH открыт в инет.

  6. Zloi_kak_sobak пишет:

    не могли бы Вы рассмотреть настройку Nokia VPN Client для подключения к серверу, настроенному по данной схеме?
    Хотя бы в общих чертах.

  7. Alsigned пишет:

    Приветствую ;)

    Жалко ни одного Nokia под рукой нет, попробовать не на чем. Теоретически с этими настройками к OpenSWAN можно подцепиться любым клиентом, и Nokia VPN Client тоже.

    Может у тебя что-то конкретное не получается?

  8. Vladimir пишет:

    Приветствую.
    А в чем преимущество OpenSwan над OpenVpn (ну кроме использования ipSec)? есть ли виндовые клиенты для подключения к серверу (аналог OpenVpn_GUI)?
    Так же слышал что OpenVpn работает быстрее, а OpenSwan иногда может не работать т.к. провайдеры лочат ipSec пакеты.
    Помогите разобраться :)

  9. sae пишет:

    Хорошо и понятно написано, но после выполнения настройки и попытки подключиться с Windows XP – выдается ошибка “сертификат не найден”, как его сгенерировать непонятно.

  10. ea2982 пишет:

    Добрый день

    А как можно настроить Ipsec в такой конфигурации
    http://itmages.ru/image/view/970334/d41d8cd9
    что бы пакеты бегали из сеть 1 в сеть 3 через сеть 2
    Сейчас получилось что бегают из сеть 1 в сеть 2 и из сеть 2 в сеть 3.

  11. Приветствую,
    не конектится через 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

    куда копать?
    спасибо за статью!

Оставить комментарий