Ipsec что это за программа

О ПРОТОКОЛЕ IPsec

IPsec (IP security) — набор протоколов для безопасной передачи трафика через IP сеть. Пожалуй, самый сложный и разветвленный стек протоколов из поддерживаемых системой VPNKI.

Включает в себя три основных протокола:

• AH (Authentication Header) — управление целостностью передаваемых данных и аутентификацию

• ESP (Encapsulating Security Payload) — шифрование данных

• ISAKMP (Internet Security Association and Key Management Protocol) — управление установкой соединения, взаимную аутентификации конечными узлами друг друга и обмен секретными ключами

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

• Протокол UDP, port 500 (IKE, управление ключами)
• Протокол UDP, port 4500 (IPSEC NAT-Traversal mode)
• Протокол ESP, значение 50 (for IPSEC)
• Протокол AH, значение 51 (for IPSEC)

Вообще, набор протоколов IPsec непрост с точки зрения возможностей его использования, которые весьма многогранны. Однако, базовой особенностью всего взаимодействия по этому протоколу является понятие SA (Security Association) — это набор параметров о том как стороны будут в дальнейшем использовать те или иные свойства протоколов из состава IPsec.

IPsec

Стоит еще упомянуть про два основных режима работы IPsec — туннельный и транспортный. Грубо говоря, в транспортном режиме шифруются только полезные данные IP пакета, а в туннельном режиме шифруется все данные, включая заголовки IP.

Аутентификация

Взаимодействие двух узлов начинается с установления SA. Точнее с двух ассоциаций — для протокола AH и ESP причем в одну и в другую стороны. SA начинается с аутентификации и затем стороны согласовывают будущие параметры сессии:

• для протокола AH — используемый алгоритм аутентификации, ключи, время жизни ключей и другие параметры,
• для протокола ESP — алгоритмы шифрования и аутентификации, ключи, параметры инициализации, время жизни ключей и другие параметры.

Здесь же стороны договариваются о туннельном или транспортном режиме работы IPsec.

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

Фаза 1 и Фаза 2

В IPsec все происходит по Фазам.

На фазе 1 происходит установление SA первой фазы. В первой фазе стороны договариваются о методе идентификации, алгоритме шифрования, алгоритме хэшировнаия и группе Diffie Hellman. Эта фаза может пройти путем обмена тремя нешифрованными пакетами (агрессивный режим) или шестью нешифрованными пакетами — стандартный режим. Если все прошло успешно, то создается SA фазы 1 под названием IKE SA и осуществляется переход ко второй фазе.

На фазе 2 стороны договариваются о политике и создаются сами ключи. Эта фаза, в отличии от первой полностью шифруется и она наступает только в случае успешного окончания первой фазы. В связи с тем, что трафик этой фазы полностью шифрован становится сложно осуществлять поиск неполадок, однако если все прошло успешно, то создается SA фазы 2 под названием IPSec SA. В этот момент можно сказать, что туннель установлен.

Тема 27. Обзор технологий VPN: PPTP, L2TP, IPSec, SSL.

Компрессия данных

В составе IPsec нет собственного механизма компрессии данны, однако можно использовать механизм IPcomp который компрессирует содержимое IP пакета до его передачи в процесс IPsec. Некоторые демоны IPsec поддерживают включение этого механизма из файлов настроек ipsec.conf (например пакет Strongswan)

Автоматическая проверка работоспособности VPN соединения

Внутри IPsec нет штатного средства для проверки работоспособности соединения (типа ping), поэтому работу туннеля можно проверять внешними средствами.

Разрыв VPN соединения и смена ключей

Согласованные на двух фазах ключи должны работать оговоренное политикой время. Это означает, что сторонам возможно предстоит пережить процедуру смены ключей (rekeying), а иначе согласованные SA распадутся. Как было сказано выше, у сторон есть ключи в рамках процесса фазы 1 (IKE) и фазы 2 (IPsec). Процедуры их смены различны, как и таймеры, которые за это отвечают. Для того, чтобы не было перерыва связи в процессе смены ключей стороны сначала согласовывают параметры новой SA и лишь после этой успешной процедуры уничтожают старую SA.

