настройка ipsec на linux

IPIP IPsec VPN туннель между Linux машиной и Mikrotik за NAT провайдера

upd: Отличный разбор про устройство современного стэка IPsec протоколов ESPv3 и IKEv2 опубликовал stargrave2. Рекомендую почитать.

Linux: Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-91-generic x86_64)

Mikrotik: CCR 1009, RouterOS 6.46.5

IPsec туннель на Linux машине будем поднимать с помощью racoon. Не буду описывать подробности, есть хорошая статья у vvpoloskin.

Устанавливаем необходимые пакеты:

Настраиваем racoon, он условно будет выступать в роли ipsec сервера. Так как mikrotik в main режиме не может передавать дополнительный идентификатор клиента, а внешний ip адрес через который он коннектится к Linux динамический, использовать preshared key (авторизацию по паролю) не получится, так как пароль должен сопоставляться либо с ip адресом подключающегося хоста, либо с идентификатором.

Будем использовать авторизацию по RSA ключам.

Демон racoon использует ключи в формате RSA, а mikrotik — в формате PEM. Если генерировать ключи утилитой plainrsa-gen идущей вместе с racoon, то конвертировать публичный ключ для Mikrotika в формат PEM с ее помощью не получится — она конвертирует только в одну сторону: PEM в RSA. Сгенерированный plainrsa-gen ключ не смогли прочитать ни openssl, ни ssh-keygen, поэтому с их помощью также не получится выполнить конвертацию.

Мы сгенерируем PEM ключ с помощью openssl, а затем конвертируем его для racoon с помощью plainrsa-gen:

Полученные ключи положим в папку: /etc/racoon/certs/server. Не забываем установить владельцем пользователя, от чьего имени запускается демон racoon (обычно root), права 600.

Настройку mikrotik опишу при подключении через WinBox.

Ключ server-name.pub.pem загрузим в mikrotik: Меню «Files» — «Upload».

Открываем раздел «IP» — «IP sec» — вкладка «Keys». Теперь генерируем ключи — кнопка «Generate Key», затем экспортируем публичный ключ mikrotika «Expor Pub. Key», скачать его можно из раздела «Files», правой кнопкой по файлу — «Download».

Импортируем публичный ключ racoon, «Import», в выпадающем списке поля «File name» ищем загруженный ранее нами server-name.pub.pem.

Публичный ключ mikrotik нужно сконвертировать

и положить в папку /etc/racoon/certs не забыв про владельца и права.

Возвращаемся в раздел «IP» — «IPsec»

Вкладка «Profiles» Параметр	Значение
Name	На ваше усмотрение (по умолчанию default)
Hash Algorithm	sha512
Encryption Algorithm	aes-128
DH-Group	modp2048
Proposhal_check	claim
Lifetime	1d 00:00:00
NAT Traversal	true (ставим галочку)
DPD	120
DPD Maximum failure	5

Вкладка «Peers» Параметр	Значение
Name	На ваше усмотрение (далее MyPeer)
Address	1.1.1.1 (IP linux машины)
Local Address	10.0.0.2 (IP WAN интерфейса mikrotik)
Profile	default
Exchange Mode	main
Passive	false
Send INITIAL_CONTACT	true

Вкладка «Proposal» Параметр	Значение
Name	На ваше усмотрение (далее MyPeerProposal)
Auth. Algorithms	sha512
Encr. Algorithms	aes-128-cbc
Lifetime	08:00:00
PFS Group	modp2048

Вкладка «Identities» Параметр	Значение
Peer	MyPeer
Atuh. Method	rsa key
Key	mikrotik.privet.key
Remote Key	server-name.pub.pem
Policy Tamplate Group	default
Notrack Chain	пусто
My ID Type	auto
Remote ID Type	auto
Match By	remote id
Mode Configuration	пусто
Generate Policy	no

Вкладка «Policies — General» Параметр	Значение
Peer	MyPeer
Tunnel	true
Src. Address	192.168.0.0/30
Dest. Address	192.168.0.0/30
Protocol	255 (all)
Template	false

Вкладка «Policies — Action» Параметр	Значение
Action	encrypt
Level	requier
IPsec Protocols	esp
Proposal	MyPeerProposal

Скорее всего у вас, как и у меня, на WAN интерфейсе настроен snat/masquerade, это правило надо скорректировать, чтобы исходящие пакеты ipsec уходили в наш туннель:
Переходим в раздел «IP» — «Firewall».
Вкладка «NAT», открываем наше правило snat/masquerade.

