Развивая IT-инфраструктуру рано или поздно приходит задача интегрироваться с какими-либо сервисами крупной организации. Это может быть, например, банк или оператор связи. Как правило в крупных организациях действуют устоявшиеся политики информационной безопасности, которые в частности требуют реализации сервиса с внешней по отношению к ним инфраструктурой через шифрованные каналы — IPSec. В то же время в небольших организациях
Общая схема сервиса представлена ниже. Как правило, в крупных организациях все уже стандартизировано, поставлено на поток, всякие возможные шифрования и прочие сетевые штуки делаются на отдельном оборудовании (циски-джуниперы и иже с ними), и, что важнее, отдельными людьми (возможно каждый синий квадратик на схеме ниже обслуживают разные люди). У вас же одна виртуалка, с которой будет и запускаться сервис, и организовываться IPSec.
Обратите внимание, сам IPSec организовывается между одними IP-адресами (в моем примере
10.0.255.1 <-> 10.0.1.1), а сам сервис — между другими (192.168.255.1<-> 192.168.1.1). Такие схемы еще называются IPSec Network-Network.Простой пример — вы работаете в молодой, но очень амбициозной компании СуперСервис, и вам надо организовать взаимодействие с закрытым API компании МегаТелеком. Ваша инфраструктура — один сервер VDS, инфраструктура партнера — куча сетевого и серверного оборудования. Задача делится на два этапа:
- Организовать транспорт (как будет происходить межсетевое взаимодействие).
- Настроить сервис (запустить приложения непосредственно на серверах).
Итак, менеджер СуперСервис решил организовать подключение к какой-то крупной организации для решения бизнес-задачи. Он обратился к МегаТелеком, на что ему выслали технические условия по подключению. Одно из этих условий — организация IPSec. Это условие пришло в виде таблички excel, пример которой я представил ниже. На картинке я желтым выделил технически значимые параметры. Формат может отличаться, но суть остается той же.
Изначально он приходит не заполненный с вашей стороны, его надо заполнить и отправить на согласование партнеру. После согласования можно садиться и пробовать настраивать вашу Linux-машинку.
Концепция IPSec
Далее я приведу немного теории для людей, совсем не знакомых с технологией. Все, что я дальше опишу, относится к чистому Ethernet и IPv4. Я не буду вдаваться в алгоритмы шифрования, обмена ключами, вместо этого сосредоточусь на сетевой части.
IPSec — набор техник и протоколов по организации защищенного соединения.
В отличии от прочих технологий туннелирования (GRE, PPP, L2TP, даже MPLS-TE) для IPSec не создается явных туннельных интерфейсов, через которые можно маршрутизировать трафик. Вместо этого в IPSec предусмотрена концепция так называемых Security Assotiations (SA). SA и есть туннель от одного сетевого устройства к другому. Но не стоит забывать, что SA — не сетевой интерфейс в нормальном понимании этого слова, классическая маршрутизация здесь не работает. Вместо таблицы маршрутизации здесь работает концепция Security Policy (SP). Мы явно прописываем что-то типа аксес-листа (ACL) для пропуска трафика через определенную SA. Все эти вещи определены в так называемом фреймворке ISAKMP.
ISAKMP — описание процедур IPSec, в литературе называют его фреймворком. В нем описываются термины SA, SP, SAD (Security Assotiations Database), SPD (Security Policy Database), необходимость установки вспомогательных туннелей… ISAKMP построен так, чтобы не зависеть от технологий туннелирования, алгоритмов аутентификации и шифрования. Он просто вводит необходимые определения.Перед шифрованием трафика стороны должны договориться о параметрах (и ключах) этого шифрования. Для этого между обоими сторонами поднимается вспомогательный туннель (его еще называют ISAKMP туннель), который действует все время. Туннель этот двунаправленный, представляет из себя соединение по UDP (по умолчанию на порту 500). Для организации этого вспомогательного туннеля стороны должны проверить подлинность друг друга (должен совпасть пароль). Этим занимается протокол IKEv1/2 (Internet Key Exchange). И уже по организованному ISAKMP туннелю стороны договариваются о шифровании непосредственно пользовательского трафика.
IKE(v1/2) — непосредственно протокол аутентифиации. Он уже реализовывает алгоритмы обмена ключами и их применение.
Благодаря концепции Cisco сейчас ISAKMP и IKE считаются синонимами.
Собственно организация IPSecа делится на две фазы:
- Создание вспомогательного туннеля ISAKMP
- Создание туннеля пользовательских данных
Как я писал, в концепции IPSec (а уже правильнее говорить, в концепции ISAKMP) туннели называются SA.
Первая фаза (организация ISAKMP SA) может осуществляться в двух режимах:
- main — стороны поочередно обмениваются параметрами согласования. Считается более безопасным, используется для постоянных каналов (наш случай).
- aggressive — инициатор в одном сообщении отправляет все необходимые параметры согласования, используется при подключении удаленного пользователя для временной сессии (чтобы быстрее).
Надо понимать, что основные SA-туннели однонаправленные. Для двусторонней передачи данных по IPSec каналу должно быть два туннеля: источник (src) > получатель (dst) и наоборот.
Во всех способах шифрования в оригинальный IP-пакет добавляются дополнительные заголовки, происходит инкапсуляция. Существует два способа этой инкапсуляции — AH (Authentication Header) и ESP (Encapsulation Security Payload). AH только аутентифицирует пакет (подписывает цифровой подписью отправителя), ESP и аутентифицирует (подписывает), и шифрует. На сегодняшний день AH уже практически не используется, все упаковывают в ESP.
Шифровать и аутентифицировать исходный IP-пакет можно без учета IP-заголовка (транспортный режим) или вместе с ним (туннельный режим). Транспортный используется тогда, когда планируется организовать свои туннели по другим технологиям (не IPSec/ESP). Например, GRE, l2tp, ppp. Для целей подключения какого-то сервиса ко внутренней инфраструктуре большой организации практически не используется. Я использовал такой сценарий для объединения нескольких офисов в один VPN через IPSec-и. Нам же более интересен туннельный режим. Как видно из картинки, здесь добавляется один дополнительный IP-заголовок.
Кстати, есть реальный пример использования AH-инкапсуляции. Предположим, у нас есть две сети, подключенные к разным маршрутизаторам. Хосты должны передавать информацию с MTU 1500 байт без фрагментации, но у нас есть промежуточный участок, который поддерживает только 1380 байт. Вся трасса доверенная. Мы можем воспользоваться тем, что IPSec не создает туннельных интерфейсов, в классическом смысле через которые трафик не маршрутизируется. Мы создадим SA туннель AH типа (нам же не надо шифровать), тогда трафик пойдет него. В трафике фрагментироваться будут только внешние IP-пакеты (по внешним IP-заголовкам), внутренние будут пересобираться без изменений.
Обратите внимание, что заголовок ESP встает до транспортных TCP/UDP. Помните, в заголовке IP-пакета есть поле Protocol? На основе этого поля сетевое оборудование (да и конечные хосты) корректно обрабатывают IP-пакеты. Так вот для ESP свой номер — 50. Полный список протоколов для этого поля можно посмотреть на вики, бывает весьма полезно.
Отсутствие заголовка транспортного уровня (TCP/UDP/ICMP уже зашифрованы!) накладывает ограничение на технологии типа NAT. Вспомните, NAT с трансляцией портов (overload, PAT, MASQARADE, у него много имен) работает на основе портов транспортных протоколов. А в зашифрованном туннеле IPSec их нет! Для преодоления этой проблемы есть такая технология, как IPSec NAT-Traversal (NAT-T). В ходе первой фазы стороны согласовывают возможность использовать NAT-T. Если обе стороны поддерживают NAT-T (да еще и на одинаковых UDP-портах), тогда в итоговых туннелях для трафика добавляется заголовок UDP, с которым пакеты уже пройдут через маршрутизаторы с трансляцией сетевых адресов.Сам по себе туннель не поднимется, нужно направить туда трафик. Как я писал выше, здесь не работают правила маршрутизации, надо писать политики Security Policy (SP).
Политики состоят из адреса источника, адреса назначения, направления (in, out, fwd) и параметров пользовательских туннелей (здесь как раз описываются ESP это будет или AH, туннельный вариант или транспортный). Это больше похоже на организацию правил для NATа. NATу тоже недостаточно записей таблицы маршрутизации. И там тоже указываются правила откуда, куда и как, а не куда и через что. И также неверным движением руки можно завалить всю связь на удаленном сервере.
Все манипуляции с IPSec добавляют заголовки служебной информации. Минимум они съедят еще 40 байт от исходного пакета. Таким образом, например, при стандартном MTU для PPPoE в 1380 байт соединений реальное MTU будет < 1340.
IPSec в Linux
Займемся практикой на примере DEB-дистрибутивов. Я буду рассматривать только случай с авторизацией на основе pre-shared-key (PSK), будем настраивать схему из начала статьи.
Сам по себе IPSec поддерживается ядром, но поддержка эта весьма ограничена. В действительности ядреные модули занимаются только тем, что связано с шифрованием и уже полученными (переданными в ядро) ключами — обработка пакетов. А чтобы передать туда параметры и правила, с которыми нужно обрабатывать трафик, требуется отдельное программное обеспечение. В качестве такого софта есть несколько решений:
- KAME, перекочевавший из BSD
- xSWAN (strongswan, freeswan, libreswan, etc)
- shorewall
Мне показался самым простым (самым предсказуемым) вариант KAME, его и будем крутить дальше.
#Для deb-дистрибутивов команда сама подтянет необходимые ядреные модули
root@localhost: ~# apt-get install racoon ipsec-tools
Традиционно KAME состоял из двух компонент
- Демона racoon для управления туннелем ISAKMP.
- Утилиты setkey для управления SA-туннелей с данными.
Начнем с первого. Racoon отвечает за параметры авторизации туннелей в рамках IKE. Это демон, он настраивается одним конфигурационным файлом (
/etc/racoon.conf), запускается обычным init-скриптом (/etc/init.d/racoon <start|stop|restart>).root@localhost: ~# cat /etc/racoon.conf
# Практически все данные в разделах remote и sainfo берутся из первоначального шаблона
#
# Мы рассмотрим простейший пример с PSK авторизацией
path pre_shared_key "/etc/racoon/psk.txt";
log debug;
listen {
# Указываем интерфейс, с которого будет строиться будущий ISAKMP туннель
isakmp 10.0.1.1 [500];
strict_address;
}
# В разделе remote перчислены настройки для первой фазы IPSec.
# Это в некотором смысле аналог tunnel-group в ASA.
# Вместо конкретного IP-адреса можно указать anonymous
# Это будет означать возможность подключения к вам с любого адреса.
# Так делаются присоединения типа user-network
# remote anonymous
remote 10.0.255.1 {
nat_traversal off;
exchange_mode main;
my_identifier address 10.0.1.1;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
lifetime time 86400 sec;
}
}
# Вторая фаза IPSec. Аналог transform-set в ASA.
#
# Предполагается, что для разных адресов взаимодействия
# можно применять разные параметры шифрования второй фазы.
# Конкретизация сервисов как раз указывается в первой строчке
# sainfo address <src> address <dst>
# Скорее всего вам это не понадобится, вы будете писать первую строку так
# sainfo anonymous
sainfo address 192.168.1.1 any address 192.168.255.1 any {
pfs_group modp1024;
lifetime time 28800 sec;
encryption_algorithm 3des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
root@localhost: ~# cat /etc/racoon/psk.txt
# Файлик с PSK-ключами
# Формат <REMOTE IP ADDR> <PASSWORD>
# Важно - владелец файла должен быть такой же, от чьего имени запускается racoon
10.0.255.1 SUPERPASSWORD
Как всегда, подробности в
man 5 racoon.confДальше займемся утилитой setkey. Она тоже запускается как демон (
/etc/init.d/setkey <start|stop|restart>), но по факту она выполняет скрипт /etc/ipsec-tools.conf. Как я и говорил, она уже задает создает туннели для пользовательского трафика. А именно задает SA и SP для них. Это что-то вроде crypto-map на ASA. Самый простой вариант для нас — добавить просто SP. Тогда SA построится автоматически исходя из параметров второй фазы, указанной в настройках racoon.Но есть возможность вообще не использовать параметры второй фазы из racoon, а задать SA через эту утилиту. Подробности и синтаксис можно посмотреть в
man 8 setkey. А я же приведу приведу пример простейшей конфигурации.root@localhost: ~# cat /etc/ipsec-tools.conf
flush;
spdflush;
spdadd 192.168.1.1/32 192.168.255.1/32 any -P out ipsec
esp/tunnel/10.0.1.1-10.0.255.1/require;
spdadd 192.168.255.1/32 192.168.1.1/32 any -P in ipsec
esp/tunnel/10.0.255.1-10.0.1.1/require;
На текущий момент утилиту setkey дублирует модуль iproute2.
В рамках него есть две команды управления записями SA и SP.
- ip xfrm state
- ip xfrm policy
Помимо управления этой же утилитой можно смотреть состояние организованных SA и применяемых к трафику SP. Подробнее в
man 8 ip-xfrm.Взгляните еще раз на изначальную табличку. Там указаны разные IP-адреса для IPSec и сервиса. По внутреннему IP-адресу идет фильтрация внутри инфраструктуры Мегателеком. Но у нас всего лишь одна виртуальная машина. На ней должен как-то появиться внутренний IP-адрес, и пакеты в туннель должны уходить именно с него. Есть несколько вариантов добиться этого сценария:
- Статический маршрут без определения некстхопа, но с явным указанием исходящего интерфейса и IP-адреса.
- Задание маршрутов на основе policy based routing (PBR в Linux ака ip rule).
- Трансляция адресов (NAT/MASQARADE).
С моей точки зрения здесь подходит первый вариант.
Мы можем добавить на наш интерфейс дополнительный (secondary) IP-адрес, при этом лучше сделать alias для этого интерфейса
root@localhost: ~# ip addr add 192.168.1.1/32 dev eth1 label eth1:1
и настроить маршрут до сервера Мегателеком с этого IP-адреса.
root@localhost: ~# ip route add 192.168.255.1/32 dev eth1:1 src 192.168.1.1
Но если так сделать, ничего не заведется. Дело в том, что при добавлении маршрута в таком виде Linux-станция будет пытаться определить MAC-адрес получателя, делать она это будет через ARP… Компьютер будет слать запросы ARPWho has IP 192.168.255.1. Так как 192.168.255.1 нет в той же сети, где и 192.168.1.1 (маска /32!), ответа на ARP не будет. Зато при попытке соединения будет возвращаться с локального IP-адреса будет возвращатьсяNo route to host. Чтобы это победить, нам надо задать статическую ARP-запись:
root@localhost: ~# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth1:1
Такой вот лайфхак. Кстати, такие манипуляции могут привести не совсем к коректной работе IP-стека Linux. В одном из случаев командыip routeне приводили к нужному результату, пришлось перезагружать сетевой стек.
Проверка работоспособности
Не забывайте, туннель поднимется только тогда, когда в него пойдет трафик! Надо запустить пинг с конкретного интерфейса (IP-адреса) до назначения.
root@localhost: ~# ping -I 192.168.1.1 192.168.255.1С небольшой задержкой должны быть ответы с обратной стороны (если конечно ICMP нигде не закрыт на участке).
Мы можем увидеть, поднялся ли ISAKMP-туннель
racoonctl show-sa isakmp
root@localhost: ~# racoonctl show-sa isakmp
Destination Cookies Created
10.0.1.1.500 356a7e11111a93f:367111530375c065 2018-10-02 09:18:28
Также мы можем посмотреть туннели с пользовательскими данными
racoonctl show-sa esp
10.0.1.1 10.0.255.1
esp mode=tunnel spi=2148175815(0x800a8fc7) reqid=0(0x00000000)
E: 3des-cbc 799e587f 6a2b4b78 5590cc2a 3d3ee331 f7e7f472 01abcdef
A: hmac-sha1 01c5161f 46679a36 5d07ee9d f159fc9a 01abcdef
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Oct 2 09:22:44 2018 current: Oct 2 10:39:21 2018
diff: 4597(s) hard: 28800(s) soft: 23040(s)
last: Oct 2 09:22:45 2018 hard: 0(s) soft: 0(s)
current: 84(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 1 hard: 0 soft: 0
sadb_seq=1 pid=3764 refcnt=0
10.0.255.1 10.0.1.1
esp mode=tunnel spi=45614328(0x02b804f8) reqid=0(0x00000000)
E: 3des-cbc 97cedcf1 644e8bbb c22b4e2c fa08a874 01abcdef 211ad19e
A: hmac-sha1 1ab3e79d 3fd924a0 01abcdef 6c9ac89a 01abcdef
seq=0x00000000 replay=4 flags=0x00000000 state=mature
created: Oct 2 09:22:44 2018 current: Oct 2 10:39:21 2018
diff: 4597(s) hard: 28800(s) soft: 23040(s)
last: Oct 2 09:22:45 2018 hard: 0(s) soft: 0(s)
current: 84(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 1 hard: 0 soft: 0
sadb_seq=0 pid=3764 refcnt=0
Бывает полезно в tcpdump посмотреть логику установления соединения. Здесь можно также увидеть фазы установления соединения и уже передаваемый шифрованный в ESP трафик. Конечно есть техники его расшифровки, но обычно такого вывода уже достаточно.
root@localhost: ~# tcpdump -i eth1 host 10.0.255.1
18:01:06.409631 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 1 I ident
18:01:06.439276 IP 10.0.255.1.500 > 10.0.1.1.500: isakmp: phase 1 R ident
18:01:06.440840 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 1 I ident
18:01:06.475244 IP 10.0.255.1.1.500 > 10.0.1.1.500: isakmp: phase 1 R ident
18:01:06.477032 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 1 I ident[E]
18:01:06.487785 IP 10.0.255.1.500 > 10.0.1.1.500: isakmp: phase 1 R ident[E]
18:01:06.488048 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 2/others I inf[E]
18:01:07.412451 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 2/others I oakley-quick[E]
18:01:07.465363 IP 10.0.255.1.500 > 10.0.1.1.500: isakmp: phase 2/others R oakley-quick[E]
18:01:07.465940 IP 10.0.1.1.500 > 10.0.255.1.500: isakmp: phase 2/others I oakley-quick[E]
18:01:08.467373 IP 10.0.1.1 > 10.0.255.1: ESP(spi=0x7aabfa82,seq=0x1), length 116
18:01:08.480141 IP 10.0.255.1 > 10.0.1.1: ESP(spi=0x0386f867,seq=0x1), length 116
При удаленном подключении по SSH, чтобы не плодить кучу окон удобно запускать tcpdump в фоне:Также в логах можно увидеть успешный статус установления соединения. В нем видно успешное установление обоих фаз IPSec.
root@localhost: ~# tcpdump -i eth1 -w ipsec.pcap esp &
Запускаем ping, telnet, netcat…
root@localhost: ~# killall tcpdump
root@localhost: ~# tcpdump -vr ipsec.pcap
root@localhost: ~# cat /var/log/daemon.log
Oct 3 17:53:26 vm22433 racoon: INFO: IPsec-SA request for 10.0.255.1 queued due to no phase1 found.
Oct 3 17:53:26 vm22433 racoon: INFO: initiate new phase 1 negotiation: 10.0.1.1[500]<=>10.0.255.1[500]
Oct 3 17:53:26 vm22433 racoon: INFO: begin Identity Protection mode.
Oct 3 17:53:26 vm22433 racoon: INFO: received Vendor ID: CISCO-UNITY
Oct 3 17:53:26 vm22433 racoon: INFO: received Vendor ID: DPD
Oct 3 17:53:26 vm22433 racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Oct 3 17:53:26 vm22433 racoon: INFO: ISAKMP-SA established 10.0.1.1[500]-10.0.255.1[500] spi:ebddc300af62ae42:abcdef0123
Oct 3 17:53:27 vm22433 racoon: INFO: initiate new phase 2 negotiation: 10.0.1.1[500]<=>10.0.255.1[500]
Oct 3 17:53:27 vm22433 racoon: INFO: received RESPONDER-LIFETIME: 4608000 kbytes
Oct 3 17:53:27 vm22433 racoon: WARNING: attribute has been modified.
Oct 3 17:53:27 vm22433 racoon: INFO: IPsec-SA established: ESP/Tunnel 10.0.1.1[500]->10.0.255.1[500] spi=238677(0xe39eabc)
Oct 3 17:53:27 vm22433 racoon: INFO: IPsec-SA established: ESP/Tunnel 10.0.1.1[500]->10.0.255.1500] spi=7204011111(0x44b4aaa)
Вот и все. Остается добавить все необходимые манипуляции в автозагрузку, и можно начинать интеграцию приложений.
P. S.: Просьба обо всех ошибках или неточностях в статье сообщать личным сообщением. Когда я подправлю статью, комментарии будут смотреться глупо.
vesper-bot
Написать, что ли, про xSWAN подобное, «для чайников»? Надо кому?
shuchkin
Напишите, конечно. Я его так и не победил когда пыжился поднять IPSEC до
МегафонаМегателекома.Ну очень грустно с инструкциями по swan в сети. Спасибо автору за ликбез по айписеку.
evg_krsk
Надо.
vvpoloskin Автор
swanы выглядят более дружелюбно, вроде как настраивается все в одном месте, но по факту баги в них копятся, авторы на проекты забивают и в итоге через год-два все мануалы по ним уже неактуальны.
В то же время функционал KAME потихоньку переходит в ядро линуха, у которого поддержка явно больше полутораземлекопов SWANa