В IPsec на каждой из фаз есть несколько способов смены ключей — с аутентификацией или без нее, но мы не будем сильно заострять на этом свое внимание. Просто для этой процедуры слишком существует много нюансов, которые зависят от версий ПО и соотношения таймеров — для IKE и IPsec.

Автоматическое установление разорванного VPN соединения

Важным аспектом является способность IPsec устанавливать соединение заново. Для этого существуют настройки в ispec.conf, однако детали этих настроек могут отличаться от версии ПО. Сверяйтесь с мануалом именно по вашей версии программного обеспечения.

• высокая криптоустойчивость
• возможность использования L2TP внутри IPsec для аутентификации по имени пользователя и паролю (вариант VPNKI)

Минусы:

• сложен для настройки и поиска неисправностей
• большие накладные расходы на передачу трафика в канале за счет заголовков

ДОПОЛНИТЕЛЬНО

Кроме базового функционала по объединению VPN туннелей с различными протоколами, в системе VPNKI вы можете воспользоваться удаленным доступом к компьютеру или камере, используя:

• Доступ из Интернет через HTTP и SOCK5 прокси

• Публикацию URL по которому вы будете попадать на свое домашнее устройство

• Проброс порта TCP, который будет вести на устройство в вашей сети

Источник: vpnki.ru

IPSec — история, архитектура, подключение

IP Security — это комплект протоколов, в состав которого входят почти 20 предложений по стандартам и 18 RFC. Он позволяет осуществлять подтверждение подлинности (аутентификацию), проверку целостности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в интернете.

Основное назначение протокола — организация VPN-соединений. Рассказываем, как появился и как устроен IPsec, а также как подключить VPN-соединение в Win10.

Немного истории

В 1994 году Совет по архитектуре интернета (IAB) выпустил отчёт «Безопасность архитектуры интернета». В этом документе описывались основные области применения дополнительных средств безопасности в сети, в том числе защита от несанкционированного мониторинга, подмены пакетов и управления потоками данных. В числе первоочередных и наиболее важных защитных мер указывалась необходимость разработки концепции и основных механизмов обеспечения целостности и конфиденциальности потоков данных. Поскольку изменение базовых протоколов семейства TCP/IP вызвало бы полную перестройку интернета, нужно было обеспечить безопасность информационного обмена в открытых телекоммуникационных сетях на базе существующих протоколов. Так начала создаваться спецификация Secure IP, дополнительная по отношению к протоколам IPv4 и IPv6.

Архитектура

Спецификация IP Security (известная сегодня как IPsec) разрабатывается Рабочей группой IP Security Protocol IETF. Первоначально IPsec включал в себя алгоритмо-независимые базовые спецификации, опубликованные в качестве RFC-документов «Архитектура безопасности IP», «Аутентифицирующий заголовок (AH)», «Инкапсуляция зашифрованных данных (ESP)» (RFC1825, 1826 и 1827).

В ноябре 1998 года Рабочая группа IP Security Protocol предложила новые версии этих спецификаций, имеющие в настоящее время статус предварительных стандартов, это RFC2401 —RFC2412. RFC1825-27 уже несколько лет считаются устаревшими и реально не применяются. Кроме этого, существуют несколько алгоритмозависимых спецификаций, использующих протоколы MD5, SHA, DES.

Рабочая группа IP Security Protocol разрабатывает также и протоколы управления ключевой информацией. В задачу этой группы входит разработка Internet Key Management Protocol (IKMP), протокола управления ключами прикладного уровня, не зависящего от используемых протоколов обеспечения безопасности. Сейчас рассматриваются концепции управления ключами с использованием спецификации Internet Security Association and Key Management Protocol (ISAKMP) и протокола Oakley Key Determination Protocol.

Спецификация ISAKMP описывает механизмы согласования атрибутов используемых протоколов, в то время как протокол Oakley позволяет устанавливать сессионные ключи на компьютеры сети Интернет. Ещё рассматривались возможности использования механизмов управления ключами протокола SKIP, но сейчас они нигде не используются. Создаваемые стандарты управления ключевой информацией, возможно, будут поддерживать Центры распределения ключей, аналогичные используемым в системе Kerberos. Протоколами ключевого управления для IPSec на основе Kerberos сейчас занимается относительно новая рабочая группа KINK (Kerberized Internet Negotiation of Keys).

