Как в Linux с помощью Openswan создать туннель IPsec VPN

Оригинал: How to create a site-to-site IPsec VPN tunnel using Openswan in Linux
Автор: Sarmed Rahman
Дата публикации: August 26, 2014
Перевод: Н.Ромоданов
Дата перевода: октябрь 2014 г.

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

Иногда туннелирование VPN можно также использовать просто в интересах безопасности. Провайдеры услуг или частные компании могут проектировать свои сети таким образом, чтобы жизненно важные серверы (например, база данных, VoIP, банковские серверы) размещались в подсетях, которые доступны для доверенных сотрудников только через туннель VPN. Когда требуется защищенный туннель VPN, часто предпочитают выбирать Ipsec, поскольку с помощью туннеля IPsec можно реализовать дополнительные уровни безопасности.

В данном руководстве будет показано, как в Linux с помощью пакета Openswan можно будет создать туннель VPN.

Топология

В настоящем руководстве будет рассказано о создании туннеля IPsec для следующих вариантов топологий сети.

Установка пакетов и подготовка серверов VPN

Как правило, управление будет происходить только со стороны A, но, согласно требованиям, вам нужно управлять сетью как на стороне A, так и на стороне B. Мы начинаем процесс с установки пакета Openswan.

На системах, основанных на Red Hat (CentOS, Fedora или RHEL):

# yum install openswan lsof 

На системах, основанных на Debian (Debian, Ubuntu или Linux Mint):

# apt-get install openswan 

Теперь с помощью следующих команд мы отключаем на сервере VPN redirects, если таковой имеется:

# for vpn in /proc/sys/net/ipv4/conf/*;
# do echo 0 > $vpn/accept_redirects;
# echo 0 > $vpn/send_redirects;
# done

Затем мы изменяем параметры ядра так, чтобы постоянно был включен IP forwarding, а IP redirects был постоянно отключен.

# vim /etc/sysctl.conf 
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

Перезагрузите файл /etc/sysctl.conf:

# sysctl -p 

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

# iptables -A INPUT -p udp --dport 500 -j ACCEPT
# iptables -A INPUT -p tcp --dport 4500 -j ACCEPT
# iptables -A INPUT -p udp --dport 4500 -j ACCEPT 

Наконец, мы создаем правила брандмауэра для NAT.

# iptables -t nat -A POSTROUTING -s site-A-private-subnet -d site-B-private-subnet -j SNAT --to site-A-Public-IP 

Пожалуйста, убедитесь, что правила брандмауэра будут сохранены и будут действовать постоянно.

Замечание:

Подготовка конфигурационных файлов

Первым конфигурационным файлом, с которым мы будем работать, является файл ipsec.conf. Независимо от того, как вы сконфигурируете сервер, всегда рассматривайте вашу подсеть как расположенную «слева» (left), а подсеть, к которой доступ осуществляется дистанционно, сайт, как расположенный «справа» (right). Следующая конфигурация выполняется на сервере VPN на стороне A.

# vim /etc/ipsec.conf 
## general configuration parameters ##
 
config setup
        plutodebug=all
        plutostderrlog=/var/log/pluto.log
        protostack=netkey
        nat_traversal=yes
        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/16
        ## disable opportunistic encryption in Red Hat ##
        oe=off
 
## disable opportunistic encryption in Debian ##
## Note: this is a separate declaration statement ##
include /etc/ipsec.d/examples/no_oe.conf 
 
## connection definition in Red Hat ##
conn demo-connection-redhat
        authby=secret
        auto=start
        ike=3des-md5
        ## phase 1 ##
        keyexchange=ike
        ## phase 2 ##
        phase2=esp
        phase2alg=3des-md5
        compress=no
        pfs=yes
        type=tunnel
        left=<siteA-public-IP>
        leftsourceip=<siteA-public-IP>
        leftsubnet=<siteA-private-subnet>/netmask
        ## for direct routing ##
        leftsubnet=<siteA-public-IP>/32
        leftnexthop=%defaultroute
        right=<siteB-public-IP>
        rightsubnet=<siteB-private-subnet>/netmask
 
## connection definition in Debian ##
conn demo-connection-debian
        authby=secret
        auto=start
        ## phase 1 ##
        keyexchange=ike
        ## phase 2 ##
        esp=3des-md5
        pfs=yes
        type=tunnel
        left=<siteA-public-IP>
        leftsourceip=<siteA-public-IP>
        leftsubnet=<siteA-private-subnet>/netmask
        ## for direct routing ##
        leftsubnet=<siteA-public-IP>/32
        leftnexthop=%defaultroute
        right=<siteB-public-IP>
        rightsubnet=<siteB-private-subnet>/netmask

Аутентификацию можно делать по-разному. В настоящем руководстве будут использоваться ключ, который добавляется в файл /etc/ipsec.secrets.

# vim /etc/ipsec.secrets 
siteA-public-IP  siteB-public-IP:  PSK  "pre-shared-key"
## in case of multiple sites ##
siteA-public-IP  siteC-public-IP:  PSK  "corresponding-pre-shared-key"

Запуск сервиса и поиск возникающих проблем

Теперь сервер должен быть готов для создания туннеля VPN между полдсетями. Если вы также осуществляете управление на стороне B, то, пожалуйста, убедитесь, что вы настроили необходимые параметры на сервере стороны B. Для систем, основанных Red Hat, пожалуйста, убедитесь, что вы с помощью команды chkconfig добавили запуск сервиса в startup.

# /etc/init.d/ipsec restart 

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

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

# ip route 
[siteB-private-subnet] via [siteA-gateway] dev eth0 src [siteA-public-IP]
default via [siteA-gateway] dev eth0

Кроме того, мы можем проверить состояние туннеля с помощью следующих команд.

# service ipsec status 
IPsec running  - pluto pid: 20754
pluto pid 20754
1 tunnels up
some eroutes exist
# ipsec auto --status 
## output truncated ##
000 "demo-connection-debian":     myip=<siteA-public-IP>; hisip=unset;
000 "demo-connection-debian":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0; nat_keepalive: yes
000 "demo-connection-debian":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,28; interface: eth0;

## output truncated ##
000 #184: "demo-connection-debian":500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 1653s; newest IPSEC; eroute owner; isakmp#183; idle; import:not set

## output truncated ##
000 #183: "demo-connection-debian":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 1093s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:not set

В журнальном файле /var/log/pluto.log также должна быть информация об аутентификации, обмене ключами и информация о различных этапах туннелирования. К этому файлу также нужно обратиться в случае, если туннель не поднимается.

Если вы уверены, что все настройки правильные, а ваш туннель все еще не поднимается, то вы должны проверить следующее.

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

Надеюсь, что это руководство вам будет полезно.

---

---