Рестартуем демона racoon

Если при рестарте racoon не запускается, значит в конфиге имеется ошибка, в syslog racoon выводит информацию о номере строки, в которой обнаружена ошибка.

Демон racoon при загрузке ОС стартует раньше поднятия сетевых интерфейсов, а мы указали в секции listen опцию strict_address, необходимо добавить в файл systemd юнита racoon
/lib/systemd/system/racoon.service, в секцию [Unit], строку After=network.target.

Сейчас наши ipsec туннели должны подняться, смотрим вывод:

Теперь необходимо настроить L3 интерфейсы, чтобы можно было маршрутизировать трафик. Есть разные варианты, мы будем использовать IPIP, так как его mikrotik поддерживает, я бы использовал vti, но, к сожалению, в mikrotik его до сих пор не реализовали. От IPIP он отличается тем, что дополнительно может инкапсулировать multicast и ставить метки (fwmark) на пакеты, по которым можно их фильтровать в iptables и iproute2 (policy-based routing). Если нужна максимальная функциональность — тогда, например, GRE. Но не стоит забывать, что за дополнительную функциональность платим большим оверхедом.

Перевод неплохого обзора туннельных интерфейсов можно посмотреть тут.

На Linux:

Теперь можно добавить маршруты для сетей за mikrotik

Чтобы наш интерфейс и маршруты поднимались после перезагрузки, нужно описать интерфейс в /etc/network/interfaces и там же в post-up добавлять маршруты, либо прописать все в одном файле, например, /etc/ipip-ipsec0.conf и дергать его через post-up, не забудьте про владельца файла, права и сделать его исполняемым.

На Mikrotik:

Раздел «Interfaces», добавляем новый интерфейс «IP tunnel»:

Вкаладка «IP tunnel» — «General» Параметр	Значение
Name	На ваше усмотрение (далее IPIP-IPsec0)
MTU	1480 (если не указывать, то mikrotik начинает резать mtu до 68)
Local Address	192.168.0.2
Remote Address	192.168.0.1
Ipsec Secret	Деактивируем поле (иначе будет создан новый Peer)
Keepalive	Деактивируем поле (иначе интерфейс будет постоянно выключаться, так как у mikrotika какой-то свой формат этих пакетов и с linux не работает)
DSCP	inherit
Dont Fragment	no
Clamp TCP MSS	true
Allow Fast Path	true

Раздел «IP» — «Addresses», добавляем адрес:

Теперь можно добавлять маршруты в сети за linux машиной, при добавлении маршрута, gateway будет наш интерфейс IPIP-IPsec0.

Так как наш сервер linux является транзитным, то на нем имеет смысл задать параметр Clamp TCP MSS для ipip интерфейсов:

создаем файл /etc/iptables.conf со следующим содержимым:

и в /etc/network/interfaces
post-up iptables-restore

Источник

Непростой IPSec с Linux

Развивая IT-инфраструктуру рано или поздно приходит задача интегрироваться с какими-либо сервисами крупной организации. Это может быть, например, банк или оператор связи. Как правило в крупных организациях действуют устоявшиеся политики информационной безопасности, которые в частности требуют реализации сервиса с внешней по отношению к ним инфраструктурой через шифрованные каналы — IPSec. В то же время в небольших организациях стартапах нет опыта организации таких схем, а из оборудования есть только VDS с Linuxом на борту. Более того, к моему удивлению, в рунете практически нет материалов с описанием инструментов траблшутинга под Linux. Попробуем устранить этот пробел и описать практическую часть настроек.

Общая схема сервиса представлена ниже. Как правило, в крупных организациях все уже стандартизировано, поставлено на поток, всякие возможные шифрования и прочие сетевые штуки делаются на отдельном оборудовании (циски-джуниперы и иже с ними), и, что важнее, отдельными людьми (возможно каждый синий квадратик на схеме ниже обслуживают разные люди). У вас же одна виртуалка, с которой будет и запускаться сервис, и организовываться IPSec.

Обратите внимание, сам IPSec организовывается между одними IP-адресами (в моем примере 10.0.255.1 10.0.1.1 ), а сам сервис — между другими ( 192.168.255.1 192.168.1.1 ). Такие схемы еще называются IPSec Network-Network.

Простой пример — вы работаете в молодой, но очень амбициозной компании СуперСервис, и вам надо организовать взаимодействие с закрытым API компании МегаТелеком. Ваша инфраструктура — один сервер VDS, инфраструктура партнера — куча сетевого и серверного оборудования. Задача делится на два этапа:

Изначально он приходит не заполненный с вашей стороны, его надо заполнить и отправить на согласование партнеру. После согласования можно садиться и пробовать настраивать вашу 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 построен так, чтобы не зависеть от технологий туннелирования, алгоритмов аутентификации и шифрования. Он просто вводит необходимые определения.

IKE(v1/2) — непосредственно протокол аутентифиации. Он уже реализовывает алгоритмы обмена ключами и их применение.

Благодаря концепции Cisco сейчас ISAKMP и IKE считаются синонимами.

Перед шифрованием трафика стороны должны договориться о параметрах (и ключах) этого шифрования. Для этого между обоими сторонами поднимается вспомогательный туннель (его еще называют ISAKMP туннель), который действует все время. Туннель этот двунаправленный, представляет из себя соединение по UDP (по умолчанию на порту 500). Для организации этого вспомогательного туннеля стороны должны проверить подлинность друг друга (должен совпасть пароль). Этим занимается протокол IKEv1/2 (Internet Key Exchange). И уже по организованному ISAKMP туннелю стороны договариваются о шифровании непосредственно пользовательского трафика.

Собственно организация IPSecа делится на две фазы:

Первая фаза (организация ISAKMP SA) может осуществляться в двух режимах:

Во всех способах шифрования в оригинальный 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 будет /etc/racoon.conf ), запускается обычным init-скриптом ( /etc/init.d/racoon ).

Как всегда, подробности в man 5 racoon.conf

На текущий момент утилиту setkey дублирует модуль iproute2.
В рамках него есть две команды управления записями SA и SP.

Взгляните еще раз на изначальную табличку. Там указаны разные IP-адреса для IPSec и сервиса. По внутреннему IP-адресу идет фильтрация внутри инфраструктуры Мегателеком. Но у нас всего лишь одна виртуальная машина. На ней должен как-то появиться внутренний IP-адрес, и пакеты в туннель должны уходить именно с него. Есть несколько вариантов добиться этого сценария:

Мы можем добавить на наш интерфейс дополнительный (secondary) IP-адрес, при этом лучше сделать alias для этого интерфейса
root@localhost:

# ip addr add 192.168.1.1/32 dev eth1 label eth1:1
и настроить маршрут до сервера Мегателеком с этого IP-адреса.
root@localhost:

Проверка работоспособности

Не забывайте, туннель поднимется только тогда, когда в него пойдет трафик! Надо запустить пинг с конкретного интерфейса (IP-адреса) до назначения.
root@localhost:

Мы можем увидеть, поднялся ли ISAKMP-туннель

Также мы можем посмотреть туннели с пользовательскими данными

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

При удаленном подключении по SSH, чтобы не плодить кучу окон удобно запускать tcpdump в фоне:

Запускаем ping, telnet, netcat…

# killall tcpdump
root@localhost:

Также в логах можно увидеть успешный статус установления соединения. В нем видно успешное установление обоих фаз IPSec.

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

P. S.: Просьба обо всех ошибках или неточностях в статье сообщать личным сообщением. Когда я подправлю статью, комментарии будут смотреться глупо.

Источник

IPsec в Linux

Материал из Xgu.ru

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

Содержание

[править] Конфигурация ядра

Для работы IPSEC необходима поддержка со стороны ядра Linux.

Поддержка протоколов AH, ESP и IPComp (сжатие данных), а так же транспортного, тоннельного и BEET (Bound End-to-End Tunnel) режимов включается следующими опциями (для IPv4 и IPv6 соответственно):

Так же, существуют модули для поддержки IPSec в NetFilter:

Так же в разделе Cryptographic API необходимо включить в ядро статически или в виде модулей поддержку тех алгоритмов шифрования, которые вы собираетесь использовать. Автоматически выбираются следующие опции:

[править] Необходимые программы

Для конфигурирования и использования необходимы следующие пакеты программ:

Если вы используете только статические тоннели, то достаточно средств iproute2.

[править] IPSec и Netfilter

Netfilter имеет несколько модулей для работы с трафиком ipsec: модули iptables для обработки пакетов протоколов esp и ah, и модули xtables: xt_esp и xt_policy, взаимодействующий с подсистемой xfrm. Так же трафик ipsec можно фильтровать по полям заголовка ip (например, по адресам источника и назначения, номеру протокола, типу обслуживания и времени жизни, и т.п.).

Очень большими возможностями в плане фильтрации пакетов ipsec обладает модуль policy, но его действие не распространяется на транзитный трафик ipsec, так как он взаимодействует с подсистемой xfrm. Модуль policy поддерживает соответствие по следующим критериям:

Так же, если вы используете какой-либо ike-демон, то соответственно необходимо разрешить udp-пакеты с/на 500 порт. Если же вы используете инкапсуляцию в udp (nat-travesal), то необходимо разрешить udp-пакеты с номером порта 4500.

Так же, если вы используете nat, то в iptables необходимо добавить исключения для трафика IpSec.

Действие RETURN при срабатывании прекращает дальнейшую обработку трафика в данной цепочке и переходит к следующей. Правила nat обрабатываются раньше, чем трафик завернется в IpSec туннель.

[править] Конфигурирование Security Association

Безопасными Ассоциациями можно управлять через утилиту ip, входящую в пакет iproute2. Во многом её возможности шире, чем у setkey. Благодаря сокращениям и единообразному интерфейсу, работать с Безопасными Ассоциациями немного удобнее. Для управления SAD используется конструкция ip xfrm state. Допустимы сокращения наподобие ip x s. В отличии от setkey, который умеет только добавлять и удалять записи SA, ip позволяет их редактировать.

Добавление и изменение записей в SAD осуществляется командой:

Посмотреть информацию о безопасных ассоциациях можно с помощью следующих команд.

Количество безопасных ассоциаций в SAD можно проверить командой

Так же можно удалять безопасные ассоциации. Чтобы очистить SAD можно использовать команду

[править] Поддерживаемые криптографические алгоритмы

Алгоритмы, используемые для проверки целостности данных и аутентификации.

Алгоритм	Длина хэша	setkey	ip	Сокращение
null	null	digest_null
md5	128	hmac-md5	hmac(md5)	md5
sha-1	160	hmac-sha1	hmac(sha1)	sha1
sha-2	256	hmac-sha256	hmac(sha256)	sha256
sha-2	384	hmac-sha384	hmac(sha384)	sha384
sha-2	512	hmac-sha512	hmac(sha512)	sha512
ripemd	160	hmac(rmd160)	rmd160
aes	128	xcbc(aes)

Алгоритмы, используемые для шифрования данных.

Алгоритм	Длина ключа	setkey	ip	Сокращение
null	null	ecb(cipher_null)	cipher_null
des	64	des-cbc	cbc(des)	des
triple des	192	3des-cbc	cbc(des3_ede)	des3_ede
cast-128	40-128	cast128	cbc(cast5)	cast5
blowfish	40-448	blowfish-cbc	cbc(blowfish)	blowfish
aes	128-256	aes-cbc	cbc(aes)	aes
serpent	128-256	cbc(serpent)	serpent
camelia	128-256	camelia-cbc	cbc(camelia)	camelia
twofish	128-256	twofish-cbc	cbc(twofish)	twofish
aes	128/160/256	aes-ctr	rfc3686(ctr(aes))

Алгоритмы, используемые для проверки целостности данных, аутентификации и шифрования.

название	длина ключа	ip
aes	128-256	rfc4106(gcm(aes))
aes	128-256	rfc4309(ccm(aes))
aes	128-256	rfc4543(gcm(aes))

Так же для сжатия данных могут использоваться алгоритмы deflate, lzh, lzjh.

[править] Конфигурирование Security Policy

Security Policy (политики безопасности) определяют, какие именно пакеты будут передаваться с помощью ipsec, а так же, через какие безопасные ассоциации и какие действия к ним должны быть применены. Политики безопасности хранятся в Security Policies Database (База политики безопасности, далее SPD). Управление политиками безопасности так же осуществляется через утилиты setkey или ip (с помощью команд ip xfrm policy).

Добавление или изменение политики безопасности осуществляется командой:

[править] Конфигурирование IKE в Racoon

[править] Аутентификация с помощью preshared key

[править] Использование сертификатов X.509

[править] NAT-Travesal

[править] Практикум и готовые решения

[править] Конфигурационные файлы для L2TP сервера с IPsec.

Аутентификация будет производиться по сертификатам безопасности.

Авторизация только через CHAP. Логины и пароли пользователей должны быть прописаны в chap-secrets.

Указываем адреса днс-серверов. Значение параметра linkname можно использовать в скриптах ip-up и ip-down.

Прописываем Политики Безопасности для IPsec.

Источник