Как завернуть трафик в ipsec туннель linux

Обновлено: 30.06.2024

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

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

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

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

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

ipsec-tools - Универсальный пакет программ для конфигурирования IPSec (так же существуют версии под другие операционные системы, что является большим плюсом), но несколько проигрывает по возможностям iproute2. iproute2 - Позволяет настроить практически все параметры IPSec, которые вообще используются в Linux, включая инкапсуляцию в UDP, что полезно в случае работы через NAT. Racoon/Racoon2/strongSwan - осуществляют поддержку IKE, если Вы будете использовать её. Openssl - необходимо для работы с различными сертификатами.

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

В ядре 2.6 обработка трафика ipsec значительно отличается от того, как это делается в ядре 2.4, в котором присутствует псевдоинтерфейс ipsecX, который является границей раздела между инкапсулированным/зашифрованным трафиком и трафиком в открытом виде. Далее всё описываемое актуально для ядра 2.6. Трафик, подпадающий под политики ipsec, дважды проходит по цепочкам netfilter - в открытом виде и в инкапсулированном/зашифрованным. Не зашифрованный трафик, подпадающий под политики ipsec, проходит по всем цепочкам netfilter сетевого уровня и после цепочки POSTROUTING таблицы nat подвергается шифрованию/инкапсуляции, и уже в инкапсулированном/зашифрованном виде попадает в цепочку OUTPUT таблицы raw, и передаётся далее. Инкапсулированный/зашифрованный же трафик, который подпадает под политики, так же проходит по стандартным цепочкам и уже после цепочки INPUT таблицы filter декапсулируется/расшифровывается, и уже в открытом виде попадает в цепочку PREROUTING таблицы raw, и передаётся далее. Таким образом, трафик можно фильтровать и до, и после инкапсуляции/шифрования.

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

Следует учесть, что механизм conntrack не может отслеживать пакеты протоколов ipsec, поэтому к ним невозможно применять правила с совпадением по критерию --state. С учётом этого и того, что тоннели ipsec являются однонаправленными, необходимо строить правила так, чтобы разрешить передачу пакетов в обе стороны. Так же эти опции можно использовать для фильтрации транзитного трафика.

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

--dir in|out - пакеты, подпадающие под политики декапсуляции|инкапсуляции. --pol none|ipsec - применяемая к пакету политика. --reqid reqid - значение параметра reqid. --spi spi - значение параметра Security Parameters Index. --proto ah|esp|ipcomp - протокол ipsec. --mode transport|tunnel - режим ipsec - транспортный или тоннельный. --tunnel-src addr/mask - адрес источника (только в контексте --mode tunnel). --tunnel-dst addr/mask - адрес назначения (только в контексте --mode tunnel). --next - в одном правиле можно указать несколько политик, эта опция указывает, что далее следует параметры другой политики.

При использовании опций --tunnel-src и --tunnel-dst следует указывать адреса (и маски) именно адреса концов тоннеля (находятся в заголовке пакета ip, в который инкапсулирован пакет). Так же следует учесть, что правила с опцией --dir in недействительны в цепочках POSTROUTING и OUTPUT, а с опцией --dir out в цепочках PREROUTING и INPUT.

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

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

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

Security Association (Безопасная Ассоциация) - это по сути и есть безопасное соединение, обеспечивающее защиту передаваемых данных. На каждом из хостов, между которыми необходимо обеспечить безопасную передачу данных, должны быть созданы безопасные ассоциации для каждого направления. SA содержит такие параметры как адреса узлов/сетей источника и направления, индекс политик безопасности, алгоритмы шифрования/аутентификации и ключи.

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

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

ID - идентификатор безопасной ассоциации в SAD. Может состоять из следующих параметров

src ADDR - адрес источника dst ADDR - адрес назначения proto XFRM_PROTO - протокол ipsec (Соответственно может принимать значения ah (authentification header), esp (encrypted security payload), comp (ip compressed payload), route2 (type2 routing header) и hao (home address option). Последние два протокола используются в контексте mobile ipv6). spi SPI - значение security parameter index. mark MARK [mask MASK] - метка и маска пакета (используется при маркировке пакетов с помощью netfilter).