Гарантии целостности и конфиденциальности данных в спецификации IPsec обеспечиваются за счет использования механизмов аутентификации и шифрования соответственно. Последние, в свою очередь, основаны на предварительном согласовании сторонами информационного обмена т.н. «контекста безопасности» – применяемых криптографических алгоритмов, алгоритмов управления ключевой информацией и их параметров.

Спецификация IPsec предусматривает возможность поддержки сторонами информационного обмена различных протоколов и параметров аутентификации и шифрования пакетов данных, а также различных схем распределения ключей. При этом результатом согласования контекста безопасности является установление индекса параметров безопасности (SPI), который по сути является указателем на определенный элемент внутренней структуры стороны информационного обмена, описывающей возможные наборы параметров безопасности.

IPSec, который станет составной частью IPv6, работает на третьем или сетевом уровне. В результате передаваемые IP-пакеты будут защищены прозрачным для сетевых приложений и инфраструктуры образом. В отличие от SSL (Secure Socket Layer), который работает на четвертом (транспортном) уровне и теснее связан с более высокими уровнями модели OSI, IPSec призван обеспечить низкоуровневую защиту.

К IP-данным, готовым к передаче по виртуальной частной сети, IPSec добавляет заголовок для идентификации защищенных пакетов. Перед передачей эти пакеты инкапсулируются в другие IP-пакеты. IPSec поддерживает несколько типов шифрования, в том числе Data Encryption Standard (DES) и Message Digest 5 (MD5).

Чтобы установить защищенное соединение, оба участника сеанса должны иметь возможность быстро согласовать параметры защиты (алгоритмы аутентификации и ключи). IPSec поддерживает два типа схем управления ключами, с помощью которых участники могут согласовать параметры сеанса. Эта двойная поддержка в свое время вызвала трения в IETF Working Group.

С текущей версией IP, IPv4, могут быть использованы Internet Secure Association Key Management Protocol (ISAKMP) или Simple Key Management for Internet Protocol. С новой версией IP, IPv6, придется использовать ISAKMP, известный сейчас как IKE, хотя не исключается возможность использования SKIP. Но стоит помнить, что SKIP уже давно не рассматривается как кандидат управления ключами, и даже был исключён из списка возможных кандидатов ещё в 1997 г.

Достоинства IPSec

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

Современные ОС (исключая мобильные) поддерживают IPsec IKEv2 из коробки. Не требуется установка дополнительного прикладного ПО, драйверов виртуальных адаптеров TUN/TAP и тому подобного. Настройка VPN-соединений происходит из системного меню.

Настройка VPN-подключения в ОС Windows 10

Рассмотрим пример настройки VPN-подключения на основе IKEv2

IKE (Internet Key Exchange) — реальный управляющий протокол IPsec на основе ISAKMP. На практике можно сказать, что Phase 1 — согласование настроек IKE, а Phase 2 — согласование настроек ESP.

В UNIX-подобных системах IKE — это единственная часть стека IPsec, которая работает в виде обычного процесса. Само шифрование реализовано в ядре, и демон IKE передаёт ему параметры после согласования со второй стороной. В Linux это происходит через netlink или команды ip xfrm.

Мастер настройки VPN-подключения вызывается из меню «Пуск».

Выбираем пункт «Добавить VPN-подключение» и переходим в окно настройки VPN-соединений.

Идём в пункт «Добавить VPN-подключение» и попадаем в окно настройки параметров подключения.

1) Поставщик услуг – «Windows (встроенные)» (других вариантов и нет).

2) Имя подключения – произвольное название (главное, чтобы можно было отличить от других подключений, если они будут).

3) Имя или адрес сервера – адрес сервера VPN (через который и организуется VPN-подключение).

4) Тип VPN – в нашем примере IKE2. Но могут использоваться и более старые протоколы (SSTP, PPTP). Присутствует и вариант «автоматического» выбора типа подключения на основе поддерживаемых сервером.

5) Тип данных для входа – имеется в виду способ аутентификации. Главным образом используются традиционные входы по «логин/пароль» или с применением сертификата.

6) «Имя пользователя», «Пароль».

Настройка сервера VPN

Развернуть свой IKEv2 сервер можно за пару минут с помощью скриптов автоматической установки или используя готовые контейнеры. Использовать docker не рекомендуется, так как его сетевая подсистема снижает производительность IPsec на дешевых тарифах VPS. Вы также можете настроить IKEv2-сервер вручную, на Хабре есть статьи с примерами настройки сервера Strongswan.

Мы будем использовать один из наиболее удачных вариантов скриптов автонастройки github.com/jawj/IKEv2-setup

Этот скрипт хорош тем, что использует сертификаты от Let’s Encrypt и автоматически генерирует валидный сертификат.

Шаг 1: Выбор сервера

Для развёртывания VPN-сервера нам потребуется Vcd. Подойдет самая простая конфигурация с одним ядром процессора. Скрипт из нашего примера лучше всего протестирован на Ubuntu, поэтому при создании сервера используем этот образ ОС.

Ждём окончания установки сервера, настраиваем сеть и записываем учётные данные для подключения.

Шаг 2: Установка Strongswan

Подключаемся по SSH, загружаем и запускаем скрипт установки:

# запуск автоматической установки сервера IKEv2 wget https://raw.githubusercontent.com/jawj/IKEv2-setup/master/setup.sh chmod u+x setup.sh ./setup.sh . # Введите имя домена направленного на IP-адрес сервера # используйте сервис sslip.io если у вас нет домена Hostname for VPN: myvpn.sslip.io # Имя пользователя VPN VPN username: user-test # пароль VPN password (no quotes, please): . # скрипт запрос создать нового SSH-пользователя, этот шаг нельзя пропускать.

Шаг 3: Настройка клиента

Заданные реквизиты пользователя VPN теперь нужно использовать для настройки подключения на узле клиента. Необходимо указать именно то доменное имя, которое вы вводили в Hostname for VPN.

Шаг 4: Добавление новых пользователей

Чтобы добавить нового пользователя в уже созданный сервер, отредактируйте файл /etc/ipsec.secrets.

# nano /etc/ipsec.secrets 123-45-67-89.sslip.io : RSA «privkey.pem» coolguy : EAP «C00lPassword» badguy : EAP «bAdP$$word»

Выводы

Мне кажется, что с точки зрения пользователя IKEv2/IPsec выглядит предпочтительнее других реализаций VPN. Настройки и управление таким сервером как минимум не труднее, чем аналогичного на OpenVPN. При организации удалённого доступа в корпоративной среде вполне подходит IKEv2.

Это позволит обойтись без лишних телодвижений, проще в настройке и обслуживании.

Что ещё интересного есть в блоге Cloud4Y

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу. А ещё напоминаем про второй сезон нашего сериала ITить-колотить. Его можно посмотреть на YouTube и ВКонтакте.

Источник: habr.com

Загадочный IPsec. Все, что ты хотел узнать об IPsec, но не догадывался спросить

IPsec — сложный стек протоколов. На клиентской стороне он обычно автоматизирован, что в сочетании с его названием легко может вызвать у пользователя ощущение полной безопасности. Однако не всегда оправданное. Только IPsec из протоколов, пригодных для организации VPN, поддерживают все сетевые ОС, поэтому у тебя есть неплохой шанс с ним столкнуться. И чтобы быстро настраивать соединения и правильно оценивать их безопасность, нужно понимать, как работает протокол.

Из чего состоит IPsec?

IPsec — это не один протокол, а три или четыре, смотря как считать. В OpenVPN и других решениях на основе TLS все просто: устанавливается соединение по TCP или UDP, согласовываются параметры, а затем передаются данные.

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

AH и ESP

Три основных компонента безопасности — доступность, аутентичность и конфиденциальность. IPsec может обеспечивать аутентичность, при этом ничего не делая для конфиденциальности.

Протокол AH (Authentication Header) добавляет в пакет специальный заголовок с контрольной суммой. На практике он используется редко, поскольку никак не способствует конфиденциальности.

