IPSec в Linux с использованием Strongswan

Где-то тут уже настраивался IPSec на оборудовании Cisco, но не только оно используется для построения VPN-ов. Хочется разобраться еще и с настройкой его на Linux. Как всегда, у нас для Linux не один вариант, можно использовать Openswan, Strongswan, еще какой-то swan и может еще чего написали, о чем я не в курсе. Использовать я буду Strongswan. Потому что несмотря на то, что Openswan хорош, стабилен и даже работает, у меня с его помощью удалось завести только host-to-host. Когда я начал  настраивать site-to-site, то туннель у меня поднялся, а маршрута в удаленную сеть система упорно не хотела видеть. Потратил часа три на разбирательства, после чего плюнул и настроил это все на Strongswan за 20 минут. К тому же, вывод статуса соединений у него намного адекватнее.

Что такое Strongswan, это набор программ и библиотек (вроде бы), которые реализуют поддержку набора протоколов IPSec в Linux. Два слова про установку и начнем знакомство и поднятие первых туннелей в Linux. Использовать будем RedHat-совместимый дистрибутив Scientific Linux. Он как CentOS, но его разрабатывают парни из CERN и его логотип мне больше нравится.

План такой:

1. Установка и первоначальная настройка системы
2. Настройка простого туннеля Linux-Linux
3. Настройка туннеля Site-to-site между двумя Linux-маршрутизаторами

Чтобы установить openswan производим нехитрое действие

[root@Paris ~]# yum install strongswan

Далее, чтобы все работало необходимо разрешить маршрутизацию пакетов через наш VPN-концентратор. Проверить можно так:

[root@Paris ~]# cat /proc/sys/net/ipv4/ip_forward

0

[root@Paris ~]#

Если в файле /proc/sys/net/ipv4/ip_forward 0, то маршрутизация запрещена, это действие по-умолчанию. Чтобы разрешить маршрутизацию, записываем туда 1.

[root@Paris ~]# echo 1 > /proc/sys/net/ipv4/ip_forward

[root@Paris ~]#

Чтобы после перезагрузки значение сохранилось (ведь /proc это виртуальная файловая система), внесем изменения в файл /etc/sysctl.conf, в частности значение параметра net.ipv4.ip_forward

# Controls IP packet forwarding

net.ipv4.ip_forward = 1

Разумеется, в iptables все это тоже должно быть разрешено. Предлагаю сначала настроить IPSec, а потом уже правила iptables.

Начнем настройку обычного IPSec туннеля между двумя хостами. Каждый из них имеет публичный IP-адрес на одном из своих интерфейсов. Схема изображена на рисунке, для удобства хосты называются Paris и London.

Основные конфигурационные файлы для strongswan это:

/etc/ipsec.conf – все настройки

/etc/ipsec.secrets – ключи и пароли для шифрования

Файл /etc/ipsec.conf разбит на разделы

config setup – глобальные параметры и опции

conn %default – параметры ipsec-соединений по-умолчанию. Если в отдельных параметрах соединений не указан параметр, то используются параметры отсюда

conn SomeTunnel – раздел с параметрами соединения SomeTunnel

настроим наше соединение, добавим в /etc/ipsec.conf обоих хостов такие строки

conn Paris-London

 left=78.12.34.56

 right=193.98.76.54

 type=tunnel

 authby=secret

 auto=start

разберемся, что это означает.
conn Paris-London – служебное слово conn означает название соединения. После него будут параметры, которые характеризуют соединение.

left=78.12.34.56 и right=193.98.76.54 – адреса хостов. Слова символизируют то, что хосты находятся с разных сторон. Не имеет значения, в какой из них вы впишете свой адрес, система автоматически определит, какой из адресов относится к ее интерфейсу. Поэтому на разных хостах вполне можно использовать одинаковый конфиг. Вместо адреса можно использовать ключевое слово %any в виде right=%any. Тогда можно будет подключаться с любого адреса.

type=tunnel – тип соединения. Может принимать значения tunnel, transport или passthrough.

authby=secret – что будет использоваться в качестве ключа: PSK (парольное слово) или RSA (ключ)

auto=start – опция определяет, когда включать соединение. Может принимать значения: start (автоматически стартовать), add (стартовать в ответ на инициацию от другого хоста), ignore (игнорировать соединение), manual (стартовать вручную), route (назначение мне осталось непонятно, используется крайне редко).

Ну и так как мы задали тип авторизации с помощью PSK, то давайте запишем секретное слово в файл ipsec.secrets. Приведем его к виду

[root@Paris ~]# cat /etc/ipsec.secrets

78.12.34.56 193.98.76.54 : PSK "SecrtKey1234"

Синтаксис тут следующий:

«мой адрес» «адрес с той стороны» : PSK “ключ”

Вместо адреса можно использовать доменное имя или ключевое слово %any.

my.host.com %any : PSK “sekretKey”

это означает, что к моему хосту с доменным именем my.host.com можно подключаться откуда угодно с использованием PSK sekretKey.

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

[root@London ~]# openssl rand -base64 48

dY2c+vnA1Lk3JcHrM4gCziNzMZL/tj8iwGYVb7MivDXUh6Qb1YTNo6rxOykreacY

После редактирования этих двух файлов на каждом из хостов перезапускаем strongswan

root@London:~# ipsec restart

Stopping strongSwan IPsec...

Starting strongSwan 4.5.2 IPsec [starter]...

root@London:~#

Чтобы не перезапускать всю эту махину можно просто перезапускать туннель

root@London:~# ipsec reload Paris-London

Reloading strongSwan IPsec configuration...

root@London:~#

Или обновить конфиг 

root@London:~# ipsec update

А если изменились ключи или внешний адрес той стороны, то обновить можно так

root@London:~# ipsec rereadsecrets

При установке параметров соединения мы указали минимум параметров, поэтому остальные остались заданными по-умолчанию. Так как и там и там используется одинаковое ПО, то и умолчания у них одинаковые и они достаточно быстро нашли общий язык.

Раз у нас трафик между двумя хостами бегает, то пора бы настроить и Site-to-site туннель. Настроим связь по шифрованному туннелю между сетями, показанными на рисунке. Кроме этого добавим других опций, не всегда же настраивать туннели между идентичными системами. Попробуем разобраться, приводим наш ipsec.conf к следующему виду

conn Paris-London

 left=78.12.34.56

 leftsubnet=10.100.0.0/16

 right=193.98.76.54

 rightsubnet=10.200.0.0/16

 ike=aes128-sha1-modp1024,3des-md5-modp1024

 esp=aes256-sha1,aes128-md5

 type=tunnel

 authby=secret

 auto=start

Добавилось

leftsubnet и rightsubnet – подсети, трафик из которых будет шифроваться (согласно топологии на рисунке).

ike – параметры первой фазы соединения (шифрование, хэш, алгоритм Диффи-Хелмана). Указано две пары параметров, если одна пара не подойдет, то будет использована другая пара.

esp – параметры второй фазы соединения (шифрование, хэш). Тут тоже можно вносить несколько пар параметров, которые будут перебираться до совпадения.

Перезапускаем strongswan и проверяем статус соединения командой ipsec status

root@London:~# ipsec status

Security Associations:

Paris-London[1]: ESTABLISHED 3 minutes ago, 193.98.76.54[193.98.76.54]...78.12.34.56[78.12.34.56]

Paris-London{1}:  INSTALLED, TUNNEL, ESP SPIs: c8e90b5d_i c69caee0_o

Paris-London{1}:   10.200.0.0/16 === 10.100.0.0/16

root@London:~#

Если нужна более детальная информация про соединение, то можно использовать ipsec statusall

root@London:~# ipsec statusall

000 Status of IKEv1 pluto daemon (strongSwan 4.5.2):

000 interface lo/lo ::1:500

000 interface lo/lo 127.0.0.1:500

000 interface eth1/eth1 193.98.76.54:500

000 interface eth2/eth2 10.200.0.1:500