mode transport | tunnel | ro | in_trigger | beet - режим безопасной ассоциации. Соответственно, может принимать одно из значений, означающих транспортный, тоннельный, beet (Bound End-to-End Tunnel), оптимизации маршрута (route optimization) или in_trigger режимы. (последние два используются в контексте mobile ipv6).

reqid REQID - что-то вроде дополнительного идентификатора безопасной ассоциации. Удобно использовать при описании политик, чтобы не описывать шаблон безопасной ассоциации целиком.

seq SEQ - начальное значение sequence номера в пакетах ipsec (по-умолчанию 0).

replay-window SIZE - размер replay-window в пакетах (по-умолчанию имеет значение 32).

replay-seq SEQ и replay-oseq SEQ - значения счётчиков sequence для входящего и исходящего направлений соответственно.

Механизм anti-replay позволяет предотвратить атаки злоумышленников, использующих отправку ранее перехваченных зашифрованных пакетов против уязвимых узлов (так называемая "replay attack"). При выборе значения replay-window следует учесть, что если оно будет слишком маленьким, то в случае, если пакеты будут приходить в другом порядке (вызванном, например, следованием пакетов различными маршрутами или задержками на промежуточных узлах), то "запоздавшие" пакеты могут быть просто отброшены. Так что рекомендуется ставить размер окна как можно большим. При получении узлом зашифрованного пакета, его sequence-номер проверяется на предмет попадания в "окно" и на предмет дубливания с sequence-номерами ранее полученных пакетов. Если sequence-номер пакета больше, чем значение счётчика replay-seq, то пакет принимается и его номер отмечается в специальной битовой маске (replay.bitmap) как полученный; если sequence-номер пакета меньше, чем значение replay-seq - replay-window, то он отбрасывается, если же, он попадает в "окно", то проверяется, был ли получен пакет с таким номером ранее, если да, то он будет так же отброшен. Значения replay-seq, replay-oseq и replay.bitmap обновляются по мере получения пакетов. Так же в механизме учитываются не только сами sequence-номера пакетов, но и время ожидания "запаздывающих" пакетов.

flag FLAG - устанавливает один или несколько флагов опций. Может принимать следующие знячения:

noecn - не использовать механизм явных уведомлений о перегруженности. decap-dscp - учитывать поле DSCP инкапсулированного пакета. Бывает полезно при использовании QOS. nopmtudisc - не выполнять path MTU discovery. wildrecv icmp - разрешить приём icmp-пакетов, полученных через безопасную ассоциацию. Влияет только на входящий шифрованный трафик. af-unspec - позволяет инкапсулировать трафик одного протокола сетевого уровня в ipsec-трафик другого протокола сетевого уровня (например, ipv4 инкапсулировать в ipv6-ipsec). Наиболее актуален при beet-режиме безопасной ассоциации.

encap ENCAP-TYPE SPORT DPORT OADDR - используется для инкапсулирования пакетов протокола esp в udp для решения проблемы с nat. Тут, соответственно, ENCAP-TYPE может принимать значения espinudp или espinudp-nonike, SPORT и DPORT - номера портов источника и назначения, а OADDR - адрес, который будет использован в качестве адреса источника в инкапсулирующих пакетах udp.

limit - устанавливает время жизни (lifetime) безопасной ассоциации. Реализовано два типа: soft - после достижения лимита безопасная ассоциация остаётся в SAD, но система генерирует специальное событие timer expired (это событие обычно обрабатывется демонами ike, а так же будет отображено в режиме мониторинга); и hard - после достижения лимита безопасная ассоциация удаляется из SAD. Команда имеет следующие параметры:

packet-soft | packet-hard PACKETS - время жизни устанавливается количеством пакетов, прошедшим через безопасную ассоциацию. byte-soft | byte-hard BYTES - время жизни устанавливается количеством данных, прошедшим через безопасную ассоциацию. time-soft | time-hard SECONDS - время жизни безопасной ассоциации в секундах с момента добавления в SAD. time-use-soft | time-use-hard SECONDS - время жизни безопасной ассоциации в секундах с момента начала использования, то есть прохождения первого пакета.

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

Показать безопасные ассоциации, соответствующие заданным параметрам. Так же может использоваться с параметром -s[tatistic], позволяющим отобразить более подробную информацию о безопасной ассоциации.

Количество безопасных ассоциаций в 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)

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

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

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

dir DIR - направление движения пакетов, подпадающих под политику. Может принимать значения in - для входящих пакетов, out - для исходящих и fwd - для транзитных.

SELECTOR - шаблон, описывающий, какие пакеты подпадают под действия политики. Может содержать следующие параметры: src ADDR[/PLEN] dst ADDR[/PLEN] proto PROTO [ [ sport PORT ] [ dport PORT ] | [ type NUMBER ] [ code NUMBER ] ] [ dev DEV ]. Имеют такое же значение, как и при описании безопасной ассоциации.

index INDEX - идентификатор политики безопасности в SPD.

ptype PTYPE - тип политики безопасности. Может принимать значения main и sub (по-умолчанию main).

action ACTION - разрешить обработку пакета (allow) или отбросить его (block).

priority PRIORITY - приоритет политики.

limit LIMIT-LIST - время жизни политики. Полностью аналогично параметрам времени жизни безопасной ассоциации.

tmpl TMPL-LIST - шаблон безопасной ассоциации, через которую должен быть передан или получен пакет. Шаблон должен содержать один или несколько параметров [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ] [ mode MODE ] [ reqid REQID ] [ level LEVEL ]. Параметр level принимает значения required (обязательное шифрование) или use (необязательное шифрование), который задаёт действие по отношению к незашифрованным входящим пакетам, подпадающим под политику. Другие параметры аналогичны тем, что используются при описании безопасных ассоциаций.

mark MARK [mask MASK] - метка netfilter пакета, подпадающего под политику.

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

$EXTADDR - адрес, к которому будут коннектится клиенты. $SERVERCRT.crt и SERVERKEY.key - сертификаты безопасности нашего сервера.

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

$BEGRANGE и $ENDRANGE - начальный и конечный адреса клиентского диапазона. $LOCALADDR - адрес шлюза для клиентов.

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

Развивая 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, инфраструктура партнера — куча сетевого и серверного оборудования. Задача делится на два этапа:

Организовать транспорт (как будет происходить межсетевое взаимодействие).
Настроить сервис (запустить приложения непосредственно на серверах).

Концепция 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
Создание туннеля пользовательских данных

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

Политики состоят из адреса источника, адреса назначения, направления (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)

Традиционно KAME состоял из двух компонент

Демона racoon для управления туннелем ISAKMP.
Утилиты setkey для управления SA-туннелей с данными.

Как всегда, подробности в 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 . А я же приведу приведу пример простейшей конфигурации.

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

ip xfrm state
ip xfrm policy

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

Статический маршрут без определения некстхопа, но с явным указанием исходящего интерфейса и IP-адреса.
Задание маршрутов на основе policy based routing (PBR в Linux ака ip rule).
Трансляция адресов (NAT/MASQARADE).

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

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

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

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

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

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

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

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

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

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

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 не забыв про владельца и права.

Конфиг racoon с комментариями: /etc/racoon/racoon.conf

Возвращаемся в раздел "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

Вкладка "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.

Вкладка "Advanced" Параметр	Значение
IPsec Policy	out: none

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

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

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

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

Если туннели не поднялись, смотрите syslog, либо journalctl -u racoon.

Теперь необходимо настроить 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», добавляем адрес:

Параметр	Значение
Address	192.168.0.2/30
Interface	IPIP-IPsec0

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

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

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