Тем не менее его можно встретить в приложениях, где важна только аутентичность. К примеру, протокол маршрутизации OSPFv2 использовал пароли и суммы MD5 для защиты от поддельных анонсов, а его наследник OSPFv3 не включает никакой функциональности для защиты — вместо этого предлагается использовать IPsec в транспортном (прозрачном) режиме и с одной подписью AH без шифрования.

ESP (Encapsulated Security Payload) шифрует содержимое пакета и добавляет хеши. Его можно использовать в двух режимах — транспортном и туннельном. Это сейчас в сетях IPv4 любой VPN немыслим без маршрутизации частных (серых) адресов через туннель, поскольку со внешним миром хосты общаются через NAT. Но IPsec старше NAT и изначально шифровал только полезную нагрузку пакетов, не трогая заголовки, — это и есть транспортный режим.

В туннельном режиме ESP шифрует весь пакет и передает его как полезную нагрузку, на другой стороне он извлекается, расшифровывается и маршрутизируется дальше.

Что интересно, оба они не работают поверх TCP или UDP, а используют отдельные номера протоколов IP. Во всяком случае, по умолчанию — ESP может быть инкапсулирован в UDP для работы через NAT, но об этом позже.

Фреймворк для управляющих протоколов — ISAKMP

Общие принципы согласования настроек безопасности описывает ISAKMP (Internet Security Association and Key Management Protocol). Он описан в RFC 2408.

ISAKMP не является законченным сетевым протоколом. Это фреймворк, который описывает требования к безопасной работе протоколов обмена настройками безопасных соединений, терминологию и общий формат пакетов, но ничего не говорит о конкретных протоколах обмена ключами, шифрования и прочего — это остается на совести реализаций.

Именно из ISAKMP происходят термины Phase 1 и Phase 2, которые часто можно встретить в интерфейсе настройки маршрутизаторов и в описаниях настроек для подключения. Phase 1 — согласование параметров безопасного обмена данными о настройках. Phase 2 — согласование параметров собственно защиты передаваемого трафика хостов или приложений.

Самая популярная и практически единственная реализация ISAKMP — IKE.

Управляющий протокол — IKE

IKE (Internet Key Exchange) — реальный управляющий протокол IPsec на основе ISAKMP. На практике можно сказать, что Phase 1 — согласование настроек IKE, а Phase 2 — согласование настроек ESP.

В UNIX-подобных системах IKE — это единственная часть стека IPsec, которая работает в виде обычного процесса. Само шифрование реализовано в ядре, и демон IKE передает ему параметры после согласования со второй стороной. В Linux это происходит через netlink или команды ip xfrm .

INFO

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

Популярные пакеты «для IPsec» вроде StrongSWAN и LibreSWAN реализуют именно IKE.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Источник: xakep.ru

Что такое и как работает IPsec

IPsec — сложный стек протоколов. На клиентской стороне он обычно автоматизирован, что в сочетании с его названием легко может вызвать у пользователя ощущение полной безопасности. Однако не всегда оправданное. Только IPsec из протоколов, пригодных для организации VPN, поддерживают все сетевые ОС, поэтому у вас есть неплохой шанс с ним столкнуться. И чтобы быстро настраивать соединения и правильно оценивать их безопасность, нужно понимать, как работает стек протоколов IPsec.

В этой статье я отвечу на вопрос «Что такое IPsec?». Вы узнаете все, что необходимо знать об IPsec

Что такое IPsec и из чего он состоит?

IPsec — это не один протокол, а три или четыре, смотря как считать. В OpenVPN и других решениях на основе TLS все просто: устанавливается соединение по TCP или UDP, согласовываются параметры, а затем передаются данные.

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

AH и ESP

Три основных компонента безопасности: доступность, аутентичность и конфиденциальность. IPsec может обеспечивать аутентичность, при этом ничего не делая для конфиденциальности.

Протокол AH (Authentication Header) добавляет в пакет специальный заголовок с контрольной суммой. На практике он используется редко, поскольку никак не способствует конфиденциальности.

Тем не менее его можно встретить в приложениях, где важна только аутентичность. К примеру, протокол маршрутизации OSPFv2 использовал пароли и суммы MD5 для защиты от поддельных анонсов, а его наследник OSPFv3 не включает никакой функциональности для защиты — вместо этого предлагается использовать IPsec в транспортном (прозрачном) режиме и с одной подписью AH без шифрования.

ESP (Encapsulated Security Payload) шифрует содержимое пакета и добавляет хеши. Его можно использовать в двух режимах — транспортном и туннельном. Это сейчас в сетях IPv4 любой VPN немыслим без маршрутизации частных (серых) адресов через туннель, поскольку со внешним миром хосты общаются через NAT. Но IPsec старше NAT и изначально шифровал только полезную нагрузку пакетов, не трогая заголовки, — это и есть транспортный режим.

В туннельном режиме ESP шифрует весь пакет и передает его как полезную нагрузку, на другой стороне он извлекается, расшифровывается и маршрутизируется дальше.

Что интересно, оба они не работают поверх TCP или UDP, а используют отдельные номера протоколов IP. Во всяком случае, по умолчанию — ESP может быть инкапсулирован в UDP для работы через NAT, но об этом позже.

Фреймворк для управляющих протоколов — ISAKMP

Общие принципы согласования настроек безопасности описывает ISAKMP (Internet Security Association and Key Management Protocol). Он описан в RFC 2408.

ISAKMP не является законченным сетевым протоколом. Это фреймворк, который описывает требования к безопасной работе протоколов обмена настройками безопасных соединений, терминологию и общий формат пакетов, но ничего не говорит о конкретных протоколах обмена ключами, шифрования и прочего — это остается не совести реализаций.

Именно из ISAKMP происходят термины Phase 1 и Phase 2, которые часто можно встретить в интерфейсе настройки маршрутизаторов и в описаниях настроек для подключения. Phase 1 — согласование параметров безопасного обмена данными о настройках. Phase 2 — согласование параметров собственно защиты передаваемого трафика хостов или приложений.

Самая популярная и практически единственная реализация ISAKMP — IKE.

Управляющий протокол — IKE

IKE (Internet Key Exchange) — реальный управляющий протокол IPsec на основе ISAKMP. На практике можно сказать, что Phase 1 — согласование настроек IKE, а Phase 2 — согласование настроек ESP.

В UNIX-подобных системах IKE — это единственная часть стека IPsec, которая работает в виде обычного процесса. Само шифрование реализовано в ядре, и демон IKE передает ему параметры после согласования со второй стороной. В Linux это происходит через netlink или команды ip xfrm .

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

Популярные пакеты «для IPsec» вроде StrongSWAN и LibreSWAN реализуют именно IKE.

Согласование настроек шифрования

В IKE есть возможность предложить второй стороне несколько вариантов на выбор, и соединение будет установлено, если у обеих сторон найдется хотя бы один совпадающий вариант. Это общий принцип работы протоколов обмена ключами, TLS работает так же, но в TLS периодически удаляют поддержку устаревших алгоритмов. В IKE безопасность выбора алгоритмов остается на совести пользователя. Заведомо уязвимые DES и MD5 из протокола официально не исключены и до сих пор поддерживаются многими реализациями.

С каждым туннелем ассоциировано одно или несколько «предложений» (proposals). Предложения обрабатываются до первого совпадения. Отсюда следствие: вполне возможна ситуация, когда зловредный (или безответственно настроенный) сервер предложит клиенту устаревшие алгоритмы, а неаккуратно настроенный клиент согласится. У некоторых клиентов вообще может не быть возможности выбрать алгоритмы вручную, а особо ленивые админы любят делать для всех клиентов один большой proposal со всеми мыслимыми алгоритмами. Сортировать алгоритмы по надежности стандарт не обязывает, и стороны вполне могут договориться на шифр полувековой давности.

Более того, официально поддерживается null cipher — опция не шифровать трафик вообще.

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

1. Ни в коем случае нельзя соглашаться ни на что, что кончается на ecb . ECB (Electronic Code Book) — чрезвычайно небезопасный режим работы блочных шифров. Суть проблемы наглядно демонстрирует знаменитый ECB penguin. Хороший шифр в неверном режиме — плохой шифр. AES-128-CBC — хорошо, AES-128-ECB — плохо.
2. 3DES и Blowfish до недавнего времени считались надежными, но уязвимость SWEET32 показала, что это не так. AES-128, AES-256, Twofish и другие шифры с 128-битными блоками — все еще разумный выбор.
3. Группы для алгоритма Диффи — Хеллмана DH1024 (group 2) и DH1536 (group 5) также признаны уязвимыми. Нужно использовать DH2048 (group 14) или группы на эллиптических кривых.

В IKE вполне можно использовать разные наборы алгоритмов для Phase 1 и Phase 2. Смысла в этом немного, но возможность имеется.

Diffie — Hellman и PFS

PFS (Perfect Forward Secrecy) — рекомендуемая опция, которую многие оставляют выключенной, а зря, особенно если используется pre-shared key.

В этом режиме из ключей обеих сторон генерируется периодически обновляемый сессионный ключ и согласуется с помощью алгоритма Диффи — Хеллмана (DH). В предельно упрощенной формулировке он основан на том, что возвести число в степень просто, а вычислить логарифм — гораздо сложнее. При использовании PFS, если кто-то получит доступ к общему ключу, он не сможет расшифровать им перехваченный трафик, в этом и суть forward secrecy. Подобранный ключ от одной сессии также не поможет расшифровать последующие, при условии, что числа достаточно большие, именно поэтому DH1024 и DH1536 стали небезопасны — современное железо уже достаточно быстрое для их взлома.

Параметр Phase2 lifetime (ESP lifetime) указывает, как часто должен меняться ключ. Время жизни ключа — чисто локальный параметр, который не согласуется через IKE и может оказаться разным на разных сторонах. Если ваши туннели IPsec сначала передают трафик, а потом вдруг перестают работать, проверьте, совпадает ли время жизни ключа на обеих сторонах.

Security Associations

В отличие от OpenVPN или wireguard, IPsec сам по себе не создает никаких виртуальных интерфейсов. Во времена его зарождения у каждого хоста в интернете был публичный адрес и никакой потребности в виртуальных сетях с отдельной адресацией просто не было. Виртуальными интерфейсами занимаются отдельные протоколы, например L2TP или GRE, а IPsec только шифрует их трафик. Многие платформы поддерживают VTI — ассоциированный с соединением IPsec виртуальный интерфейс, но на деле это всего лишь автоматизированная настройка IPIP поверх IPsec.

Вместо туннелей IPsec оперирует еще более абстрактными сущностями — security associations. Они не являются сетевыми соединениями, это просто наборы параметров, которые указывают, какой трафик и как шифровать. К примеру, «трафик из 192.168.1.0/24 в 10.1.0.0/24 зашифровать AES-128 и добавить сумму SHA-1».

Security associations существуют на обеих сторонах независимо и не могут оборваться сами по себе, в отличие от сетевых соединений. Если ты видишь на своей стороне живую SA, это еще не значит, что трафик нормально пойдет на вторую сторону туннеля. Не забывайте проверять, что все на самом деле работает. Чтобы вторая сторона могла узнать, что у вас происходит, нужно настроить dead peer detection (для IKEv1) или использовать IKEv2, где есть liveness check.

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

NAT traversal

IPsec появился до NAT и в своем чистом виде работать за NAT не может. Эту возможность к нему прикрутили позже. Сам ESP — отдельный протокол IP с номером 50. Для работы за NAT его инкапсулируют в UDP. В этом случае IKE и инкапсулированный ESP используют один порт — UDP/4500.

Изначально от NAT страдали пользователи клиентских соединений вроде L2TP и IPsec. Популярность облачных платформ, где вместо присвоения хостам публичных адресов эти адреса раздают через 1:1 NAT сделала эту проблему актуальной и для соединений между маршрутизаторами.

При этом может возникнуть неожиданная проблема: если на другой стороне туннель настроен на фиксированный адрес, даже если NAT traversal поддерживается, соединение не заработает.

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

Решение простое: никто не обязывает использовать идентификатор по умолчанию. В него можно прописать вообще любую строку, иногда даже необходимо, к примеру если у второй стороны нет фиксированного адреса или используется x.509.

Например, в StrongSWAN:

Источник: tech-geek.ru