000 %myid = '%any'

000 loaded plugins: test-vectors curl ldap aes des sha1 sha2 md5 random x509 pkcs1 pgp dnskey pem openssl gmp hmac xauth attr kernel-netlink resolve

000 debug options: none

000

Status of IKEv2 charon daemon (strongSwan 4.5.2):

  uptime: 11 minutes, since Sep 28 22:06:02 2013

  malloc: sbrk 233472, mmap 0, used 146872, free 86600

  worker threads: 7 idle of 16, job queue load: 0, scheduled events: 7

  loaded plugins: test-vectors curl ldap aes des sha1 sha2 md5 random x509 revocation constraints pubkey pkcs1 pgp pem openssl fips-prf gmp agent pkcs11 xcbc hmac ctr ccm gcm attr kernel-netlink resolve socket-raw farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc dhcp led addrblock

Listening IP addresses:

  193.98.76.54

  10.200.0.1

Connections:

Paris-London:  193.98.76.54...78.12.34.56

Paris-London:   local:  [193.98.76.54] uses pre-shared key authentication

Paris-London:   remote: [78.12.34.56] uses any authentication

Paris-London:   child:  10.200.0.0/16 === 10.100.0.0/16

Security Associations:

Paris-London[3]: ESTABLISHED 3 minutes ago, 193.98.76.54[193.98.76.54]...78.12.34.56[78.12.34.56]

Paris-London[3]: IKE SPIs: 94645ad237ed6496_i e44690af76a91691_r*, pre-shared key reauthentication in 2 hours

Paris-London[3]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024

Paris-London{3}:  INSTALLED, TUNNEL, ESP SPIs: cd4e97ba_i c68f865e_o

Paris-London{3}:  AES_CBC_256/HMAC_SHA1_96, 12660 bytes_i (1s ago), 12660 bytes_o (1s ago), rekeying in 40 minutes

Paris-London{3}:   10.200.0.0/16 === 10.100.0.0/16

root@London:~#

К слову, логи strongswan пишет в файл /var/log/secure (в RedHat) и в /var/log/auth.log (в Debain)

Управление соединением можно осуществлять командами:

ipsec up Paris-London (поднять соединение)

ipsec down Paris-London (отключить соединение)

Для полноты картины проверим, трафик, который бегает между нашими Linux- маршрутизаторами. Используем утилиту tcpdump, которая будет показывать все пакеты относящиеся к противоположенному хосту и запустим пинг между двумя локальными сетями.

На хосте London видим:

root@London:~# tcpdump -i eth1 host 78.12.34.56

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes

22:23:38.696918 IP 78.12.34.56 > 193.98.76.54: ESP(spi=0xcd4e97ba,seq=0x1f5), length 100

22:23:38.711322 IP 193.98.76.54 > 78.12.34.56: ESP(spi=0xc68f865e,seq=0x1f5), length 100

22:23:39.699217 IP 78.12.34.56 > 193.98.76.54: ESP(spi=0xcd4e97ba,seq=0x1f6), length 100

22:23:39.710468 IP 193.98.76.54 > 78.12.34.56: ESP(spi=0xc68f865e,seq=0x1f6), length 100

22:23:40.698510 IP 78.12.34.56 > 193.98.76.54: ESP(spi=0xcd4e97ba,seq=0x1f7), length 100

22:23:40.703955 IP 193.98.76.54 > 78.12.34.56: ESP(spi=0xc68f865e,seq=0x1f7), length 100

22:23:41.702856 IP 78.12.34.56 > 193.98.76.54: ESP(spi=0xcd4e97ba,seq=0x1f8), length 100

22:23:41.708428 IP 193.98.76.54 > 78.12.34.56: ESP(spi=0xc68f865e,seq=0x1f8), length 100

^C

8 packets captured

8 packets received by filter

0 packets dropped by kernel

root@London:~#

В листинге хорошо видно, что пришли какие-то зашифрованные 4 пакета, и последовали 4 ответа. Обратите внимание на прокол, это шифрованный ESP вместо обычного ICMP.