и в /etc/network/interfaces
post-up iptables-restore < /etc/iptables.conf

В сети за mikrotik у меня работает nginx (ip 10.10.10.1), делаем доступным его из интернета, добавим в /etc/iptables.conf:

Не забывайте добавить соответствующие разрешения в iptables, если у вас включены фильтры пакетов.

Организовать транспорт (как будет происходить межсетевое взаимодействие).
Настроить сервис (запустить приложения непосредственно на серверах).

Концепция IPSec

IPSec — набор техник и протоколов по организации защищенного соединения.

ISAKMP — описание процедур IPSec, в литературе называют его фреймворком. В нем описываются термины SA, SP, SAD (Security Assotiations Database), SPD (Security Policy Database), необходимость установки вспомогательных туннелей… ISAKMP построен так, чтобы не зависеть от технологий туннелирования, алгоритмов аутентификации и шифрования. Он просто вводит необходимые определения.

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

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

Создание вспомогательного туннеля ISAKMP
Создание туннеля пользовательских данных

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

Кстати, есть реальный пример использования AH-инкапсуляции. Предположим, у нас есть две сети, подключенные к разным маршрутизаторам. Хосты должны передавать информацию с MTU 1500 байт без фрагментации, но у нас есть промежуточный участок, который поддерживает только 1380 байт. Вся трасса доверенная. Мы можем воспользоваться тем, что IPSec не создает туннельных интерфейсов, в классическом смысле через которые трафик не маршрутизируется. Мы создадим SA туннель AH типа (нам же не надо шифровать), тогда трафик пойдет него. В трафике фрагментироваться будут только внешние IP-пакеты (по внешним IP-заголовкам), внутренние будут пересобираться без изменений.

Все манипуляции с IPSec добавляют заголовки служебной информации. Минимум они съедят еще 40 байт от исходного пакета. Таким образом, например, при стандартном MTU для PPPoE в 1380 байт соединений реальное MTU будет < 1340.

IPSec в Linux

KAME, перекочевавший из BSD
xSWAN (strongswan, freeswan, libreswan, etc)

Традиционно KAME состоял из двух компонент

Демона racoon для управления туннелем ISAKMP.
Утилиты setkey для управления SA-туннелей с данными.

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

ip xfrm state
ip xfrm policy

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

Статический маршрут без определения некстхопа, но с явным указанием исходящего интерфейса и IP-адреса.
Задание маршрутов на основе policy based routing (PBR в Linux ака ip rule).
Трансляция адресов (NAT/MASQARADE).

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

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

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

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

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

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

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

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

Топология

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

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

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

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

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

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

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

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

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

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

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

Вы можете вместо SNAT использовать MASQUERADE. С точки зрения логики это работать должно, но из-за этого у меня в прошлом возникали проблемы с виртуальными частными серверами (VPS). Так что я бы рекомендовал использовать SNAT, если вы не против.
Если вы осуществляете управление на стороне B, то также следует создать подобные правила на сервере стороны B.
Прямая маршрутизации не требует SNAT.

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

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

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

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

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

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

Если туннель не поднят, то частная подсеть на стороне B не должна быть доступна со стороны А, т. е. команда ping не должна работать.
После того, как туннель будет поднят , попробуйте команду ping для доступа к частной подсети на стороне B со стороны A. Это должно работать.

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

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

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

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

Многие провайдеры отфильтровывают использование портов IPsec. Убедитесь, что вашим провайдером разрешено использовать порты UDP 500, TCP/UDP 4500. Вы можете с помощью telnet попробовать дистанционно подключиться к вашим портам IPsec на сервере.
Убедитесь, что в брандмауэре сервера / серверов открыты необходимые порты.
Убедитесь, что на обоих серверах правильные ключи.
На обоих серверах должны быть правильно настроены параметры left и right.
Если вы столкнулись с проблемами NAT, то вместо MASQUERADING попробуйте воспользоваться SNAT.

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

Читайте также: